☰

기본적으로 VPN 및 나머지 AP를 통해 라우팅

tag-icon • tag-icon networking
기본적으로 VPN 및 나머지 AP를 통해 라우팅

저는 이더넷 인터페이스(eth0)가 있는 Orangepi(armbian)를 가지고 있는데, 여기에 AccessPoint용 인터페이스(wlan0)를 설정하고 VPN 클라이언트(tun0)를 설치했습니다. 목표는 다음과 같습니다. wlan0 AP의 모든 트래픽은 VPN(tun0)으로 전달되고 그 반대도 마찬가지입니다. 시스템 프로세스, 프로그램 등의 모든 트래픽은 기본적으로 192.168.1.1 ISP 대상으로 라우팅됩니다.

                     -------------------
                     |                 |
       10.8.3.2/24---|tun0       wlan0 |----192.168.2.1/24
   192.168.1.31/24---|eth0             |    WIFI AP
                     |                 |
                     -------------------

전달을 활성화했습니다: net.ipv4.ip_forward=1

그리고 iptables에 규칙을 추가하세요: iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

결과: AP를 통한 액세스는 잘 작동하고 VPN을 통한 라우팅은 항상 잘 작동합니다.

문제: 모든 트래픽은 VPN을 통해 라우팅됩니다. 프로세스에서 생성된 트래픽은 기본 192.168.1.1을 통해 라우팅됩니다.

터미널에서 ping, 경로 추적 등을 수행하면 tun0이 라우팅되고 tun0의 10.8.3.2를 소스 IP로 할당하는 이유를 이해합니다. 그게 문제인 것 같습니다. eth0의 192.168.1.31을 할당하면 기본 192.168을 라우팅합니다. . 1.1이 해결되었습니다.

VPN 클라이언트 생성 기본값:

  0.0.0.0         10.8.3.1        128.0.0.0       UG        0 0          0 tun0

삭제해도 모든 것이 그대로 유지됩니다.

기본적으로 나머지 트래픽을 192.168.1.1 ISP 대상으로 라우팅하려면 무엇을 구성해야 합니까?

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.8.3.1        128.0.0.0       UG        0 0          0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0
10.8.3.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
128.0.0.0       10.8.3.1        128.0.0.0       UG        0 0          0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 wlan0
178.239.165.30  192.168.1.1     255.255.255.255 UGH       0 0          0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0

eth0: flags=4163 <UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.31  netmask 255.255.255.0  broadcast 192.168.1.255
ether 02:81:91:07:0c:a5  txqueuelen 1000  (Ethernet)

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>

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
inet 10.8.3.2  netmask 255.255.255.0  destination 10.8.3.2
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.2.1  netmask 255.255.255.0  broadcast 192.168.2.255
ether 00:e0:4c:81:79:8a  txqueuelen 1000  (Ethernet)

답변1

참고: Linux에서는 더 이상 사용되지 않고 더 이상 사용되지 않는 Linux 커널 API를 사용하므로 더 이상 Linux에서 사용해서는 ifconfig안 됩니다 . , 및 (뿐만 아니라 from) route로 대체되어야 합니다.ip linkip addrip routeIP 경로 2모음곡).

정책 기반 라우팅이는 Linux에서 더 이상 사용되지 않는 명령을 사용하여 달성할 수 없습니다.IP 경로 2제품군 명령.

현재 라우팅 설정은 기본 경로 대신 두 개의 "반기본" 경로를 사용하여 원래 기본 경로를 재정의합니다(예 def1:서버 푸시 라우팅또는클라이언트가 이를 재정의합니다.), 실제 VPN 경로는 다음과 같습니다.

  0.0.0.0         10.8.3.1        128.0.0.0       UG        0 0          0 tun0
  128.0.0.0       10.8.3.1        128.0.0.0       UG        0 0          0 tun0

그리고 기본 경로보다 좁기 때문에 모든 대상에 대한 기본 경로를 재정의합니다(터널 엔벨로프에 대한 라우팅 루프를 피하기 위해 명시적으로 추가된 VPN 원격 끝점과 같은 다른 경로 항목에서는 제외).

