iptables-Regeln funktionieren nicht zum Zulassen einer bestimmten IP

Question 1

Wenn Sie einen VPN-Client auf diesem Host verwenden, um die zweite Schnittstelle zu erstellen, vergessen Sie nicht, auchVerbindungen zum VPN-Server zulassen, sonst ist Ihre lokale IP 10.147.18.192nicht mehr erreichbar.

Sie müssen mindestens ausgehenden und eingehenden Datenverkehr zum/vom VPN-Server auf der Schnittstelle zulassen 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 wird udpoder tcp, und sein $vpn_server_ip: $vpn_portdie IP-Adresse oder der Bereich und Port des/der VPN-Server(s)

Ich kann beim Erraten dieser Werte nicht wirklich helfen, aber Ihre VPN-Dokumentation oder tcpdump/wireguard mit einer funktionierenden Verbindung zum VPN-Tunnel sollten Ihnen diese Informationen geben.

Answer

Wenn Sie einen VPN-Client auf diesem Host verwenden, um die zweite Schnittstelle zu erstellen, vergessen Sie nicht, auchVerbindungen zum VPN-Server zulassen, sonst ist Ihre lokale IP 10.147.18.192nicht mehr erreichbar.

Sie müssen mindestens ausgehenden und eingehenden Datenverkehr zum/vom VPN-Server auf der Schnittstelle zulassen 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 wird udpoder tcp, und sein $vpn_server_ip: $vpn_portdie IP-Adresse oder der Bereich und Port des/der VPN-Server(s)

Ich kann beim Erraten dieser Werte nicht wirklich helfen, aber Ihre VPN-Dokumentation oder tcpdump/wireguard mit einer funktionierenden Verbindung zum VPN-Tunnel sollten Ihnen diese Informationen geben.

Question 2

Diese beiden Befehle erwähnen Sie in Ihrer Frage:

iptables -A INPUT -s 10.147.18.80 -j ACCEPT
iptables -A OUTPUT -d 10.147.18.80 -j ACCEPT

Sie hängen diese Regeln an das Ende der Ketten an. -ADie Option hängt die Regel an das Ende an. Wenn Sie -Idie Option verwenden, fügen Sie die Regel an den Anfang der Kette ein.

DROPDas Problem besteht hier darin, dass Sie wahrscheinlich bereits eine Regel REJECTvor der Regel in einer der Ketten haben ACCEPT, die den Datenverkehr verwirft, bevor er das Ende der Kette erreicht. Wie zum Beispiel eine Regel, die den Datenverkehr zu oder von einem ganzen Subnetz verwirft, das die IP 10.147.18.80 enthält.

Wenn Sie in einer Kette eine Regel haben, die Datenverkehr zu oder von dieser IP (je nachdem, ob es sich um eine INPUT- oder OUTPUT-Kette handelt) vor der ACCEPT-Regel verwirft/ablehnt, wird der Datenverkehr verworfen und alle anderen Regeln in der Kette werden nicht mehr verarbeitet, unabhängig davon, ob die Regel nur diese IP oder das gesamte Subnetz angibt.

DROP, REJECT, ACCEPTsind Beendigungsziele. Sobald iptables mit dieser Regel übereinstimmt, beendet es die Verarbeitung anderer Regeln in der Kette und fährt nicht mit der nächsten Regel fort.

Versuchen

iptables -I INPUT -s 10.147.18.80 -j ACCEPT
iptables -I OUTPUT -d 10.147.18.80 -j ACCEPT

Dadurch werden diese Regeln oben in den Ketten platziert, sodass sie als erste Regeln angewendet werden und andere Regeln für diesen Datenverkehr in diesen Ketten dann nicht mehr verarbeitet werden.

Sie können alle Regeln in einer Kette mit etwas wie auflisten

iptables -nvL

oder wenn Sie nur bestimmte Ketten anzeigen möchten

iptables -nvL INPUT 
iptables -nvL OUTPUT

BEARBEITEN

Angesichts der von Ihnen eingefügten Ausgabe und der Tatsache, dass Sie einen Ping senden können, wenn Sie die Standardaktionen entsprechend ändern, ACCEPTscheint dies nicht das Problem zu sein.

Sie können beispielsweise „tcpdump“ verwenden, um zu prüfen, ob Datenverkehr hinein- und zurückgeht.

Ein Befehl wie dieser gibt Ihnen alle ICMP-Pakete aus, die von der Maschine gesendet oder empfangen werden

tcpdump -nnvvi any icmp

Wenn Sie in der Ausgabe so etwas erhalten

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

Dann werden Ihre Ping-Pakete gesendet und zurückgesendet, aber von einer anderen Regel abgelehnt.

Sie können überprüfen, ob Sie möglicherweise andere Regeln in anderen Tabellen wie der NAT- oder Mingle-Tabelle haben, und ob einige der dortigen Regeln möglicherweise mit dem Datenverkehr in Konflikt stehen.

iptables -t nat -nvL
iptables -t mingle -nvL

Sie können auch anhand der Nummer in der Liste sehen, ob die Pakete die ACCEPT-Regel in der OUTPUT-Kette durchlaufen pkts. Wenn diese Nummer nach dem Ping-Versuch ansteigt, die Nummer in der INPUT-Kette jedoch 0 bleibt, liegt das Problem bei den Regeln für eingehenden Datenverkehr.

Überprüfen Sie außerdem Ihre Routen mit ip reinem Befehl oder etwas Ähnlichem, wenn der Datenverkehr möglicherweise nicht über die Schnittstelle im selben Subnetz austritt, sodass die Quell-IP der zurückkehrenden Pakete unterwegs möglicherweise aufgrund einiger NAT-Regeln geändert wird.

Answer