문제가 발생했습니다. 내 모든 컴퓨터는 모뎀의 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)이나 172.16.0.0 네트워크의 컴퓨터로부터 ping 응답을 받는 것이 문제입니다. 상황에 따라서는 그 반대가 될 수도 있는데 왜 그런지는 모르겠습니다.
내 모뎀은 두 개의 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
main.conf에서 규칙과 추가 라우팅 테이블을 제거합니다.
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
따라서 로컬(라우팅되지 않은) 트래픽과 일치하지 않으며 기본 테이블만 사용됩니다.
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
Linux 시스템에서 나가는 소스 IP 주소를 변경하면 로컬에서 시작된 나가는 트래픽의 경로(링크)도 변경할 수 있습니다. 이는 선택사항이지만 ARP 트래픽에 관한 다음 섹션에서 이를 시행합니다.
ip rule add from 192.168.0.6 lookup 10 ip rule add from 192.168.0.3 lookup 172
규칙의 경로 재정의와 관련된 특별하지 않은 경우도 반복되어야 합니다.
여기서 누락된 유일한 라우팅은 두 개의 특정 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 정보는 원격 시스템에 캐시되어 일정 기간 동안 그대로 유지됩니다. 결국 캐시가 만료되고 동일한 일이 발생하지만 결과는 다를 수 있습니다. 그러면 이것이 어떻게 문제를 일으킬 수 있습니까? 예는 다음과 같습니다.
- 라우터(모뎀)는 원래 10.0.0.0/24에서 전송된 트래픽에 대한 라우팅 및 NAT(Linux를 통해) 응답을 다시 보내기 위해 192.168.0.6에 ARP 요청을 보냅니다.
- 리눅스가 대답했다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
올바른 ARP 확인을 위해서는 IP 주소 192.168.0.3 및 192.168.0.6이 정책 라우팅 규칙에서 일치해야 하기 때문에 이전 섹션의 3번 항목에 있는 두 규칙이 이제 필수입니다 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 항목 등을 확인합니다 .