☰

seltsame NAT-Probleme mit pfSense zu Vagrant VM

tag-icon • tag-icon linux-networking pfsense vagrant docker-networking
seltsame NAT-Probleme mit pfSense zu Vagrant VM

Das hier hat mich verwirrt:

Ich habe eine pfSense-Firewall (nennen wir sie pfs) und dahinter mehrere Server. Ich verbinde mehrere Dienste von meiner öffentlichen IP per NAT mit verschiedenen Servern im LAN, ohne dass es zu Problemen kommt.

Auf einem der Server (nennen wir ihn s1) betreibe ich eine vagrant(mit libvirt) VM (nennen wir sie v1) mit einemöffentlichNetzwerk konfiguriert, welches die IP 192.168.1.159über pfseinen DHCP-Server bezieht.

Jetzt konfiguriere ich ein einfaches NAT auf , um auf das SSH von pfszuzugreifen , und greife beispielsweise auf darauf zu . Kein Problem.s1<wan>:6622 -> s1:22mydomain.com:6622

Ich kann auch mit einem gültigen SSH-Benutzer auf v1:22(oder das Äquivalent ) zugreifen192.168.1.159:22aus dem LANohne Problem.

Jetzt füge ich ein einfaches NAT hinzu pfs, sagen wir <wan>:6722 -> v1:22. Jetzt versuche ich aufmydomain.com:6722 nichtarbeiten?!

Das Ziel besteht darin, noch „eine weitere Ebene“ hinzuzufügen: Container mit öffentlichen Ports auszuführen, zB --publish 9980:80auf v1und auf sie zuzugreifen, zB v1:9980und von mydomain.com:9980mit dem entsprechenden NAT auf pfswie <wan>:9980 -> v1:9980.Aus dem LANdies funktioniert auch wie erwartet (dh ich kann v1:9980vom LAN aus zugreifen), über NAT jedoch pfsnicht.

Ich habe ähnliche Setups, die innerhalb desselben Netzwerks auf verschiedenen Maschinen ohne Probleme funktionieren. Ich habe sogar eine andere (nicht vagrante, aber auch libvirt) VM, auf s1die ich über NAT über meine öffentliche IP problemlos SSH herstellen kann. Aber irgendwie funktioniert das oben genannte mit der vagrantMaschine nicht, und ich bin wirklich ratlos, was dieses Problem verursachen könnte. (FWIW: Ich habe net.ipv4.forwardes auf aktiviert v1).

BEARBEITEN:

Ich bin einen Schritt näher gekommen: Wenn ich die erste vorhandene Netzwerkkarte der vagrantVM mit lösche virt-managerund die zweite VM auf rtl8139anstelle von einstelle virtio(und dann neu starte), verliere ich vagrant sshdie Funktionalität, aber NAT funktioniert dann. Die Frage ist also: Wie konfiguriere ich über vagrantProvisioning so, dass wir eine ähnliche Konfiguration haben? Ich nehme an, das bedeutet dann, dass das öffentliche Netzwerk auf der Standardschnittstelle sein muss?

Antwort1

Lösung:

Der Grund dafür ist, dass vagrantdie lokale Schnittstelle (privates Netzwerk) als primäre Schnittstelle benötigt wird (und daher konfiguriert wird), ohne dass es eine Standardmethode gibt, um dies zu überschreiben. (Einige Informationen sindHier, aber die vagrantLeute geben zu, dass sie selbst von dem Thema verwirrt sind …)

Eine (robustere) Variante des Konzepts zur Optimierung der Standardrouten brachte die Lösung. Ich verwende einen ansibleProvisioner, in dem ich Folgendes ausführe (auf dem Gast über das Provisioning-Playbook):

  - name: remove wrong default route on eth0 (again)
    shell: |
      eval $(route -n | awk '$0~/[.0]{4}/ && $3~/[.0]{4}/ && $8~/eth0/ { printf "ip route del default via %s dev %s; ",$3,$8 }')

(Interessanterweise muss es zweimal ausgeführt werden (oder nach einer Weile?), möglicherweise, weil das Netzwerk noch nicht vollständig hochgefahren war, als das Bereitstellungsskript gestartet wurde?)

Dadurch wird die Standardroute auf entfernt eth0(die nur automatisch von public_networkkonfiguriert wird ) und externe Verbindungen funktionieren wie erwartet. Dies liegt vermutlich (hier wird spekuliert) daran, dass Antworten auf eingehende NAT-Anfragen standardmäßig über die Standardroute auf an die Firewall weitergeleitet werden (die standardmäßig Priorität hat), was die NAT-FW verwirrt, da sie über die VM eingegangen ist . Daher werden standardmäßig Antworten auf externe Anfragen auf derselben Schnittstelle entfernt , über die sie eingegangen sind.eth1vagranteth0vagranteth1eth0

verwandte Informationen