따라서 첫 번째 항목을 제거하는 것만으로도 인터넷의 약 절반에 여전히 영향을 미칩니다(예: www.armbian.com5.161.66.254로 확인되면 더 이상 터널을 통해 연결할 수 없지만 www.debian.org128.31.0.62로 확인되면 도달하게 됩니다). 물론 둘 다 제거하면 터널이 어느 정도 비활성화됩니다. 이러한 작업은 호스트에 영향을 미칩니다.그리고후속 노드무선랜 0.

여기서 정책 기반 라우팅을 사용하면 라우팅/전달된 트래픽과 호스트 자체에서 발생하는 트래픽을 구별하여 서로 다른 라우팅 결과를 얻을 수 있습니다.

OP의 목표는 호스트 뒤(LAN 뒤)의 노드가 VPN을 사용하도록 하는 것입니다.무선랜 0) 호스트 자체는 아닙니다. 현재 설정에 다른 변경 사항을 적용할 필요가 없습니다. 이 작업은 정책 라우팅 규칙을 통해 수동으로 수행할 수 있습니다. + 현재 적용되는 경로 테이블 재정의: CIDR 0(0.0.0.0/0) 또는 1(0.0)을 무시하는 호스트에만 적용됩니다. .0.0 /1 및 128.0 .0.0/1: OpenVPN정의 1방법)을 선택하고 새 기본 경로를 다시 할당합니다(이것이 원래 기본 경로가 됩니다).

이 문제를 해결하려면 다음 3가지 명령으로 충분합니다.:

ip route add default via 192.168.1.1 dev eth0 table 1000
ip rule add pref 1000 iif lo lookup main suppress_prefixlength 1
ip rule add pref 1001 iif lo lookup 1000

이는 다음을 수행합니다.

  • 호스트 자체에서만 작동하지만( 호스트가 시작한 트래픽에 대한 특수 구문) 라우팅/전달된 트래픽에서는 작동하지 않습니다( 어디에서 오는지에 따라 iif lo일치하거나 다름) . 기본 라우팅 테이블은 경로가 그렇지 않을 때마다 경로를 검색하는 데 사용됩니다. 기본 경로 또는 두 개에서 옵니다.iif wlan0iif eth0iif tun0정의 1"반기본" 경로입니다. 감사합니다.suppress_prefixlength억제기.

  • 여전히 호스트 자체에 대해서만 작동합니다. 경로가 발견되지 않으면 라우팅 테이블 1000에 중복된 원래 기본 경로가 사용됩니다.

    따라서 기본적으로 호스트는 VPN을 사용하지 않고 인터넷에 액세스할 수 있습니다.

게다가:

  • 라우팅/전달된 트래픽은 이 설정의 영향을 받지 않습니다.

    따라서 VPN을 통한 인터넷 연결은 이전과 같이 계속됩니다.

  • 호스트 자체로 반환되는 트래픽은 항상 먼저 다음에서 처리됩니다.현지의따라서 라우팅 테이블은 이 설정의 영향을 받지 않습니다. 실제로 기본 설정 0의 첫 번째 라우팅 규칙은 다음을 처리합니다.현지의라우팅 테이블은 아래와 같습니다.

    # ip rule
0:      from all lookup local
1000:   from all iif lo lookup main suppress_prefixlength 1
1001:   from all iif lo lookup 1000
32766:  from all lookup main
32767:  from all lookup default

  • 호스트는 평소와 같이 VPN을 사용하여 10.8.3.0/24의 노드에 도달하거나 무선으로 192.168.2.0/24의 노드에 도달할 수 있습니다. 왜냐하면 호스트의 경로에는 CIDR이 1보다 나은 24가 있기 때문입니다. 억제.

참고: 인터페이스가이더넷 0관리상 삭제된(그리고 다시 올라온) 라우팅 테이블 1000의 항목은 삭제될 것이므로 다음과 같이 다시 넣어야 합니다.기본라우팅 테이블: 이는 다음에 통합되어야 합니다.이더넷 0시작 시 설정하는 대신 인터페이스 설정을 수행합니다.

물론 게이트웨이에 대한 명시적인 지식이 필요하지 않거나 이 작업을 자동으로 수행하는 다른 방법도 있지만 VPN 설정이 필요할 수 있습니다. 이러한 명령은 VPN 도구(변수로 게이트웨이를 제공할 수 있음)를 통해 스크립트로 실행될 수 있으며, VPN 구성을 통해 이 문제에 대한 직접적인 솔루션을 제공할 수도 있습니다. 나는 존재하는 정보를 알 방법이 없습니다.

관련 정보