☰

들어오는 인터페이스를 기반으로 IP/32에서 NIC로 응답 패킷 라우팅

tag-icon • tag-icon ssh route traffic
들어오는 인터페이스를 기반으로 IP/32에서 NIC로 응답 패킷 라우팅

서로 다른 서브넷에 2개의 네트워크 카드가 있는 Rhel 8.7 시스템이 있습니다. 이렇게 놔두세요 eth1-IP:10.10.10.4/24 ,gateway:10.10.10.1. 이 게이트웨이는 두 번째 NIC뿐만 아니라 이 가상 머신의 기본 게이트웨이이기도 합니다 eth2, IP:10.10.20.2 , gateway:10.10.20.254.

상태: 이 컴퓨터에는 여러 개의 고정 경로가 구성되어 있으며, 내 생각에는 기본 라우팅 테이블에 어떤 식으로든 중단하고 싶지 않은 경로가 있는 것 같습니다.

두 네트워크 카드 모두 SSH를 통해 연결해야 하는 특정 IP(10.10.30.33)가 있습니다(icmp도 테스트에 허용되고 사용됩니다). eth1에 기본 게이트웨이가 있으므로 다른 서브넷에 있는 이 IP는 수정 없이 eth1 IP: 10.10.10.4에 완벽하게 연결할 수 있지만 eth2: 10.10.20.2에는 연결할 수 없습니다. 응답 패킷이 기본 게이트웨이 대신 eth2 게이트웨이를 통과하도록 전환하도록 고정 경로를 설정하면 액세스는 가능하지만 기본 게이트웨이에 대한 인터페이스는 더 이상 가능하지 않으며 고정 경로를 추가하기 전의 연결은 작동했습니다.

표적: 들어오는 인터페이스의 특정 IP를 기반으로 응답 트래픽만 라우팅합니다. 10.10.30.33이 10.10.10.4에 도달하려고 하면 eth1에서 응답을 보내야 하고, 10.10.20.2에 도달하려고 하면 응답 패킷을 eth2에서 보내야 합니다. 기본적으로 10.10.30.33이 두 시스템 인터페이스에 모두 액세스할 수 있기를 바랍니다.

답변1

긴 이야기 짧게

10.10.30.33에서만 멀티홈 설정이 작동하도록 하려면 다음 3가지 명령을 실행하십시오.

ip route add 10.10.20.0/24 dev eth2 table 1002
ip route add default via 10.10.20.254 dev eth2 table 1002
ip rule add from 10.10.20.2 to 10.10.30.33 iif lo lookup 1002

상해

이것이 필요하다정책 라우팅, 기본적으로 Linux는 기본 라우팅 테이블에서 메트릭이 가장 낮은 기본 경로만 사용하기 때문입니다. 정책 라우팅을 사용하면 대체 결과를 선택하는 라우팅 규칙 선택기에 따라 대체 기본 경로가 있는 대체 경로 테이블을 사용할 수 있습니다. 대부분의 경우 선택기는 소스(대상이 아님: 경로로 충분함)와 관련되어 있지만 OP는 10.10.30.33만 다른 동작을 트리거해야 한다고 명시적으로 지정했으므로 10.10.30.33에 관한 추가 선택기 경로도 사용됩니다. .

NetworkManager를 사용하여 RHEL 8에서 이 기능을 올바르게 통합하거나 더 이상 사용되지 않는 방법을 사용하려면 /etc/sysconfig/network-scripts/(NetworkManager가 설치된 경우 이전 방법이 작동하는지 알 수 없습니다):

10.10.30.33으로 제한되지 않는 일반적인 멀티호밍 사용의 경우 간단히 to 10.10.30.33.

  • 사용 중인 경로만 백업 라우팅 테이블 1002에 없는 eth2것처럼 복사됩니다(값 1002는 무작위로 선택됨).eth1

    ip route add 10.10.20.0/24 dev eth2 table 1002
ip route add default via 10.10.20.254 dev eth2 table 1002

  • 10.10.20.2에서 로컬로 시작된 트래픽(응답 포함)에 대해 대체 경로 테이블 1002를 선택하려면 라우팅 규칙을 사용합니다.

    ip rule add from 10.10.20.2 to 10.10.30.33 iif lo lookup 1002

    통합이 용이하다면 대부분의 경우 iif lo필요하지 않으며 규칙에서 제거할 수 있습니다.

  • 다음 규칙은 다음과 같은 경우에만 필요합니다.

    • ping -I eth2 10.10.30.33IP 주소( ping -I 10.10.20.2 10.10.30.33) 가 아닌 인터페이스(예: : )에만 바인딩하는 경우
    • 기본 라우팅 테이블에 이 결합된 인터페이스를 사용하는 기본 경로가 없는 경우(선택한 기본 경로보다 메트릭이 더 높음) 이 경로가 없으면 이 인터페이스에 대한 기본 경로가 강제로 적용되지만 게이트웨이가 없으면 올바른 경로가 사용되지 않습니다(증상: 시스템이 다른 네트워크로 ARP를 보냅니다).
    • 연결되지 않은 모드(예: 호출이 사용되지 않음)의 ICMP 클라이언트 또는 UDP 클라이언트에만 해당됩니다. connect(2)대부분의 설정에서 올바른 소스 IP 주소는 다음에서 설정됩니다.기본소켓이 사용되는 경우 주소는 소스의 라우팅 테이블을 암시하도록 설정됩니다 connect(2). 이전 라우팅 규칙은 방출될 때 어쨌든 트리거됩니다.

     

    ip rule add to 10.10.30.33 oif eth2 lookup 1002

    OP가 실제로 두 번째 기본 경로를 추가한 것 같습니다.

    두 번째 네트워크 카드: eth2, IP: 10.10.20.2,게이트웨이:10.10.20.254

    그러면 위의 규칙은 더 이상 필요하지 않습니다.기본라우팅 테이블은 충분합니다.

    eth2많은 설정에서는 대체 인터페이스( )에 대해 정의된 기본 경로가 없으므로 이 규칙이 유용합니다.

  • 들어오는 트래픽에는 특정 규칙이 필요하지 않습니다. 들어오는 패킷에 대한 경로 조회가 조기에 처리됩니다.현지의라우팅 테이블.

    이는 트래픽을 라우팅하는 데 필요할 수 있습니다. 예를 들어 다음과 같습니다.기계가상 머신 또는 컨테이너를 실행합니다. OP는 이에 대해 언급하지 않았습니다. 어쨌든 여기에는 더 자세한 내용이 필요하며 Netfilter(iptables또는nftables)은 라우터 인클로저에 적합합니다.

