☰

라우팅 정책 데이터베이스가 표시된 패킷을 감지하지 못합니다.

tag-icon • tag-icon iptables routing netfilter
라우팅 정책 데이터베이스가 표시된 패킷을 감지하지 못합니다.

mangle1대상 주소가 다음과 같은 경우 내 연구실 서버에 다음과 같은 테이블 규칙이 있습니다 6.6.6.6.

$ sudo iptables -t mangle -L PREROUTING 2 -v -n --line-numbers
2       17   884 MARK       udp  --  ge-0.0.0-Iosv6 *       0.0.0.0/0            6.6.6.6              MARK set 0x1
$

6.6.6.6/32lo이 서버에 구성하십시오. 위의 규칙 카운터는 traceroute를 실행할 때마다 6.6.6.6증가하는데 , 이는 예상된 결과입니다. 즉, 패킷이 표시되어 있는 것처럼 보입니다. 내 라우팅 정책 데이터베이스는 다음과 같습니다.

$ ip rule show
0:      from all lookup local
32764:  from all fwmark 0x2 lookup twohundred
32765:  from all fwmark 0x1 lookup threehundred
32766:  from all lookup main
32767:  from all lookup default
$

..테이블은 threehundred다음과 같습니다.

$ ip r sh table threehundred
default via 192.168.100.2 dev ge-0.0.0-Iosv6
$

그러나 태그가 지정된 패킷은 테이블의 항목을 기반으로 하지 않고 라우팅됩니다 threehundred. 승인을 통해 서버를 통해 UDP 패킷을 main얻을 수 있지만 ICMP 응답은 테이블과 관련된 기본 경로를 통해 전송 됩니다 . 앞서 언급했듯이 이 기간 동안 테이블 규칙 #2가 증가됩니다.tcpdumpge-0.0.0-Iosv6port unreachableeth0mainmanglePREROUTING

이 동작의 원인은 무엇입니까? 저는 우분투 16.04.6 LTS를 실행하고 있습니다.

답변1

이것은일반 네트워크의 Netfilter 및 패킷 흐름개략도:

일반 네트워크의 Netfilter 및 패킷 흐름

수신 패킷이 PREROUTING에 표시되어 있지만 로컬에서 생성된 응답 패킷은 OUTPUT을 통해 나갑니다. 거기에 표시하는 규칙이 없으므로표시그리고 노선도 다릅니다.

mangle/OUTPUT에서 패킷을 변경하면(태그 변경과 같은 메타 정보 포함) 경로 재지정 검사가 트리거됩니다. 이 경로는 다음에서 경로를 변경해야 합니다.이더넷 0도착하다ge-0.0.0-Iosv6(참고:nftables바꾸다iptables, 헌신적인노선이 효과를 얻으려면 연결이 필요합니다.) 이 규칙은 다음을 수행합니다.

iptables -t mangle -A OUTPUT -s 6.6.6.6 -j MARK --set-mark 1

두 가지 방법으로 특정 규칙으로 개별 패킷을 표시하는 대신 전체 흐름을 자동으로 표시할 수 있습니다(예:연결하다). 이것코맥경쟁과 그코맥대상 대응물을 사용할 수 있습니다. 이 블로그에서는 사용 예를 제공합니다.넷필터 코맥.

이 경우에는 대신iptables위의 규칙:

  • mangle/PREROUTING의 마지막 규칙이어야 합니다.

    iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j CONNMARK --save-mark

  • mangle/OUTPUT의 첫 번째 규칙이어야 하므로 필요한 경우 계속 변경할 수 있습니다. 이렇게 하면 경로 재지정 확인이 실행됩니다.

    iptables -t mangle -I OUTPUT -m connmark ! --mark 0 -j CONNMARK --restore-mark

테스트 없이는 안정적으로 예측하기 어렵고 알아야 할 몇 가지 사항이 더 있습니다.

  • 스위치fwmark_reflect(예 sysctl -w net.ipv4.fwmark_reflect=1: )는 이 특정한 경우에 충분할 수 있으며 위의 규칙 대신 사용할 수 있지만 보다 일반적인 경우에는 도움이 되지 않습니다. 또한 있다tcp_fwmark_acceptTCP 상황을 완화합니다. UDP와 같은 다른 프로토콜에는 유사한 프로토콜이 없습니다.

  • 때때로 경로가 실패함앞으로경로 재지정 확인 때문에엄격한 역방향 경로 전달그리고 패킷은 표시되고 다시 라우팅되기 전에 조기에 삭제됩니다. 분명히 여기서는 그렇지 않습니다(SRPF가 활성화되지 않을 수도 있음). 그러나 그런 일이 발생하면 관련된 인터페이스 중 하나에서 느슨한 모드로 변경하여 검사를 완화해야 합니다(어느 인터페이스인지 파악하려면 테스트를 수행해야 함).rp_filter설정(예: sysctl -w net.ipv4.conf.eth0.rp_filter=2).

  • 가끔 추가 경로가 있는 경우도 있습니다.기본테이블은 대체되기 전에 읽기 때문에 추가된 테이블에 복사되어야 합니다.기본테이블이 일치하지 않을 수 있습니다. 언제, 특히 언제 필요할지 파악하기 어렵습니다.분수모두 관련되어 있습니다. 예를 들어:

    ip route add table threehundred 192.168.100.2/32 dev ge-0.0.0-Iosv6

  • ip route get ...적절한 명령이 제공되더라도 그 명령이 mark현재 일어나고 있는 일을 항상 정확하게 예측하는 것은 아닌 것 같습니다.분수그리고iptables모두 관련되어 있습니다.

  • 마커, 경로 및 예측 간의 상호 작용과 관련된 동작은 ip route get문서화되지 않은 콘텐츠를 통해 변경될 수 있습니다.src_valid_mark토글( 를 통해서도 사용 가능 sysctl) 문제가 해결될 것 같은 경우에만 사용하세요.

  • 정책 라우팅의 경우 UDP 서버 동작이 TCP 서버 동작과 다른 것을 알 수 있으며 그 이유는 복잡하고 설명하기 어렵습니다. 사용분수복잡성만 가중됩니다.

관련 정보