☰

주어진 인터페이스(OpenVPN에서 생성된 `tun0`)를 통해 주어진 호스트에 연결할 수 있는지 확인합니다.

tag-icon • tag-icon networking ping tunneling
주어진 인터페이스(OpenVPN에서 생성된 `tun0`)를 통해 주어진 호스트에 연결할 수 있는지 확인합니다.

내 Linux 시스템에는 여러 네트워크 인터페이스가 있습니다. 일부는 물리적( eth0등)이고 일부는 가상( tun0예: OpenVPN에서 생성)입니다.

주어진 인터페이스를 통해 주어진 호스트(IP 주소)에 접근할 수 있는지 확인하는 것이 가능합니까?

ping-I인터페이스를 선택하는 옵션을 지원합니다 . 하지만 ping -I tun0 1.1.1.1작동하지 않습니다. 패킷을 받지 못합니다. tun0라우팅 테이블에서 해당 인터페이스를 게이트웨이로 설정하면 1.1.1.1에 도달할 수 있기 때문에 이는 놀라운 일입니다 .

tun0예를 들어 해당 경로의 호스트 게이트웨이를 변경하지 않고 1.1.1.1에 연결할 수 있는지 어떻게 확인할 수 있습니까 ?

자세한 내용은:저는 이 시스템을 사용하여 전체 네트워크에서 다양한 인터페이스를 통해 인터넷으로 트래픽을 전달하고 있습니다. 때때로 인터넷 접속 제공이 중단되는데, 제 목표는 이런 일이 발생할 때 인터페이스를 변경하는 스크립트를 작성하는 것입니다. 이를 더 잘 설정하는 방법에 대한 좋은 가이드/튜토리얼이 있으면 기꺼이 읽어보겠습니다.

내 시스템 상태를 표시하는 일부 명령의 출력은 다음과 같습니다(개인 정보 보호를 위해 다소 다듬어지고 편집됨).

# ping -c1 -W1 1.1.1.1 -Ieth0 | tail -n2
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 8.997/8.997/8.997/0.000 ms
# ping -c1 -W1 1.1.1.1 -Itun0 | tail -n2
1 packets transmitted, 0 received, 100% packet loss, time 0ms

# ping -c1 -W1 1.1.1.1 -Itun1 | tail -n2
1 packets transmitted, 0 received, 100% packet loss, time 0ms

# ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
eth0             UP             01:23:45:67:89:ab <BROADCAST,MULTICAST,UP,LOWER_UP> 
tun1             UNKNOWN        <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> 
tun0             UNKNOWN        <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> 

# ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
12: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    inet 172.16.1.8 peer 172.16.1.9/32 scope global tun1
       valid_lft forever preferred_lft forever
13: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    inet 172.16.0.6 peer 172.16.0.5/32 scope global tun0
       valid_lft forever preferred_lft forever

# ip route
10.0.0.0/22 via 172.16.0.5 dev tun0 
2.3.4.5 via 192.168.1.2 dev eth0 
172.16.0.0/24 via 172.16.0.5 dev tun0 
172.16.0.5 dev tun0 proto kernel scope link src 172.16.0.6 
172.16.1.0/24 via 172.16.1.9 dev tun1 
172.16.1.9 dev tun1 proto kernel scope link src 172.16.1.8 
192.168.0.0/16 via 172.16.1.9 dev tun1 
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 
1.2.3.4 via 192.168.1.2 dev eth0 

# ip rule
0:      from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 
40000:  from 192.168.0.0/28 lookup physical 
500000: from all iif lo lookup physical 
600000: from 192.168.0.4 lookup physical 
900000: from all lookup fallback 

# ip -details link show dev tun0
13: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 100
    link/none  promiscuity 0 
    tun numtxqueues 1 numrxqueues 1 

# ip -details link show dev tun1
12: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 100
    link/none  promiscuity 0 
    tun numtxqueues 1 numrxqueues 1 


# iptables-save -c
# Generated by iptables-save v1.6.2 on Tue Sep  5 10:15:50 2023
*filter
:INPUT ACCEPT [59898142:66144679517]
:FORWARD ACCEPT [82206554:78274304851]
:OUTPUT ACCEPT [26945751:6646653799]
COMMIT
# Completed on Tue Sep  5 10:15:50 2023
# Generated by iptables-save v1.6.2 on Tue Sep  5 10:15:50 2023
*nat
:PREROUTING ACCEPT [2568037:216846789]
:INPUT ACCEPT [2278788:177840950]
:OUTPUT ACCEPT [853479:59465416]
:POSTROUTING ACCEPT [0:0]
[1133282:97570449] -A POSTROUTING -j MASQUERADE
COMMIT
# Completed on Tue Sep  5 10:15:50 2023

# sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -j MASQUERADE

# ip route show table default

# ip route show table physical
default via 192.168.1.2 dev eth0 proto static 

# ip route show table fallback
default via 172.16.0.5 dev tun0 metric 5 
default via 172.16.1.9 dev tun1 metric 10

답변1

설정