이제부터 시스템 10.10.30.33은 10.10.10.4 또는 10.10.20.2로 ssh 또는 ping을 수행할 수 있어야 합니다. 마찬가지로(방화벽 차단이 없는 경우) 듀얼 호머는 인터페이스 eth2(예 : 또는 ) 또는 주소 10.10.20.2에 바인딩하여 10.10.30.33( 예: ping -I eth2 10.10.30.33또는 )에 액세스하도록 선택할 수 있으며 일반적으로 기본 라우팅의 기본 설정을 사용합니다. 테이블 .ssh -B eth2 10.10.30.33ping -I 10.10.20.2 10.10.30.33ssh -b 10.10.20.2 10.10.30.33

동등한 구성은 eth1기본 라우팅 테이블에서 이미 올바르게 처리되었으므로 선택 사항입니다. 또한 다음을 수행합니다.

ip route add 10.10.10.0/24 dev eth1 table 1001
ip route add default via 10.10.10.1 dev eth1 table 1001
ip rule add from 10.10.10.4 to 10.10.30.33 iif lo lookup 1001

참고: UDP 서비스

기본적으로UDP 응답은 들어오는 쿼리에 대한 로컬 시스템의 IP 주소나 인터페이스가 무엇인지 알기 위해 컨텍스트를 상속하지 않습니다. 따라서 기본적으로 UDP 소켓이 INADDR_ANY(0.0.0.0)에 바인딩되면 0.0.0.0이 경로, 인터페이스 및 너무 늦은 소스 IP 주소를 확인하기 위해 네트워크 스택에 제공되는 초기 소스 주소가 됩니다. 이는 10.10.20.2가 다음 규칙에 제공되지 않기 때문에 이전 라우팅 규칙 중 어느 것도 일치하지 않음을 의미합니다.기본인터페이스는 여전히 선택 가능합니다. 인터페이스가 알려지면 해당 인터페이스에 대해 적절한 IP 주소가 선택되며, 기본적으로 선택한 인터페이스의 라우팅 기본 IP 주소가 됩니다. 이는 멀티호밍 인식을 지원하지 않는 UDP 서비스가 eth110.10.20.2에 대한 요청을 수신할 때(LAN 10.10.20.0/24에서 오는 경우를 제외하고) 여전히 잘못된 인터페이스( ) 및 주소(10.10.10.4)로 응답한다는 의미입니다. 일하다). 이 동작은 Linux에만 국한되지 않고 비슷한 이유로 약한 기능을 사용하는 다른 운영 체제에도 영향을 미칠 수 있습니다.호스트 모델및 BSD 소켓 API.

이러한 UDP 서비스가 두 인터페이스에서 액세스되어야 하는 경우 이 문제를 해결하는 두 가지 방법이 있습니다.

  • 대신 각 주소에 명시적으로 바인딩합니다 INADDR_ANY. 예를 들어 HTTP/3 서비스가 UDP 포트 80을 사용하는 경우 0.0.0.0:80에 바인딩하는 대신 두 개의 별도 소켓 바인딩을 사용하도록 구성해야 합니다. 10.10.10.4: 80 및 10.10.20.2:80. 이 경우 UDP 소켓을 통한 응답은 바인딩된 주소를 소스로 선택하여 올바른 라우팅 규칙과 인터페이스를 트리거합니다. 예를 들어, DNS 서버가 일반적으로 수행하는 작업은 다음과 같습니다.바인딩 9. 대부분의 애플리케이션에는 이에 대한 특정 구성이 있습니다.

  • UDP를 처리할 때 애플리케이션이 멀티호밍을 인식하도록 합니다. 이를 위해서는 애플리케이션 활성화가 필요합니다.보조 메시지실제 수신 인터페이스 및/또는 UDP 패킷이 수신된 주소를 검색하려면 다음을 사용하십시오.IP_PKTINFO소켓 옵션을 선택하고 응답할 때 이 정보를 사용하세요. 예를 들어, DNS 서버가 일반적으로 수행하는 작업은 다음과 같습니다.속박되지 않은. 이를 위해서는 애플리케이션에 특정 코드가 필요합니다.

TCP는 이 문제를 겪지 않습니다. 응답에는 올바른 소스 주소를 선택하고 올바른 라우팅 규칙을 트리거하는 컨텍스트가 있습니다.

관련 정보