☰

이 라우팅 설정이 작동하지 않는 이유는 무엇입니까?

tag-icon • tag-icon linux routing linux-networking
이 라우팅 설정이 작동하지 않는 이유는 무엇입니까?

서버 컴퓨터에 두 개의 인터페이스가 있습니다. 출력은 ip route다음과 같습니다.

default via 192.168.100.1 dev enp1s0 proto static metric 100
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.1
192.168.100.0/24 dev enp1s0 proto kernel scope link src 192.168.100.201 metric 100

다음 은 ip address다음입니다(MAC는 숨겨짐).

...
1: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.201/24 brd 192.168.100.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::1409:66c6:eb0d:22a1/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::85:5fff:fe98:6cb7/64 scope link
       valid_lft forever preferred_lft forever

값 /proc/sys/net/ipv4/ip_forward은 1입니다. 방화벽이 비활성화되었습니다.

내가 원하는 것은 액세스하는 것입니다192.168.100.1~에서10.8.0.100. 웹 서버(이 시스템의 모든 포트를 수신하고 있음)에 액세스하면 curl --interface 10.8.0.100 http://10.8.0.1정상적으로 작동합니다. 그러나 curl --interface 10.8.0.100 http://192.168.100.201출력은 Network unreachable.

Curl은 TCP 핸드셰이크를 시작하고 패킷을 푸시합니다.10.8.0.100상호 작용. 그런 다음 패킷은 서버 시스템에 도달합니다.10.8.0.1. 서버는 패킷 대상을 조사하여 그것이 맞는지 확인합니다.192.168.100.201. 그런 다음 라우팅 테이블을 살펴보고 다음을 확인합니다.192.168.100.201지역적이다. 이제 답이 돌아오고 있습니다. 보낸 사람은 다음과 같습니다.10.8.0.100. 라우팅 테이블을 살펴보면 tap0로컬인 를 통해 액세스할 수 있음을 알 수 있습니다. 이제 tap010.8.0.100에 도달합니다.

하지만 실제로는 -그렇지 않다. 내 생각의 흐름이 잘못되었기 때문일까? 설명된 표에서 제공하는 정보는 패킷 전달 방법을 결정하는 데 충분하다고 생각했습니다. 실제로는 불완전한가요?

답변1

우선, -I 매개변수를 사용하여 IP 주소 및 인터페이스를 ping동의어가 아닙니다. 먼저 무엇을 source IP선택할지 알려줍니다. 로컬 주소 및 라우팅 테이블을 포함하여 순 흐름에 따라 라우팅합니다. 두 번째는 패킷을 보낼 인터페이스를 직접 선택하도록 지시합니다(그리고 첫 번째 할당된 IP를 소스로 선택합니다).

다음으로 당신이 하고 있는 일은 패킷 전달과 아무 관련이 없습니다. 전달이란 패킷이 실제로 "외부"에서 도착해야 함을 의미합니다. 이 호스트에서 패킷을 생성하면 전달이 필요하지 않습니다. 로컬에서 생성된 패킷입니다. 대상 IP는 핑이 특정 인터페이스 "외부"(옵션 포함)로 패킷을 보내도록 강제하지 않을 때 로컬로 할당된 주소 중 하나이므로 -I interface커널은 이 패킷 흐름을 내부적으로 처리합니다. 목적지가 "이미 여기에" 있으므로 실제 인터페이스로 출력하려고 시도하지 않습니다. 그래서 이것이 일어나는 일이고 왜 그것이 어떤 경우에서는 작동하고 다른 경우에서는 작동하지 않는 이유입니다.

추신: 또한 수행 중이고 두 인터페이스가 모두 동일한 브로드캐스트 도메인에 연결되어 있다는 것을 알고 있는 경우 도구 -r의 옵션을 확인하십시오 (TAP 인터페이스에서는 이것이 의심됩니다).ping

답변2

문제는 --interface IP과 의 차이를 오해한 데 있었습니다 --interface dev. 첫 번째는 라우팅 테이블을 사용합니다.

패킷 은 인터페이스(이 IP가 속한) --interface 10.8.0.100로 전달되지 않습니다 . 대신 라우팅 테이블에 따라 (LAN 인터페이스) tap0로 전달됩니다 . 192.168.100.58따라서 경로는 입니다 10.8.0.100 -> 192.168.100.58 -> 192.168.100.201. SYN이 전달되었다는 사실에도 불구하고 서버는 이상하게 SYN-ACK로 응답하지 않습니다. 이것이 컬 실패의 이유입니다.

즉, 링크 레이어 주소를 사용하면 --interface tap0의도한 대로 작동합니다 10.8.0.100 -> 10.8.0.1 -> 192.168.100.201. SYN-ACK는 동일한 경로를 사용하여 다시 전달됩니다.

관련 정보