☰

이 특별한 경우에 이 네트워크를 작동시키는 방법은 무엇입니까?

tag-icon • tag-icon debian networking routing
이 특별한 경우에 이 네트워크를 작동시키는 방법은 무엇입니까?

문제가 있습니다. 내 모든 컴퓨터는 모뎀의 ETH 포트에 연결된 라우터 뒤에 있습니다. 해당 포트는 다운로드/업로드가 너무 제한되어 있습니다. 그래서 두 포트의 라우터에서 모뎀까지 두 개의 케이블을 연결해 보았습니다. 나는 이 문제를 해결하는 방법을 많이 연구해 왔지만 더 이상 무엇을 시도해야 할지 모르겠습니다.

내 라우터에는 4개의 인터페이스가 있습니다.

enp1s0f0   172.16.0.3
enp4s0f1   10.0.0.6
enp1s0f1   192.168.0.3
enp4s0f0   192.168.0.6

보시다시피 eth3과 eth4는 동일한 네트워크에 있는데, 이상합니다. 두 개의 ETH 포트를 사용하여 모뎀(192.168.0.1)에 연결하려면 이 방법을 사용해야 했습니다.

그래서 제가 시도한 것은 다음과 같습니다.

echo "1   myorg" >> /etc/iproute2/rt_tables #added a custom routing table myorg
sudo ip route add 192.168.0.1 scope link dev enp4s0f0 #don't know if it is really necessary
sudo ip rule add from 192.168.0.6 table myorg
sudo ip route add default via 192.168.0.1 dev enp4s0f0 table myorg #second default gateway through myorg table

결과적으로 다음 경로를 얻습니다.

$ ip -4 route show table main
default via 192.168.0.1 dev enp1s0f1 onlink 
10.0.0.0/24 dev enp4s0f1 proto kernel scope link src 10.0.0.6 
172.16.0.0/24 dev enp1s0f0 proto kernel scope link src 172.16.0.3 
192.168.0.0/24 dev enp1s0f1 proto kernel scope link src 192.168.0.3 
192.168.0.0/24 dev enp4s0f0 proto kernel scope link src 192.168.0.6
192.168.0.1 dev enp4s0f0 scope link

$ ip -4 route show table myorg
default via 192.168.0.1 dev enp4s0f0

$ sudo route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 enp1s0f1
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 enp4s0f1
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 enp1s0f0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp1s0f1
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp4s0f0
192.168.0.1     0.0.0.0         255.255.255.255 UH    0      0        0 enp4s0f0

NAT 방화벽으로 ufw를 사용합니다. *nat 섹션에 다음을 추가했습니다.

:POSTROUTING ACCEPT - [0:0]
-A POSTROUTING -s 172.16.0.0/24 -o enp1s0f1 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/24 -o enp4s0f0 -j MASQUERADE

문제는 10.0.0.0 네트워크의 시스템이 모뎀(게이트웨이 192.168.0.1)으로부터 ping 응답을 받거나 172.16.0.0 네트워크의 시스템 중 하나라는 것입니다. 상황에 따라서는 반대일 수도 있는데, 이유는 모르겠습니다.

내 모뎀에는 두 개의 ETH 포트에서 클라이언트 192.168.0.3과 192.168.0.6이 모두 표시됩니다.

그렇다면 이 토폴로지를 사용하는 모든 시스템과 모든 네트워크(동일한 네트워크에 두 개의 인터페이스가 있는 라우터)에서 WAN 액세스가 가능합니까?

답변1

명시적으로 작성되지는 않았지만 목표는 다음과 같이 트래픽을 분할하는 것입니다.

  • 172.16.0.0/24 트래픽은 enp1s0f1을 통해 흐릅니다.
  • 10.0.0.0/24 트래픽은 enp4s0f0을 통해 흐릅니다.

OP가 쓴 것처럼 여기에는 정책/소스 기반 라우팅이 필요합니다.iptables그리고넷필터거의 유용하지 않습니다(적어도 단독으로는):

  • 일반적으로 말하면iptables그리고넷필터경로를 지정하지 말고 경로에 신경 쓰지 마십시오. 네트워크 라우팅 스택이 라우팅됩니다. 일부iptables' 작업으로 인해 여전히 라우팅 결정이 변경됩니다(이 항목에 설명된 대로).개략도)
  • 에서 수행된 모든 작업포스트라우팅이름에서 알 수 있듯이 발생합니다.~ 후에경로 결정이 내려졌습니다. 경로를 변경하기에는 너무 늦었습니다. 여기 동안nat/포스트라우팅규칙이 필요하더라도 경로는 변경되지 않습니다.

