Wi-Fi와 사이트-사이트 VPN(제로티어)이라는 2개의 네트워크 인터페이스가 있는 호스트가 있습니다.
root@host:~# ifconfig wlp0s20f3
wlp0s20f3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.38 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::a098:2166:78af:d78d prefixlen 64 scopeid 0x20<link>
ether ac:12:03:ab:6e:31 txqueuelen 1000 (Ethernet)
RX packets 1071869 bytes 1035656551 (1.0 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 911450 bytes 134092251 (134.0 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@host:~# ifconfig ztklh3tu4b
ztklh3tu4b: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 2800
inet 10.147.18.192 netmask 255.255.255.0 broadcast 10.147.18.255
inet6 fe80::f8f6:d1ff:fe3d:4f09 prefixlen 64 scopeid 0x20<link>
ether fa:f6:d1:3d:4f:09 txqueuelen 1000 (Ethernet)
RX packets 8836 bytes 1146994 (1.1 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 667 bytes 281732 (281.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
VPN 뒤에 있는 IP를 제외하고 이 호스트에 대한 모든 트래픽(인바운드 및 아웃바운드 모두)을 차단하고 싶습니다. 그래서 다음 iptable 규칙을 추가했습니다.
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -s 10.147.18.80 -j ACCEPT
iptables -A OUTPUT -d 10.147.18.80 -j ACCEPT
10.147.18.80에 ping을 실행하면 그렇게 할 수 없습니다. 핑 결과는 다음과 같습니다.
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3067ms
root@host:~# ping 10.147.18.80
PING 10.147.18.80 (10.147.18.80) 56(84) bytes of data.
^C
--- 10.147.18.80 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5097ms
iptables 규칙의 IP를 8.8.8.8과 같은 다른 것으로 변경하면 모든 것이 예상대로 작동합니다. 즉, 8.8.8.8 이외의 다른 것과는 통신할 수 없습니다.
편집하다 iptables -nvL의 다음 출력은 체인을 보여줍니다.
root@host:~# iptables -nvL
Chain INPUT (policy DROP 23 packets, 4560 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 10.147.18.80 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 330 packets, 25776 bytes)
pkts bytes target prot opt in out source destination
8 672 ACCEPT all -- * * 0.0.0.0/0 10.147.18.80
iptables의 위 출력은 패킷이 IP로 나가지만 규칙이 적용되면 응답이 수신되지 않음을 보여줍니다.
내 호스트의 Tcpdump는 동일한 동작을 보여줍니다.
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
13:28:32.323064 ztklh3tu4b Out IP (tos 0x0, ttl 64, id 17342, offset 0, flags [DF], proto ICMP (1), length 84)
10.147.18.192 > 10.147.18.80: ICMP echo request, id 61, seq 1, length 64
13:28:33.330145 ztklh3tu4b Out IP (tos 0x0, ttl 64, id 17567, offset 0, flags [DF], proto ICMP (1), length 84)
10.147.18.192 > 10.147.18.80: ICMP echo request, id 61, seq 2, length 64
13:28:34.354178 ztklh3tu4b Out IP (tos 0x0, ttl 64, id 17694, offset 0, flags [DF], proto ICMP (1), length 84)
10.147.18.192 > 10.147.18.80: ICMP echo request, id 61, seq 3, length 64
13:28:35.378135 ztklh3tu4b Out IP (tos 0x0, ttl 64, id 17714, offset 0, flags [DF], proto ICMP (1), length 84)
10.147.18.192 > 10.147.18.80: ICMP echo request, id 61, seq 4, length 64
10.147.18.80의 Tcpdump는 10.147.18.192의 인바운드 ICMP 에코 요청을 표시하지 않습니다. 무엇이 잘못되었을 수 있나요?
답변1
이 호스트에서 VPN 클라이언트를 사용하여 두 번째 인터페이스를 생성하는 경우 다음 사항도 잊지 마세요.VPN 서버에 대한 연결을 허용해 주세요그렇지 않으면 로컬 IP에 10.147.18.192더 이상 접근할 수 없습니다.
최소한 인터페이스에서 VPN 서버와의 아웃바운드 및 인바운드 트래픽을 허용해야 합니다 wlp0s20f3.
iptables -I OUTPUT -d $vpn_server_ip -p $proto --dport $vpn_port -j ACCEPT
iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$proto 또는 , 및 : VPN 서버의 IP 주소 또는 범위 및 포트입니다 udp.tcp$vpn_server_ip$vpn_port
이러한 값을 추측하는 데 많은 도움이 될 수는 없지만 VPN 설명서 또는 VPN 터널에 대한 연결이 작동하는 tcpdump/wireguard에서 이러한 정보를 제공해야 합니다.
답변2
귀하의 질문에서 언급한 두 명령은 다음과 같습니다.
iptables -A INPUT -s 10.147.18.80 -j ACCEPT
iptables -A OUTPUT -d 10.147.18.80 -j ACCEPT
그들은 해당 규칙을 체인 끝에 추가합니다.
-A옵션은 규칙을 끝에 추가합니다. 옵션을 사용하면 -I규칙이 체인의 맨 위에 놓이게 됩니다.
여기서 문제는 트래픽이 체인 끝에 도달하기 전에 트래픽을 삭제하는 체인 중 하나의 규칙 앞에 이미 DROP또는 REJECT규칙이 있을 수 있다는 것입니다 . ACCEPT예를 들어 IP 10.147.18.80을 포함하는 전체 서브넷과의 트래픽을 삭제하는 규칙과 같습니다.
체인에 해당 IP로의 트래픽을 삭제/거부하는 규칙이 있는 경우, INPUT 또는 OUTPUT 체인인지 여부에 따라 해당 IP에서 오는 트래픽을 ACCEPT 규칙 이전에 규칙이 해당 IP만 지정하는지 또는 전체 서브넷을 지정하는지 여부에 따라 트래픽이 발생합니다. 삭제되고 체인의 다른 모든 규칙은 더 이상 처리되지 않습니다.
DROP, REJECT, ACCEPT은 종료 대상입니다. iptables가 해당 규칙과 일치하면 체인의 다른 규칙 처리가 중지되고 다음 규칙으로 진행되지 않습니다.
노력하다
iptables -I INPUT -s 10.147.18.80 -j ACCEPT
iptables -I OUTPUT -d 10.147.18.80 -j ACCEPT
이렇게 하면 해당 규칙이 체인 위에 배치되어 가장 먼저 적중되는 규칙이 되며, 해당 체인의 해당 트래픽에 대해서는 다른 규칙이 처리되지 않습니다.
다음과 같이 체인의 모든 규칙을 나열할 수 있습니다.
iptables -nvL
또는 특정 체인만 보려면
iptables -nvL INPUT
iptables -nvL OUTPUT
편집하다
붙여넣은 출력과 기본 작업을 ACCEPT이것으로 변경하면 ping을 실행할 수 있다는 사실은 문제가 되지 않는 것 같습니다.
tcpdump와 같은 것을 사용하여 트래픽이 진행 중이고 반환되는지 확인할 수 있습니다.
이와 같은 명령은 시스템에서 보내거나 받는 모든 ICMP 패킷을 제공합니다.
tcpdump -nnvvi any icmp
출력에 이와 같은 내용이 나타나면
10:13:48.866598 IP (tos 0x0, ttl 255, id 30625, offset 0, flags [DF], proto ICMP (1), length 84)
10.147.18.192 > 10.147.18.80: ICMP echo request, id 26621, seq 4, length 64
10:13:48.867771 IP (tos 0x0, ttl 53, id 0, offset 0, flags [none], proto ICMP (1), length 84)
10.147.18.80 > 10.147.18.192: ICMP echo reply, id 26621, seq 4, length 64
그런 다음 핑 패킷이 전송되고 반환되지만 다른 규칙에 의해 거부됩니다.
nat 또는 mingle 테이블과 같은 다른 테이블에 다른 규칙이 있는지, 트래픽과 충돌하는 규칙이 있는지 확인할 수 있습니다.
iptables -t nat -nvL
iptables -t mingle -nvL
pkts목록 아래의 숫자를 통해 패킷이 OUTPUT 체인의 ACCEPT 규칙을 통과하는지 확인할 수도 있습니다 . 핑을 시도한 후 해당 숫자가 증가하지만 INPUT 체인의 숫자가 0으로 유지되면 들어오는 트래픽 규칙에 문제가 있는 것입니다.
또한 명령이나 이와 유사한 방법으로 경로를 확인하십시오. ip r트래픽이 동일한 서브넷의 인터페이스를 통해 나가지 않을 수 있으므로 도중에 일부 NAT 규칙으로 인해 반환되는 패킷의 소스 IP가 변경될 수 있습니다.