OP의 정책 라우팅 설정이 특이합니다.

  • 규칙 위에 규칙은 없습니다기본테이블

  • 이에 비해 메인 테이블에는 기본 경로가 없으며,

  • 추가 규칙을 평가하고뒤쪽에기본 테이블

  • 호스트에 대한 실제 중요한 라우팅 규칙은 다음과 같습니다. 500000: from all iif lo lookup physical

    이는 호스트(트래픽 전달이 아닌 로컬 노드)에 대한 첫 번째 규칙이므로 INADDR_ANY(0.0.0.0/0 경로와 일치하는 주소 0.0.0.0)와 일치하므로 모든(TCP, UDP, ICMP...) 클라이언트 쿼리가 주소나 인터페이스에 바인딩되지 않았습니다.이더넷 0.

  • 동일한 브로드캐스트 도메인을 공유하는 두 개의 네트워크를 사용하여 수행된 단일 암 라우팅에 대해서는 의견이 없습니다.이더넷 0, 문제와 관련이 없습니다.

이 설정의 주요 목적은 호스트 자체 트래픽과 (너무 많이) 상호 작용할 필요 없이 호스트의 트래픽이 앞뒤로 라우팅되어 인터넷에 도달할 수 있도록 하는 것입니다 tun1. tun0나는 동일한 작업을 수행하는 더 쉽고 더 표준적인 방법이 있어야 한다고 생각하지만 그것이 설정입니다.

라우팅 문제 감지

커널 라우팅 스택의 각 선택은 다음 명령으로 확인할 수 있습니다.ip route get:

ip route get

단일 경로 가져오기

이 명령은 대상까지의 단일 경로를 사용하고 커널이 보는 것과 정확하게 그 내용을 인쇄합니다.

인터페이스에 바인딩할 때(사용SO_BINDTODEVICE), 추가 선택기를 통해 강제 라우팅 효과를 쿼리할 수 있습니다.oif.

패킷 전송:

# ip route get oif tun0 to 1.1.1.1
1.1.1.1 via 172.16.0.5 dev tun0 table fallback src 172.16.0.6 uid 0 
    cache

루트가 있으므로,TCP 덤프나가는 패킷이 표시되어야 합니다.Tun0상호 작용.

복귀 경로,첫눈에, 또한 작동해야 합니다:

# ip route get from 1.1.1.1 iif tun0 to 172.16.0.6
local 172.16.0.6 from 1.1.1.1 dev lo table local 
    cache <local> iif tun0

그리고TCP 덤프반환 패킷도 캡처됩니다.

하지만 만약에rp_filter=1이미 사용 가능엄격한 역방향 경로 전달(SRPF)는 다음과 같이 변경됩니다.

# ip route get from 1.1.1.1 iif tun0 to 172.16.0.6
RTNETLINK answers: Invalid cross-device link

응답 패킷(아직 캡처되었지만)TCP 덤프라우팅 스택에 의해 삭제됩니다.평평한실패하다.

따라서 흔하지 않은 라우팅 설정에서는 반환 경로가 사용된 경로 rp_filter=1와 일치할 것으로 예상하므로 이러한 라우팅은 비대칭 라우팅으로 간주된다고 가정할 수 있습니다.500000: from all iif lo lookup physical이더넷 0. 이 패킷이 보여주듯이Tun0대신에이더넷 0, SRPF 검증에 실패했습니다. 사실은평평한라우팅 스택이 SRPF 인증을 사용하는 경우 프로세스가 실제로 인터페이스에 바인딩되어 있는지는 중요하지 않습니다.왕복 교통.

고치다

oif tun0SRPF 기능을 유지하려면 172.16.0.6에서 최종적으로 선택한 소스 주소와 일치하는 라우팅 규칙을 추가해야 합니다. 기본 설정은 500000 미만의 값일 수 있습니다(이후이더넷 0SRPF 알고리즘의 구현을 만족시키기 위해 선택됩니다.

ip rule add from 172.16.0.6 lookup fallback

이제 우리는 (여전히 rp_filter=1) 다음을 얻습니다.

# ip route get from 1.1.1.1 iif tun0 to 172.16.0.6
local 172.16.0.6 from 1.1.1.1 dev lo table local 
    cache <local> iif tun0

의미: 명령을 통해 로컬 사용을 위한 패킷을 수락하고 수신합니다 ping.

또한 인터페이스에 바인딩하지 않고 주소에만 작업할 수 있습니다.

ping -I 172.16.0.6 1.1.1.1

실제로 이전에도 있었습니다.

# ip route get from 172.16.0.6 to 1.1.1.1
1.1.1.1 from 172.16.0.6 via 192.168.1.2 dev eth0 table physical uid 0 
    cache

터널은 사용되지 않습니다.

하지만:

# ip route get from 172.16.0.6 to 1.1.1.1
1.1.1.1 from 172.16.0.6 via 172.16.0.5 dev tun0 table fallback uid 0 
    cache

또는 라우팅 규칙이 변경되지 않도록 위의 규칙 대신 사용할 터널 인터페이스를 설정할 수 있습니다.느슨한 RPF어느우선 사항SRPF를 통해:

sysctl -w net.ipv4.conf.tun0.rp_filter=2

이를 통해 (가정된) 비대칭 라우팅에도 불구하고 RPF 검사를 통과할 수 있습니다. 이를 통해 ping -I tun0 1.1.1.1다른 라우팅 변경 없이 ping이 작동할 수 있었습니다 (그러나 더 이상 사용되지 않습니다 ping -I 172.16.0.6 1.1.1.1.이더넷 0이전과 같이 다시 선택합니다(위 참조).

또한 사용할 수 있습니다화 1. 누구나:

ip rule add from 172.16.1.8 lookup fallback

또는:

sysctl -w net.ipv4.conf.tun1.rp_filter=2

관련 정보