☰

더블 홉 VPN - LAN 트래픽만 볼 수 있고 인터넷은 볼 수 없습니다.

tag-icon • tag-icon debian iptables vpn openvpn
더블 홉 VPN - LAN 트래픽만 볼 수 있고 인터넷은 볼 수 없습니다.

TLDR: 라즈베리 파이의 이중 홉 VPN. VPN을 통해 로컬 장치의 Samba 공유를 SSH로 연결하고 볼 수 있습니다. VPN을 통해 인터넷 트래픽을 얻을 수 없습니다. 진행 방법을 잘 모르겠습니다.

내 설정은 단일 Raspberry Pi를 실행 openvpn하고 pi-hole. openvpn의 두 가지 인스턴스가 있습니다.

  • server.conf- VPN 호스트 이상 tun-incoming. 작동 중입니다. 에서 VPN DNS 요청을 볼 수 있습니다 pi-hole.
  • outgoing.conf- 을(를) 통해 VPN 공급업체에 연결합니다 tun-outgoing. 현지에서 일합니다. 새로운 IP를 볼 수 있어요.

나는 주로 이 가이드를 따르고 있습니다.https://www.comparitech.com/blog/vpn-privacy/raspberry-pi-vpn/ 아이디어는 (1) 내 로컬 네트워크의 192.168.*.*에 있는 모든 장치에서 SSH를 통해 공유 파일 등을 볼 수 있고 (2) VPN 공급업체를 통해 인터넷이 터널링될 수 있어야 한다는 것입니다. 첫 번째 사용 사례는 잘 작동합니다.

나는 가이드에 따라 이것을 시도했습니다.

ip rule add from 192.168.1.166 lookup 101
ip route add default via 192.168.1.1 table 101

그 후 .NET을 통해 SSH를 연결하는 기능을 잃었습니다 ipv4.

다음은 몇 가지 관련 출력입니다.

IP 경로 목록

pi@raspberrypi2:~ $ ip route list
0.0.0.0/1 via 10.1.11.5 dev tun-outgoing
default via 192.168.1.1 dev eth0 src 192.168.1.166 metric 202
10.1.11.1 via 10.1.11.5 dev tun-outgoing
10.1.11.5 dev tun-outgoing proto kernel scope link src 10.1.11.6
10.8.0.0/24 dev tun-incoming proto kernel scope link src 10.8.0.1
128.0.0.0/1 via 10.1.11.5 dev tun-outgoing
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.166 metric 202
199.229.249.184 via 192.168.1.1 dev eth0

IP 규칙 목록

pi@raspberrypi2:~ $ ip rule list
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

iptables -t nat -S

pi@raspberrypi2:~ $ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -m comment --comment openvpn-nat-rule -j MASQUERADE

ifconfig

pi@raspberrypi2:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.166  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2604:2000:6aa0:c0d0::307  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::7a09:12ee:27ff:f6fc  prefixlen 64  scopeid 0x20<link>
        inet6 fd38:2d6b:a55b::111  prefixlen 128  scopeid 0x0<global>
        inet6 fd38:2d6b:a55b::307  prefixlen 128  scopeid 0x0<global>
        inet6 fd38:2d6b:a55b:0:3ed3:ce3b:88db:5070  prefixlen 64  scopeid 0x0<global>
        inet6 2604:2000:6aa0:c0d0:70cf:5710:52e:373e  prefixlen 64  scopeid 0x0<global>
        ether dc:a6:32:65:73:5d  txqueuelen 1000  (Ethernet)
        RX packets 48570  bytes 8636380 (8.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 55906  bytes 34181320 (32.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 331  bytes 27074 (26.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 331  bytes 27074 (26.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun-incoming: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.1  netmask 255.255.255.0  destination 10.8.0.1
        inet6 fe80::a8c2:d1fa:b798:f945  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 432 (432.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun-outgoing: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.1.11.6  netmask 255.255.255.255  destination 10.1.11.5
        inet6 fe80::9fe5:8e1:b1c0:86c5  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 24200  bytes 3403386 (3.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 30214  bytes 29464427 (28.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:65:73:5e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

답변1

TL;DRIP 규칙이 필요하지 않습니다. 여기서 필요한 것은 tun-outgoing인터페이스로 나가는 패킷에 대한 또 다른 NAT 규칙입니다.

설명: 무슨 일이 일어나고 있는지는 VPN 제공업체 라우터(예: 10.1.11.5 dev tun-outgoing)가 다시 연결하는 방법을 모르기 10.8.0.0/24때문에 패킷이 삭제되거나 손실된다는 것입니다.

10.8.0.0/24이는 라우터가 네트워크를 알고 있지만(즉, 라우팅 테이블에 있음을 의미) raspberrypi2동일한 VPN에 속하지 않은 다른 호스트(예: LAN 호스트 및 외부 VPN 공급자)에서는 이를 알 수 없기 때문입니다 .

언급하신 두 번째 사용 사례(VPN 공급자를 사용하여 인터넷 서핑)만 살펴보면,이론에 의하면이 문제를 해결하는 방법에는 두 가지가 있습니다.

  1. VPN 내부에서 도달해야 하는 각 호스트의 경로를 (정적으로/자동으로) 구성하여( tun-incoming)
  2. 또는 NAT를 사용하여 IP를 마스킹합니다.

첫 번째 방법은 당연히~ 아니다외부 행위자(VPN 제공자)가 있는 경우 가능하므로 다음과 같은 NAT 규칙을 생성해야만 이 문제를 해결할 수 있습니다.

-A POSTROUTING -s 10.8.0.0/24 -o tun-outgoing -j MASQUERADE

이 규칙은 VPN 공급자가 알고 있는 의 10.8.0.0/24(소스) IP 주소를 사용하여 VPN을 통해 VPN에서 인터넷으로 의 모든 연결을 마스킹합니다 .raspberrypi2

첫 번째 사용 사례(LAN 액세스): 첫 번째 사용 사례의 경우 NAT 방법을 계속 사용할 수 있지만 실제로는 방법 2도 적용할 수 있습니다. 이를 적용하려면 raspberrypi2LAN의 기본 게이트웨이인 경우 NAT 규칙을 제거하기만 하면 모든 것이 제대로 작동합니다.

그렇다면rasperrypi2​~ 아니다LAN의 기본 게이트웨이인 경우에도 다음을 수행하여 방법 2를 적용할 수 있습니다.

  • LAN의 현재 기본 게이트웨이에서 고정 경로 구성
  • 또는 다음에서 정적 경로를 구성합니다.각LAN의 호스트

(둘 다 분명히 raspberrypi2서브넷만을 가리킵니다 10.8.0.0/24).

관련 정보