☰

ip6tables는 소스 주소를 가장하지 않습니다.

tag-icon • tag-icon iptables ip6tables
ip6tables는 소스 주소를 가장하지 않습니다.

내 ip6tables규칙은 다음과 같습니다.

# ip6tables -t nat -L -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       all      eth0   any     anywhere             2001:470:4a71:f170::/64  to:fdde:ad00:beef:0:91f5:6dd4:e66f:cf5b

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 19 packets, 1936 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 19 packets, 1936 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  all      any    eth0    fdde:ad00:beef::/64  anywhere            
    0     0 MASQUERADE  udp      any    eth0    fd11:22::/64         anywhere            
    0     0 MASQUERADE  tcp      any    eth0    fd11:22::/64         anywhere

eth0를 사용하여 패킷이 나가는 것을 볼 수 있습니다 tshark. 다음은 하나의 대표적인 패킷입니다(인터페이스에서 수신됨 wpan0).

221 480.196225356 fd11:22::703c:ef83:a03d:7e1b ? 2600:1f1c:c93:da00:76c2:1dbd:72c2:d063 TCP 94 [TCP Retransmission] 49998 ? 50000 [SYN] Seq=0 Win=9 Len=0 MSS=474 WS=1 SACK_PERM=1 TSval=2889901 TSecr=0

나는 이 패킷이 MASQUERADE 필터를 통과하여 소스 주소가 이더넷( eth0)에서 호스트의 IPv6 주소가 되도록 다시 작성되기를 원합니다. 그러나 패킷이 ip6tables 규칙과 일치할 것으로 예상하더라도 이런 일은 발생하지 않습니다. 실제로 패킷은 MASQUERADE 규칙 중 어느 것과도 일치하지 않습니다(카운터에서 목격 pkts). 이것을 디버깅하는 방법을 잘 모르겠습니다. 이 패킷이 가장되지 않는 이유를 아는 사람이 있습니까?

내가 시도한 것들:

  1. 모든 conntrack항목 삭제:conntrack -f ipv6 -D
  2. 기계를 다시 시작하십시오.

당신의 도움을 주셔서 감사합니다!

편집하다:

다음은 좀 더 유용한 결과입니다.

# ip6tables-save -c
# Generated by ip6tables-save v1.6.0 on Sun Sep  2 11:44:06 2018
*filter
:INPUT ACCEPT [1812:134308]
:FORWARD ACCEPT [22:1760]
:OUTPUT ACCEPT [1782:210084]
COMMIT
# Completed on Sun Sep  2 11:44:06 2018
# Generated by ip6tables-save v1.6.0 on Sun Sep  2 11:44:06 2018
*nat
:PREROUTING ACCEPT [1:137]
:INPUT ACCEPT [1:137]
:OUTPUT ACCEPT [41:5757]
:POSTROUTING ACCEPT [41:5757]
[0:0] -A PREROUTING -d 2001:470:4a71:f170::/64 -i eth0 -j DNAT --to-destination fdde:ad00:beef:0:91f5:6dd4:e66f:cf5b
[0:0] -A POSTROUTING -s fdde:ad00:beef::/64 -o eth0 -j MASQUERADE
[0:0] -A POSTROUTING -s fd11:22::/64 -o eth0 -p udp -j MASQUERADE
[0:0] -A POSTROUTING -s fd11:22::/64 -o eth0 -p tcp -j MASQUERADE
COMMIT
# Completed on Sun Sep  2 11:44:06 2018

# ip -6 link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:96:eb:75 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:c3:be:20 brd ff:ff:ff:ff:ff:ff
4: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 06:8a:53:01:68:f2 brd ff:ff:ff:ff:ff:ff
5: wpan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 500
    link/none

# ip -6 -brief address
lo               UNKNOWN        ::1/128 
eth0             UP             2001:470:4a71:f000::11/64 fe80::ba27:ebff:fe96:eb75/64 
wpan0            UNKNOWN        fdde:ad00:beef:0:cc1e:c6e2:8252:e44b/64 fd11:22::1c4d:925:de45:9d30/64 fe80::1c4d:925:de45:9d30/64 fe80::2ccb:f19:edce:c49e/64

# ip -6 route
2001:470:4a71:f000::/64 dev eth0  proto kernel  metric 256  pref medium
fd11:22::/64 dev wpan0  proto kernel  metric 256  pref medium
fdde:ad00:beef::/64 dev wpan0  proto kernel  metric 256  pref medium
fe80::/64 dev eth0  proto kernel  metric 256  pref medium
fe80::/64 dev wpan0  proto kernel  metric 256  pref medium
default via 2001:470:4a71:f000::1 dev eth0  metric 1024  pref medium

답변1

이는 TCP 체크섬이 잘못되었기 때문인 것으로 나타났습니다(호스트의 TCP 스택에 버그가 있음). 분명히 tshark이것은 기본적으로 표시되지 않지만 ip6tables가 소스 주소를 가장하지 않게 만들었습니다.

도와주신 모든 분들께 감사드립니다. Kasperd의 제안과 관련하여 유사한 솔루션이 내 설정(/48이 아닌 /60이 있음)에서 작동하는 것으로 밝혀졌으므로 ip6tables에서 벗어나려고 노력할 것입니다.

편집: 이제 NAT 없이 작동하는 설정이 있습니다. 이것을 제안해 주셔서 감사합니다.

답변2

네, 저도 같은 문제가 있었습니다. 해결책은 간단했습니다. "ip6tables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT"를 실행하면 됩니다.

문제는 ip6tables 코드가 기본적으로 conntrack 모듈을 로드하지 않으므로 상태 전체 규칙이 투명하게 작동하지 않는다는 것입니다.

그리고 "IPv6에는 NAT가 필요하지 않습니다!" brigade - 예를 들어 AWS에서 Docker 컨테이너를 실행하려는 경우 가끔 필요합니다. DHCP PD를 지원하지 않으므로 NAT에 갇혀 있습니다.

관련 정보