1:1 상태 비저장 NAT 트래픽을 시도하고 있습니다. 트래픽은 GRE 터널을 통해 들어오고 VPN을 통해 나갑니다.
나는 GRE 터널에서 Linux 상자로 들어오는 트래픽이 Conntrack에 도달하지 않거나 iptables -t nat에 도달하지 않는다는 것을 알기 위해 충분한 연구를 수행했습니다. iptales SNAT, DNAT 또는 NETMAP은 모두 -t nat 테이블에 있어야 합니다.
iproute2 상태 비저장 nat 옵션이 있었지만 커널 버전 2.6에서 제거되었습니다. 삭제하기 전에 다음을 수행할 수 있습니다.ip route add nat 192.168.50.2 via 192.168.60.2
상태 비저장 nat가 iproute2에서 제거되었을 때 Xtables-addons 패키지에 RAWDNAT 및 RAWSNAT 옵션이 있었습니다. Xtables 플러그인. Xtables-addons 문서는 여전히 RAWDNAT 및 RAWSNAT를 옵션으로 제공하지만 오류가 발생하고Xtables-애드온은 RAWSNAT/RAWDNAT를 제거합니다.
이제 나는 교통 통제의 세계로 들어갑니다. 교통 통제 문서는 매우 드물고 따라가기가 어렵습니다. 특히 입구 처리의 경우.
그래서 나는 문제를 해결했고 이제 내 eth0에서 tc와 함께 작동하는 1:1 간단한 상태 비저장 NAT를 얻으려고 노력하고 있습니다. 주소가 192.168.234.5이고 라우팅이 10.40.0.0/16인 상자가 있습니다. 192.168.234.112에서 10.40.0.112로 양방향으로 NAT를 시도하고 있습니다.
10.40.0.112의 인바운드 패킷의 경우:
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip prio 10 \
u32 match ip src 10.40.0.112/32 \
action nat ingress 10.40.0.112/32 192.168.234.112
아웃바운드 패킷의 경우
tc qdisc add dev eth0 root handle 1: htb
tc filter add dev eth1 parent 1: protocol ip prio 10 \
u32 match ip dst 192.168.234.112/32 \
action nat egress 192.168.234.112/32 10.40.0.112
어쩐지 실제로 위의 명령이 작동하도록 할 수 있었지만 평생 동안 더 이상 작동하게 할 수 없습니다. stackoverflow.com에서 Ubuntu의 기본 qdisc(pfifo_fast)는 클래스가 없으므로 패킷 필터링을 제공하지 않는다는 기사를 찾았지만 더 이상 해당 기사를 따를 수 없습니다. 필터를 지원하지 않는 qdisc에 추가하면 "tc filter add"가 오류 메시지를 표시할 것이라고 생각할 수도 있지만 이것이 트릭을 수행하는 것 같습니다.
이것은 내가 실행 중인 명령입니다.
먼저 입구에 부착할 무언가가 있도록 출구 qdisc를 추가하십시오.
tc qdisc add dev eth0 root handle 1: htb
tc qdisc add dev eth0 ingress
이때 tc qdisc신고하세요
qdisc htb 1: dev eth0 root refcnt 2 r2q 10 default 0 direct_packets_stat 9 direct_qlen 1000
qdisc ingress ffff: dev eth0 parent ffff:fff1 ----------------
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
이제 항목 필터를 추가합니다. 예를 들면 다음과 같습니다.
tc filter add dev eth0 parent ffff: protocol ip prio 10 \
u32 match ip src 10.40.0.112/32 \
action nat ingress 10.40.0.112/32 192.168.234.112
이 시점에서 10.40.0.112로 ping을 실행하면 192.168.234.112에서 응답이 나올 것으로 예상됩니다. 그러나 필터는 결코 적중되지 않습니다. 실제로 패킷에 NAT 연산이 적용되는 것을 본 적이 없는데 이 필터 규칙에 대한 통계가 올라갔습니다.
다음과 같은 내보내기 필터를 추가하겠습니다.
tc filter add dev eth0 parent 1: protocol ip prio 10 \
u32 match ip dst 192.168.234.112/32 \
action nat egress 192.168.234.112/32 10.40.0.112
이 시점에서 tc 필터는 다음과 같습니다.
root@ubusswan1-VirtualBox:/home/ubusswan1# tc filter show dev eth0
filter parent 1: protocol ip pref 10 u32
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid ???
match c0a8ea70/ffffffff at 16
action order 1: nat egress 192.168.234.112/32 10.40.0.112 pass
root@ubusswan1-VirtualBox:/home/ubusswan1# tc filter show dev eth0 root
filter parent ffff: protocol ip pref 10 u32
filter parent ffff: protocol ip pref 10 u32 fh 800: ht divisor 1
filter parent ffff: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 terminal flowid ???
match 0a280070/ffffffff at 12
action order 1: nat ingress 10.40.0.112/32 192.168.234.112 pass
이 1:1 NAT가 진행되도록 TC를 충분히 이해하도록 도와주실 수 있나요? 작동하지 않는 TC 필터를 디버깅하는 더 좋은 방법이 있습니까?
답변1
교환 src하고 dst맞춰주신 것 같아요. 나는 현재 다음을 가지고 있습니다:
#tc qdisc del dev eth0 ingress
#tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip prio 1 u32 match ip dst $FROMIP action nat ingress $FROMIP $TOIP
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src $TOIP action nat egress $TOIP $FROMIP
#tc -s qdisc show dev eth0
#tc -s filter show dev eth0
#tc -s filter show dev eth0 parent ffff:
이것은 효과가 있는 것 같습니다( tc비록 전문가는 아니지만)!