☰

OpenVPN 클라이언트에서 OpenVPN 서버 뒤의 LAN으로 나가는 연결이 서버 커널에 의해 전달됩니까?

tag-icon • tag-icon iptables openvpn kernel forwarding tun
OpenVPN 클라이언트에서 OpenVPN 서버 뒤의 LAN으로 나가는 연결이 서버 커널에 의해 전달됩니까?

나는 완전히 이해할 수 없는 다소 이상한 행동을 관찰했습니다. 그래서 아래 그림과 같이 OpenVPN 연결을 설정했습니다. (TUN 및 클라이언트 간 설정입니다). 내 생각은 이 시나리오에서 핑 경로를 향하고 있습니다. 내 openvpn 연결

 from client: 192.168.200.102 to LAN: 10.198.0.16

일반적으로 이 ping이 성공한다는 것은 놀라운 일이 아니지만, 제가 이해하기로는 서버의 iptables 설정을 다음과 같이 변경하는 경우입니다.

-P FORWARD DROP

그리고 심지어

 net.ipv4.ip_forward = 0.

위의 설정으로는 트래픽이 목적지에 도달해서는 안 됩니다. 트래픽이 성공하더라도 LAN 인터페이스에 도달하지 않습니다. 문제는 LAN 인터페이스 eth0 10.198.0.16에 도착하는 트래픽(tcpdump 데이터 네트워크 패킷 분석기를 실행하여)을 볼 수 없다는 것입니다. LAN IP가 tun 인터페이스에 바인딩된 것처럼 tun 인터페이스가 트래픽에 자체 응답하는 것 같습니다. 아래를 참조하세요.

sudo tcpdump -i tun0 tcpdump: 16:34:21.391381 IP 192.168.200.102 > 10.198.0.16: ICMP echo request, id 14, seq 1885, length 64 16:34:21.391514 IP 10.198.0.16 > 192.168.200.102: ICMP echo reply, id 14, seq 1885, length 64

여기서 무슨 일이 일어나고 있나요? 내가 이해하는 한, 클라이언트에서 오는 요청은 서버의 tun 인터페이스로 이동하고 결국에는전달됨커널에서 eth0으로, 맞나요? 일반적으로 다음을 실행하여 볼 수 있습니까? sudo tcpdump -i tun0또는 sudo tcpdump -i eth0?

제가 이 문제를 그토록 까다롭게 여기는 이유는 클라이언트가 서버의 LAN에 액세스하는 것을 방지하는 규칙을 구현할 방법이 없으면 보안 위험이 있다고 생각하기 때문입니다. 여기서 무엇을 놓치고 있습니까? 클라이언트-클라이언트 구성을 위해 의도된 대로 패킷을 eth0 인터페이스로 전달하는 OpenVPN 프로세스가 있습니까?

내 문제를 더 잘 해결할 수 있도록 아래에 진단 정보를 첨부했습니다.

서버의 경우

  1. ip addr

    `1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
    valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether b8:27:eb:5c:a6:e6 brd ff:ff:ff:ff:ff:ff
    inet 10.198.0.16/24 brd 10.198.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fe5c:a6e6/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b8:27:eb:09:f3:b3 brd ff:ff:ff:ff:ff:ff
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 192.168.200.1/24 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::87cd:fedd:92fc:cde/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

`

  1. ip route

    default via 10.198.0.1 dev eth0 proto static 
10.198.0.0/24 dev eth0 proto kernel scope link src 10.198.0.16 
192.168.200.0/24 dev tun0 proto kernel scope link src 192.168.200.1 
192.168.178.0/24 via 192.168.200.1 dev tun0 scope link

  2. server openvpn.conf

    tls-server
mode server
dev tun
local 10.198.0.16
proto tcp-server
port 1234
user openvpn
group openvpn
ca /etc/openvpn/cacert.pem
cert /etc/openvpn/servercert.pem
key /etc/openvpn/serverkey
dh /etc/openvpn/dh2048.pem
ifconfig-pool 192.168.200.2 192.168.200.103 255.255.255.0
client-config-dir /etc/openvpn/ccd
ifconfig 192.168.200.1 255.255.255.0
keepalive 10 120
comp-lzo
client-to-client
push "topology subnet"
topology "subnet"
log /var/log/openvpn.log

클라이언트의 경우

  1. ip addr

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 38:af:d7:a0:52:ec brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:28:f8:8d:1c:6f brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.79/24 brd 192.168.178.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 859868sec preferred_lft 859868sec
    inet6 2a0a:a540:d54:0:bd79:eb10:5e26:548a/64 scope global temporary dynamic 
       valid_lft 7190sec preferred_lft 3590sec
    inet6 2a0a:a540:d54:0:6086:b044:dff:2694/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7190sec preferred_lft 3590sec
    inet6 fe80::ad5c:6e18:87fa:dff4/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 192.168.200.102/24 brd 192.168.200.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::5dfc:6b3a:3c4d:e9a4/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

  2. ip route

     default via 192.168.178.1 dev wlp2s0 proto dhcp metric 600 
 169.254.0.0/16 dev wlp2s0 scope link metric 1000 
 10.198.0.0/24 via 192.168.200.1 dev tun0 
 192.168.200.0/24 dev tun0 proto kernel scope link src 192.168.200.102

 192.168.178.0/24 dev wlp2s0 proto kernel scope link src 192.168.178.79 metric 600

  3. client openvpn.conf

     dev tun
 client
 nobind
 remote 11.22.33.44
 proto tcp
 port 1234
 ca /etc/openvpn/cacert.pem
 cert /etc/openvpn/user_cert.pem
 key /etc/openvpn/user
 comp-lzo
 verb 3
 keepalive 10 120
 log /var/log/openvpn.log

  4. ccd for client

    iroute 192.168.178.0 255.255.255.0

