Ich suche nach dem entsprechenden Macos-Befehl für Linux:
sudo iptables -t nat -A POSTROUTING -o en0 -j MASQUERADE
Der Grund, warum ich dies tun möchte, ist, dass ich ein VPN mit der Standardroute habe, aber möchte, dass bestimmte Apps über den physischen Uplink und nicht über das VPN laufen.
Mit pfctlhabe ich Folgendes getan:
pass out route-to (en0 192.168.4.1) group skipvpn flags any
Wo 192.168.4.1ist die IP meines Gateways? Und es scheint, dass alle Pakete von Apps in der skipvpnGruppe an die en0Schnittstelle (und nicht an den Tunnel) weitergeleitet werden. Ich überprüfe dies mittcpdump
Die „Quell-IPs“ aller umgeleiteten Pakete weisen jedoch noch immer die Quell-IP des VPN (eine 10.0.0.0/8Bereichs-IP) auf, was natürlich zu Störungen führt (d. h. zurückkommende Pakete finden nie wieder den Weg zurück).
Daher habe ich versucht, natdie Quell-IPs folgendermaßen zu ermitteln:
nat on en0 from any to any -> en0
Aber dasNICHTscheint zu funktionieren, die Quell-IPs sind immer noch defekt und entsprechen nicht der Quell-IP meiner en0Schnittstelle.
Wie stelle ich sicher, dass die Quell-IPs für diese umgeleiteten Pakete richtig eingestellt sind?
Antwort1
— Mac OS Pf erledigt das nicht für Sie. Hier ist der Grund:
Wenn Sie einen Blick in das Handbuch werfen würden, würden Sie feststellen, dassNAT wird durchgeführtVorFilterung. NAT-Regeln unterstützen jedoch nicht alle Arten von Kennzeichen, wie dies bei Filterregeln der Fall ist. Insbesondere gibt es keine Möglichkeit, während der NAT-Ausführung den Besitz des Sockets zu überprüfen. Sie können die Anwendbarkeit von NAT-Regeln beispielsweise anhand von Quell- oder Ziel-IPs einschränken, nicht jedoch anhand des Besitzes.
Eine weitere zu erwähnende Sache istWährend der NAT-Verarbeitung führen Pfs eine normale Routensuche durch. Das bedeutet, dass Sie überhaupt nichts tun müssen – die Pakete werden in diesem Moment gemäß der Routing-Tabelle des Kernels geroutet. In Ihrem Fall werden sie über die Schnittstelle der Standardroute, also die VPN-Schnittstelle, gesendet. Und sie würden die Adresse der VPN-Schnittstelle als ihre Quell-IPs verwenden – was bei normalen Routensuchen nicht überraschend ist, aber offensichtlich nicht zu Ihrem Plan passt.nat on en0
Um die Widersprüche kurz zusammenzufassen:
- Wenn Sie kein NAT verwenden, haben Sie eine falsche Quell-IP, wenn
route-todiese angewendet wird - Ihre NAT-Regel sollte auf die Standardroutenschnittstelle (VPN) eingestellt werden, während Sie die Quell-IP auf die IP von ändernNicht-VPNSchnittstelle, wie:
nat on vpn0 … -> (en0) - Andererseits ist kein benutzerdefiniertes NAT (nach Eigentümerschaft) möglich, und wenn Sie trotzdem NAT verwenden, hätte der Datenverkehr, der über VPN laufen soll, die falsche Quell-IP.
PS Der aktuelle Stand der Dinge in Mac OS Pf istnoch schlimmer. Nachdem NAT abgeschlossen ist, funktioniert die Eigentümerschaftsübereinstimmung auch in Filterregeln nicht mehr.