언제든지iptables라우팅 문제를 해결하려면 피할 수 있으므로 피하는 것이 좋습니다. 때로는 피할 수 없는 경우도 있습니다(그리고 일반적으로iptables패킷에 표시를 추가하는 데 사용되며 이 표시는 ip rule항목에 사용됩니다.

노선

나는 그것을 가정할 것이다rp_filter=1대부분의 배포판에서 기본값이므로 모든 인터페이스에 설정되어 있습니다.엄격한 역방향 경로 전달.

소스 주소는 규칙에 의해 선택되고, 목적지는 라우팅 테이블에 의해 선택됩니다. 추가 라우팅 테이블에는 여러 경로 중 하나만 선택해야 하는 경우(이 경우 이 하나만 테이블에 추가됨) 경로를 재정의할 수 있는 충분한 정보가 있어야 합니다. 종종 기본 테이블의 추가 경로도 복사해야 합니다. 그렇지 않으면 나쁜 일이 발생할 수 있습니다.

내 대답에서는 하나의 네트워크 또는 다른 네트워크에 대해 우선권을 부여하지 않을 것입니다. 각 네트워크는 자체 라우팅 테이블을 갖습니다. 표 1은 잊어버리고 LAN 10.0.0.0/24에는 표 10을, LAN 172.16.0.0/24에는 표 172를 사용하겠습니다. NAT 규칙을 유지하고 192.168.0.1 dev enp4s0f0 scope link기본 규칙과 추가 라우팅 테이블을 제거합니다 .

  1. 10.0.0.0/24 <--> 10.0.0.6 enp4s0f0에 대한 경로 | enp4s0f1 192.168.0.6 <--> 192.168.0.1/기본값:

     ip rule add from 10.0.0.0/24 lookup 10
 ip route add table 10 10.0.0.0/24 dev enp4s0f1
 ip route add table 10 192.168.0.0/24 dev enp4s0f0 src 192.168.0.6
 ip route add table 10 default via 192.168.0.1

위에서 10.0.0.0/24에 대한 중복된 경로 항목이 없으면 시스템 자체가 이 LAN에 액세스할 수 없습니다.엄격한 역방향 경로 전달(SRPF) 목적으로 이를 디버깅하기 어렵게 만듭니다. 추가하지 않으면 나쁜 일의 예입니다. 의심스러운 경우에는 경로를 중복하면 됩니다.

위의 규칙을 다음과 같이 변경하는 추가 경로 대신 다른 동등한 옵션이 있을 수 있습니다.

    ip rule add from 10.0.0.0/24 iif enp4s0f1 lookup 10

따라서 로컬(라우팅되지 않은) 트래픽에는 일치하지 않으며 기본 테이블만 사용됩니다.

  1. 172.16.0.0/24 <--> 172.16.0.3 enp1s0f0에 대한 경로 | enp1s0f1 192.168.0.3 <--> 192.168.0.1/기본값:

     ip rule add from 172.16.0.0/24 lookup 172
 ip route add table 172 172.16.0.0/24 dev enp1s0f0
 ip route add table 172 192.168.0.0/24 dev enp1s0f1 src 192.168.0.3
 ip route add table 172 default via 192.168.0.1

  2. Linux 시스템에서 나가는 소스 IP 주소를 변경할 때 로컬에서 시작된 나가는 트래픽의 경로(링크)도 변경합니다. 이는 선택사항이지만 ARP Flux에 대한 다음 부분에서는 필수입니다.

     ip rule add from 192.168.0.6 lookup 10
 ip rule add from 192.168.0.3 lookup 172

  3. 규칙에서 재정의된 경로와 관련된 비특별한 경우도 복제해야 합니다.

여기서 유일하게 누락된 경로는 두 개의 특수 LAN 자체 사이입니다.

표 10에서는 172.16.0.0/24에 도달하고
표 172에서는 10.0.0.0/24에 도달합니다.

각각의 추가 테이블에는 아직 상대방에 대한 경로가 없기 때문에 기본 경로를 사용하지만(그러나 SRPF에 의해 다시 차단됨) 두 특수 네트워크 각각이 더 이상 서로 통신할 수 없게 됩니다. 따라서 각 테이블에 대해 누락된 경로를 복제하세요.

    ip route add table 10 172.16.0.0/24 dev enp1s0f0
    ip route add table 172 10.0.0.0/24 dev enp4s0f1

이 모델을 사용하면 예를 들어 두 개의 다른 "일반" 내부 네트워크가 추가되는 경우 추가 설정 없이 서로 통신할 수 있지만(그리고 기본 테이블의 기본 경로를 사용하여 외부로 나갈 수 있음) 다시 경로가 중복되어야 합니다. 각각의 추가 라우팅 테이블은 두 개의 특수 LAN과 통신합니다.

이제 경로는 괜찮지만 아직은...

그만큼ARP 플럭스문제

리눅스는 다음을 따른다약한 호스트 모델. IP 라우팅의 경우도 마찬가지이며, Linux가 ARP 요청에 응답하는 방식도 마찬가지입니다. 즉, 모든 인터페이스에서 모든 IP에 대해 응답하지만 물론 인터페이스의 자체 MAC 주소를 사용합니다. 여러 인터페이스가 동일한 LAN에 있을 때 모든 인터페이스에서 동시에 이런 일이 발생할 수 있으므로 일반적으로 가장 빠른 것이 승리합니다. 그런 다음 ARP 정보가 원격 시스템에 캐시되어 한동안 그곳에 유지됩니다. 결국 캐시가 만료되고 동일한 일이 발생하며 다른 결과가 발생할 수 있습니다. 그러면 이것이 어떻게 문제를 일으키는가? 예는 다음과 같습니다.

  • 라우터(모뎀)는 192.168.0.6에 대한 ARP 요청을 보내 처음 10.0.0.0/24에서 전송된 트래픽에 대해 라우팅 및 NAT(Linux에 의해) 응답을 다시 보냅니다.
  • 리눅스가 응답한다enp1s0f1(enp1s0f1경주에서 승리)를 사용하여enp1s0f1의 MAC 주소가 192.168.0.6임을 알려줍니다.
  • 몇 초에서 몇 분 동안 192.168.0.6에 대한 라우터의 향후 수신 IP 패킷이 도착합니다.enp1s0f1,
  • 동시에출구192.168.0.6의 패킷은 다음을 사용하여 떠납니다.enp4s0f0.

이 비대칭 라우팅은 다음에 의해 포착됩니다.엄격한 역방향 경로 전달(rp_filter) 트래픽이 실패합니다. 이는 몇 초 동안 무작위로 작동하는 것처럼 보이다가 다시 실패할 수도 있습니다. 전체 트래픽에 따라 문제는 나중에 다른 링크로 전환될 수도 있습니다(그리고 문제는 다른 LAN으로 전환됩니다).

다행히도 이를 방지하기 위해 Linux는 정책 라우팅과 함께만 사용되는 설정을 제공하여 ARP가 라우팅에 정의된 동일한 규칙을 따르도록 합니다.arp_filter.

arp_filter - 부울

1 - 동일한 서브넷에 여러 네트워크 인터페이스를 보유하고 각각에 대해 ARP를 가질 수 있습니다.상호 작용에 기초하여 답변을 받다커널이 ARP의 IP에서 해당 인터페이스로 패킷을 라우팅할지 여부(그러므로소스 기반 라우팅을 사용해야 합니다.이것이 작동하려면). 즉, arp 요청에 응답할 카드(보통 1개)를 제어할 수 있습니다.

sysctl -w net.ipv4.conf.enp4s0f0.arp_filter=1
sysctl -w net.ipv4.conf.enp1s0f1.arp_filter=1

이제 ARP 동작이 정확합니다. 설정이 방금 적용되었다면 다음의 ARP 캐시를 강제로 플러시해야 합니다.동료(여기서는 모뎀)을 사용하여 중복 주소 감지를 수행합니다.arping(에서아이틸스/iputils-arping) 피어에게 브로드캐스트하고 캐시를 업데이트하도록 합니다.

arping -c 5 -I enp4s0f0 -D -s 192.168.0.6 192.168.0.6 &
arping -c 5 -I enp1s0f1 -D -s 192.168.0.3 192.168.0.3

이전 부분의 글머리 기호 3에 있는 두 가지 규칙은 이제 필수입니다. 왜냐하면 IP 주소 192.168.0.3 및 192.168.0.6은 올바른 ARP 확인을 위해 정책 라우팅 규칙에서 일치해야 하기 때문입니다 arp_filter=1.

디버깅 방법

ip route get경로를 확인하고 역방향 경로 필터링을 수행하는 데 매우 유용합니다.

위의 글머리 기호 4에 대한 새로운 테스트 사례:

# ip route get from 10.0.0.111 iif enp4s0f0 172.16.0.111
172.16.0.111 from 10.0.0.111 dev enp1s0f0 table 10 
    cache iif enp4s0f0 
# ip route get from 172.16.0.111 iif enp1s0f0 to 10.0.0.111
10.0.0.111 from 172.16.0.111 dev enp4s0f1 table 172 
    cache iif enp1s0f0

규칙이나 경로를 삭제할 때:

# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp4s0f0 table 10 
    cache iif enp4s0f1 
# ip rule del from 10.0.0.0/24 lookup 10
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp1s0f1
    cache iif enp4s0f1
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
local 192.168.0.6 from 192.168.0.1 dev lo table local
    cache <local> iif enp4s0f0
# ip rule delete from 192.168.0.6 lookup 10
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
RTNETLINK answers: Invalid cross-device link

이는 규칙 및 추가 경로에 따라(부족한) 결과가 어떻게 달라지는지 보여줍니다. 마지막 결과는 역방향 경로 전달 확인 실패(=> 삭제)를 알리는 오류 메시지입니다.

그런 다음 ip neigh(가장 유용 합니다.또래tcpdump시스템)에서 ARP 항목 등을 확인합니다.

관련 정보