답변1

물론 VPN과 나머지 네트워크 간의 트래픽은 tun0. 이 트래픽의 경우 FORWARD체인은 평소와 같이 참조되며 누가 어디에 연결할 수 있는지 제어할 수 있습니다. 활성화되지 않으면 ip_forward트래픽이 전달되지 않습니다.

를 사용하지 않을 경우 client-to-client클라이언트 간 트래픽은 동일한 경로를 사용합니다. tun0인터페이스에서 서버 OS에 나타나고 OS 라우팅 테이블을 사용하여 적절하게 라우팅하고 방화벽을 통과하며 유일한 차이점은 대상이 뒤에 있다고 판단하므로 tun0패킷은 그것을 통해 나갔습니다.

OpenVPN 프로세스는 사용자 공간에 있고 tun0은 커널 공간에 있기 때문에 그다지 효율적이지 않으며 각 패킷에 대해 최소한 두 번의 컨텍스트 변경이 발생합니다.

그러나 를 사용 하면 client-to-client클라이언트 간의 패킷이 에 나타나지 않으며 tun0서버의 방화벽 FORWARD체인이 참조되지 않으며 ip_forward제어가 전달에 영향을 미치지 않습니다. OpenVPN 프로세스 자체는 호스팅 OS와 별개로 자체 라우팅 테이블을 갖춘 라우터가 됩니다. 관리 인터페이스 명령을 사용하여 이를 확인 status하거나 상태 파일에 덤프할 수 있습니다. 클라이언트의 파일이나 스크립트에서 생성된 동적 구성 iproute에서만 유효한 지시문을 사용하여 이 "라우터" 내의 경로를 제어할 수 있습니다 ("내부 경로"를 의미한다고 생각합니다).client-config-dir

가장 쉬운 것은 VPN을 특별한 것으로 생각하지 않는 것입니다. 터널이 설정되면 잊어버리십시오. 이제 이는 각 컴퓨터(서버 및 클라이언트)에 추가 일반 인터페이스일 뿐이며 모든 인터페이스는 일반 단순 라우터에 연결됩니다. 그리고 일반적인 라우팅 및 방화벽을 고려하십시오.

마침내 당신이 다음 주소로 ping을 보낸다는 것을 알았습니다.VPN 서버 자체다른 인터페이스에 할당되었지만. 이 패킷은전달되지 않을 예정어쨌든 목적지는 서버 자체이기 때문에 ip_forward이 패킷이 처리되는 방식에 영향을 주지 않으며 방화벽 체인을 통과 INPUT하고 응답이 통과됩니다 OUTPUT(예: FORWARD시스템 자체를 대상으로 하지 않는 경우 체인이 아님). 패킷은 시스템으로 들어가고 시스템에서 볼 수 있지만 전송되지 않기 때문에 tun0시스템에서는 볼 수 없습니다 . eth0현지에서 처리됩니다. 답변의 경우에도 마찬가지입니다.

시스템에서 주소가 할당된 위치(인터페이스) 또는 액세스하는 데 사용하는 시스템의 주소는 중요하지 않습니다(라우팅 관련 코드). 중요한 것은 그것이 시스템에 속하는지 아닌지입니다.

관련 보안 문제는 일부 사람들이 서비스를 일부 인터페이스에 할당된 일부 IP 주소에 바인딩하면 다른 인터페이스를 통해 이 서비스에 대한 액세스가 차단된다고 생각한다는 것입니다.이것은 잘못된 것입니다.다른 인터페이스 뒤에 있는 다른 시스템에 서비스가 바인딩된 IP로의 경로가 있는 경우에도 여전히수있을 것입니다서비스에 액세스합니다. 이는 서비스를 보호하는 올바른 방법이 아닙니다. 적절한 방화벽 설정이 필요합니다.

또 다른 관련 문제는 일부 사람들이 ping -I <local-address> <address-to-ping>또는 심지어 ping -I <interface> <address-to-ping>어떤 인터페이스 핑이 나갈지 직접 선택한다고 생각한다는 것입니다. 다시 말하지만 이것은 잘못된 것입니다. 이렇게 하면 다음 중 하나만 선택할 수 있습니다.소스 주소핑은 있지만 이를 보낼 인터페이스는 없습니다. 인터페이스는 패킷의 대상 주소만을 기반으로 하는 라우팅 테이블에 따라 엄격하게 라우팅 코드에 의해 선택됩니다. (VRF 또는 RPDB 설정이 수행되지 않은 것으로 추정하지만 이는 고급 기능이며 설정한 사람들은 어쨌든 이 기능에 대해 알고 있습니다. ).

관련 정보