PXE-Boot über WAN

Ich habe derzeit einen Debian-PC und einen Raspbian Raspberry Pi in meinem Heimnetzwerk hinter meinem Router. Der Router hat einen Port für mich geöffnet, an dem ich ssh in das rPi einführen kann, wenn ich nicht da bin, und wenn ich einmal im Netzwerk bin, kann ich alles tun, was ich im Heimnetzwerk tun möchte.

Auf Reisen scheint die Festplatte meines Debian-PCs gestorben zu sein; Zumindest weigert es sich, hochzufahren.

Ich habe keine Boot-CDs zum Einlegen hinterlassen, da ich die Box immer über PXE gebootet habe. Mein Tomato-Heimrouter ist so konfiguriert, dass er auf eine VM auf meinem Laptop verweist, um die für das Booten eines Linux-Installationsprogramms erforderlichen BOOTP- und TFTP-Images bereitzustellen. System Rescue CD oder Trinity Rescue Kit.

Dieser Laptop ist jetzt mit mir unterwegs.

Kann ich die SSH-Portweiterleitung von meinem Laptop aus einrichten, wenn ich eine Verbindung zu meinem Heim-rPi herstelle und die IP-Adresse vorübergehend auf [Ich denke] umkonfiguriere, dhcp-bootso dass mein Debian-PC PXE-Start mit meiner Remote-Laptop-VM über das Internet ausführen kann?

UPDATE 3. August: Dem folgenden Vorschlag von Matt zu folgen, war ein guter Anfang, aber immer noch nicht vollständig. Ich bin immer noch nicht weiter als vorher.

Der TFTP-Server wartet auf UDP-Port 69, verwendet jedoch die -ROption, sshnur TCP weiterzuleiten.

Dies und das war eine Möglichkeit, um fortzufahren, indem Pipes um den Tunnel herum eingerichtet wurden, um den UDP-Verkehr vor dem Tunnel in TCP und TCP nach dem Tunnel wieder in UDP umzuwandeln. In Kommentaren wurde jedoch darauf hingewiesen, dass dies nicht der beste Weg ist. Das hat auch bei mir nicht funktioniert.

Die Verwendung von socat anstelle der Pipes schien weniger kontrovers zu sein, also dachte ich, ich würde es versuchen, aber das funktionierte auch nicht.

Um zu erfassen, was ich bisher gemacht habe, habe ich versucht, das Problem lokal auf meinem Laptop wie folgt zu replizieren.

Ich habe bereits eine VM, auf der der TFTP-Server auf Port 69 ausgeführt wird, der zumindest eine pxelinux.0Datei bedienen kann.

Ich habe eine neue VM erstellt, die ein ISO-Image der System Rescue CD startet. Beim Booten dieser VM habe ich sie als DHCP-Server eingerichtet:

# vi /etc/dhcp/dhcpd.conf 

In der Datei habe ich Folgendes angegeben:

subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.251 192.168.1.253; option routers 192.168.1.1; filename "pxelinux.0"; next-server 192.168.1.252; } 

Dann habe ich den DHCP-Server neu gestartet:

# /etc/init.d/dhcpd restart 

Hinweis: Ich habe jetzt zwei DHCP-Server in diesem "fremden" Netzwerk - der Router, der meinem Laptop seine IP-Adresse zur Verfügung gestellt hat, und nun diese VM, bis sie heruntergefahren ist. Dies führt zu einer Race-Bedingung, da meine PXE-Boot-VM möglicherweise eine Antwort von einem der DHCP-Server empfängt. Ich hoffe, dass die Antwort meiner VM die erste ist, die die PXE-VM erreicht, damit sie die next-serverobige Anweisung erhalten kann.

In der Praxis mit meinen begrenzten Übungen scheint dies kein Problem zu sein, aber ich möchte meine VM nicht zu lange aufhalten, damit ich hier niemanden störe.

Wie bereits erwähnt, habe ich bei laufendem DHCP-Server meine dritte VM ohne Festplatte gestartet, die für den PXE-Startvorgang eingerichtet wurde, um den PXE-Startvorgang auszuführen.

Der .252-Host war mein PXE-Server, sodass die PXE-Boot-VM sie erreichen konnte, die erforderlichen Dateien über TFTP abrufen konnte und wie üblich mit dem Booten begann.

Als der Nennfall funktionierte, entschied ich mich, den SSH-Tunnel in die Mischung einzuführen, wie Matt es vorgeschlagen hatte.

# vi /etc/dhcp/dhcpd.conf 

Ich next-serverhabe die IP-Adresse der System Rescue CD-VM selbst geändert :

subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.251 192.168.1.253; option routers 192.168.1.1; filename "pxelinux.0"; next-server 192.168.1.13; } 

Dann habe ich den DHCP-Server neu gestartet:

# /etc/init.d/dhcpd restart 

Ich habe auch überprüft, dass auf dieser Box kein TFTP-Server ausgeführt wurde:

# netstat -an | grep 69 

Jetzt konnte meine PXE-Boot-VM nicht booten. Es erhielt eine IP-Adresse vom DHCP-Server, konnte jedoch kein TFTP-Boot-Image abrufen.

Ich habe den öffentlichen Schlüssel meines PXE-Servers übernommen und in die Root- authorized_keysDatei eingefügt.

Von der PXE-Server-VM aus habe ich meinen Tunnel erstellt:

$ ssh -R 69:localhost:69 -R 2049:localhost:2049 root@192.168.1.13 

Hinweis: Port 2049 musste zu diesem Zeitpunkt nicht weitergeleitet werden. Dies ist jedoch für NFS später erforderlich.

Gleiches Problem beim Booten der PXE-VM: Das Image konnte nicht über TFTP abgerufen werden.

Der TFTP-Server hat UDP-Port 69 überwacht:

udp 0 0 0.0.0.0:69 0.0.0.0:* 

Der weitergeleitete Port überwacht jedoch TCP:

tcp 0 0 127.0.0.1:69 0.0.0.0:* LISTEN tcp6 0 0 ::1:69 :::* LISTEN 

Versuchte den ersten Ansatz der Verwendung von Rohren. Auf der System Rescue CD-VM:

# mkfifo /tmp/fifo # nc -v -l -u -p 6963 < /tmp/fifo | nc -v -u 127.0.0.1 6964 > /tmp/fifo 

In der Zwischenzeit auf der PXE-Server-VM:

$ ssh -R 6964:localhost:6965 root@192.168.1.13 $ nc -v -l -p 6965 < /tmp/fifo | nc -v -u localhost 69 > /tmp/fifo 

Ich habe versucht, die Datei von der System Rescue CD-VM manuell zu übertragen:

# tftp localhost 6963 -c get pxelinux.0 connect to [127.0.0.1] from sysresccd.gentoo [127.0.0.1] 51072 too many output retries : Broken pipe 

Das funktionierte immer noch nicht, also versuchte ich erneut, den Tunnel aus der Gleichung herauszunehmen.

System Rescue CD VM:

# nc -v -l -u -p 6963 < /tmp/fifo | nc -v -u 127.0.0.1 6965 > /tmp/fifo 

PXE-Server-VM:

$ nc -v -l -p 6965 < /tmp/fifo | nc -v -u localhost 69 > /tmp/fifo 

Übertragen auf System Rescue CD VM:

# tftp localhost 6963 -c get pxelinux.0 

Das hat immer noch nicht funktioniert, also habe ich mit rm /tmp/fifobeiden Boxen aufgeräumt .

Als Nächstes fuhr ich mit dem socatVersuch fort, aber das hatte ähnliche Ergebnisse. Ich habe den SSH-Tunnel auch dort mit den gleichen Ergebnissen aus der Gleichung herausgenommen.

Dieses Mal konnte ich die System Rescue CD-VM nicht verwenden, da sie nicht socatinstalliert war. Daher habe ich eine andere VM verwendet.

Zunächst wollte ich überprüfen, ob der tatsächliche TFTP-Server noch verfügbar war:

$ tftp 192.168.1.252 tftp> get pxelinux.0 tftp> quit 

Sicher genug, ich habe eine Nicht-Null-Byte-Datei heruntergeladen.

Dies funktionierte nicht, wenn ich eine Box mit nichts auf dem TFTP-Port abhörte:

$ tftp localhost tftp> get pxelinux.0 Transfer timed out.  tftp> quit boots$ rm pxelinux.0 

Zeit zum socatMixen.

Auf dem PXE-Server:

$ ssh -p 22 -R 6969:localhost:6968 192.168.1.7 $ sudo socat UDP4-LISTEN:69,fork TCP4:localhost:6969 

In einem anderen Fenster auf dem PXE-Server:

$ socat -T10 TCP4-LISTEN:6968,fork UDP4:localhost:69 

Das hat immer noch nicht funktioniert:

$ tftp localhost tftp> get pxelinux.0 Transfer timed out.  tftp> quit boots$ rm pxelinux.0 

Update 4 Aug: Ich glaube, ich habe mein Problem gefunden, bin mir aber nicht sicher, wie ich daran vorbeikommen kann.

Ich habe mein Setup noch grundlegender gemacht. Ich habe den SSH-Tunnel komplett beseitigt und an den geraden UDP-Ports festgehalten.

Auf meinem lokalen TFTP-Client einfach Folgendes:

$ sudo socat -d -d -d -d udp4-recvfrom:69,reuseaddr,fork udp:192.168.1.252:69 

Beachten Sie, dass die .252-Box der TFTP-Server ist.

Das hat immer noch nicht funktioniert:

$ tftp localhost tftp> get pxelinux.0 Transfer timed out.  tftp> quit boots$ rm pxelinux.0 

Also habe ich Wireshark sowohl auf den .7- als auch auf den .252-Boxen ausgeführt und habe UDP-Verkehr und insbesondere TFTP-Verkehr betrachtet.

Hier sind meine Capture-Filter für die beiden Wireshark-Instanzen:

• .7: udp und host 192.168.1.252 und port nicht 123
• .252: UDP und Host 192.168.1.7 und Port nicht 123

Als ich das ausführte, sah ich viel TFTP-Verkehr auf einem anderen Port als 69. In diesem Fall gingen Datenpakete von Port 60862 auf dem Quellhost auf 44792 auf dem Ziel, und Bestätigungen kehrten auf diesen Ports zurück.

Laut Wikipedia :

Eine Übertragungsanforderung wird immer als Zielport 69 initiiert, die Datenübertragungsports werden jedoch während der Übertragungsinitialisierung unabhängig von Sender und Empfänger ausgewählt. Die Ports werden nach den Parametern des Netzwerkstapels zufällig ausgewählt, typischerweise aus dem Bereich der kurzlebigen Ports.

Wenn ich das richtig verstanden habe, muss ich mehr als nur Port 69 tunneln. Welche zusätzlichen Befehle benötigen ich, um diese Ports weiterzuleiten? Gibt es eine einfache Möglichkeit, dies zu erreichen?

Update 5 Aug: Ich habe vorher ein anderes Problem.

In Bezug auf das oben aufgeführte Element habe ich versucht, etwas mehr mit TFTP herumzuspielen und die Pakete in Wireshark zu betrachten. Anscheinend bekomme ich das erste Paket von Port 69 von einem beliebigen Quellport. Im letzten Fall war dies Port 48723.

Es stellt sich heraus, dass der TFTP-Server UDP-Pakete über diesen Port von einem anderen Port zurücksendet. Wenn ich das erste Paket an Port 69 überwachen kann, kann ich dies sehen und erwarte, dass ich schnell einen anderen Tunnel auf diesem Port einrichten kann, bevor er das Zeitlimit überschreitet. Der Prozess wird also ein wenig manuell sein, aber ich könnte es tun in der Lage, es abzuziehen.

Jetzt, wo ich genau hinschaue, sieht es so aus, als ob ich das erste Paket überhaupt nicht bekomme socat.

Wenn ich keinen Tunnel habe, sehe ich das ursprüngliche Paket auf Port 69 ohne Probleme.

Wenn ich stattdessen einen direkten socatSSH-Tunnel wie folgt aufstelle, sehe ich kein Paket.

Fenster 1:

$ sudo socat -d -d -d -d udp4-recvfrom:69,reuseaddr,fork udp:192.168.1.252:69 

Fenster 2:

$ tftp localhost tftp> get pxelinux.0 Transfer timed out. 

Hier ist die Ausgabe von netcat:

$ netstat -an | grep 69 | grep udp udp 0 0 0.0.0.0:69 0.0.0.0:* 

Ich habe auch eine Wireshark-Instanz, die auf beiden Seiten läuft. beide zeigen absolut nichts. Hier ist mein Capture-Filter auf beiden Seiten:

udp and not (port 123 or port 5353 or port 1900) 

Ich habe noch eine Frage dazu gestellt.

Update: Ein kleiner Schritt vorwärts. Ich habe den Verdacht, dass ich mit meinem socatBefehl etwas falsch gemacht habe .

Ich habe einen anderen einfachen Test nur auf meinem Laptop ausprobiert.

Fenster 1:

$ sudo nc -v -l -u 69 

Wireshark:

• Hören Sie sich die Schnittstelle an
• Erfassungsfilter: UDP und Port 69

Fenster 2:

$ nc -u 127.0.0.1 69 

Während ich in Fenster 2 tippte, sah ich die Ausgabe in Fenster 1 und sah Pakete, die in Wireshark erfasst wurden.

Dann wiederholte ich mit der Netzwerkkarte meines Laptops:

Fenster 1:

$ sudo nc -v -l -u 69 

Wireshark:

• Hören Sie sich das Interface wlan0 an
• Erfassungsfilter: UDP und Port 69

Fenster 2:

$ nc -u 127.0.0.1 69 

Es stellte sich heraus, dass in Wireshark keine Pakete erfasst wurden, obwohl die Meldungen in Fenster 1 angezeigt wurden. Ich erinnerte mich, dass ich Docker vor einiger Zeit eingerichtet hatte, also hatte ich eine Docker0-Brücke. Ich habe auch ein paar Virtualisierungsprodukte, also störten sie vielleicht.

Ich habe das Wireshark-Capture erneut mit:

• Hören Sie sich die Schnittstelle an
• Erfassungsfilter: UDP und Port 69

Dieses Mal bekam ich alles, was ich wollte. Vielleicht war mein Problem die ganze Zeit die Wireshark-Capture-Schnittstelle.

Stoppen Sie die Netcat-Fenster und machen Sie jetzt einen Schritt zurück:

$ sudo socat -d -d -d -d udp4-recvfrom:69,reuseaddr,fork udp:192.168.1.252:69 

Habe den TFTP-Test noch einmal versucht:

$ tftp localhost tftp> get pxelinux.0 

Das war's! Ich bekomme meine Pakete jetzt in Wireshark!

Ich sehe die Leseanforderungsnachrichten erfasst und es stellt sich heraus, dass alle fünf Versuche / Wiederholungen von demselben Quellport stammen.

Nun ist es Zeit zu sehen, ob ich eine zusätzliche socatSitzung für diesen Quellport manuell einrichten kann . Auf dem TFTP-Server selbst habe ich zusätzlich ausgeführt:

$ for f in 52163; do socat -d -d -d -d udp4-recvfrom:$,reuseaddr,fork udp:192.168.1.7:$; done 

Beachten Sie, dass dies die IP-Adresse meines Laptops hatte. (Die for-Schleife dient lediglich der Bequemlichkeit, sodass ich die Portnummer nur einmal im Befehl angeben muss.)

Es stellt sich heraus, dass jeder der Quellports gleich ist, unabhängig davon, wie oft ich den PXE- get pxelinux.0Befehl ausführt . Die Quellportnummer ändert sich, wenn ich TFTP verlasse und TFTP erneut starte.

Ich habe Wireshark sowohl auf meinem Laptop als auch auf der TFTP-Box ausgeführt. Ich sehe jetzt Pakete auf dem Wireshark meines Laptops, aber nicht auf dem TFTP-Wireshark.

Ich vermute, mit meinem socatBefehl stimmt etwas nicht, aber ich weiß nicht, was es ist:

$ sudo socat -d -d -d -d udp4-recvfrom:69,reuseaddr,fork udp:192.168.1.252:69 

Update: Jetzt, da ich die Grundlagen für netcat habe, dachte ich, ich würde einen Schritt nach oben machen, indem ich socatin den Mix einführe, aber immer noch keinen ssh-Tunnel.

Ich habe meinen lokalen Laptop, und jetzt nennen wir den TFTP-Server die Remote-Box, obwohl es nur eine VM auf meinem Laptop ist.

Fenster 1:

local$ sudo socat udp4-recvfrom:69,reuseaddr,fork udp:192.168.1.13:69 

Fenster 2:

local$ nc -4u localhost 69 

Wireshark läuft auf einer Remote-Box und erfasst den UDP-Verkehr.

In Fenster 2 habe ich drei Zeilen eingegeben und nach jeder Eingabe die Eingabetaste gedrückt: "Eins", "Zwei" und "Drei".

In Wireshark sehe ich drei Pakete auf dem TFTP-Port, daher muss der TFTP-Server diese Mülldaten abrufen. Interessant ist hier, dass jedes der drei Pakete einen anderen Quellport hat.

Als Nächstes habe ich netcat beendet und stattdessen den TFTP-Client mit der lokalen IP-Adresse anstelle von "localhost" ausgeführt, da ich heute davon verbrannt wurde:

local$ tftp 127.0.0.1 tftp> get pxelinux.0 

Jetzt bekomme ich das TFTP Read Request-Paket von meinem lokalen Laptop !!

(Zu Ihrer Information vor dem Erfassen meiner Notizen habe ich "tftp localhost" ausgeführt und wieder nichts erhalten. Es sieht aus wie das in meiner anderen Frage erwähnte IPv4 / IPv6-Problem .)

Nun also zurück zum SSH-Tunnel.

Fenster 1:

remote$ socat tcp4-listen:6901,reuseaddr,fork udp:127.0.0.1:69 

Fenster 2:

local$ ssh -L 6901:127.0.0.1:6901 192.168.1.13 

Fenster 3:

local$ sudo socat udp4-recvfrom:69,reuseaddr,fork tcp:127.0.0.1:6901 

Ich erhalte die Leseanforderungspakete in Wireshark zusammen mit dem ersten Datenpaket, das nicht erreichbar ist, da über den Quellport kein Tunnel zurückgeführt wird. Zumindest bekomme ich die UDP-Pakete über den Tunnel an den TFTP-Server !

Jetzt musste ich ein bisschen über diese Rückreise nachdenken. Mit socatin der Mitte, es sieht aus wie ich bin immer fünf Übertragungsversuche von diesem TFTP - Client, bevor es mal aus; Ich weiß nicht, wie sich der TFTP-Client in der NIC-Firmware verhält.

Für jeden dieser Versuche scheint es, als würde ich jetzt einen anderen Quellport erhalten, da die Verbindung zum TFTP-Server von socatund nicht zum TFTP-Client meines Laptops kommt. Wieder weiß ich nicht, wie sich der in der NIC-Firmware eingebaute TFTP-Client verhält.

Selbst wenn ich den Verkehr überwache und schnell einen Rücktunnel aufbaue, nachdem ich den Verkehr in Wireshark gesehen habe, bin ich mir nicht sicher, ob das zu spät ist.

Ich vermute, das Gleiche wird wahr sein, wenn ich Pfeifen anstelle von benutzt habe socat.

Update: Ich denke, ich bin bereit, dies aufzugeben, aber aus Spaß habe ich gedacht, ich würde in die Originalverpackung zurückkehren und versuchen, ein paar Pakete einzufangen, da ich genug habe, um wenigstens eine Reise in Gang zu bringen.

Meine Vorstellung von "local" und "remote" ist jetzt umgekehrt, da mein TFTP-Server lokal ist, während mein toter PC remote ist.

Fenster 1:

laptop$ ssh user@192.168.1.13 local$ socat tcp4-listen:6901,reuseaddr,fork udp:127.0.0.1:69 

Fenster 2:

laptop$ ssh -R 6901:127.0.0.1:6901 user@remote.fqdn.net remote$ ping -i 60 8.8.8.8 

(Der Ping dient dazu, die Verbindung am Leben zu erhalten, falls sie benötigt wird.)

Fenster 3:

laptop$ ssh user@remote.fqdn.net remote$ sudo socat udp4-recvfrom:69,reuseaddr,fork tcp:127.0.0.1:6901 

Ich habe mir Sorgen gemacht, dass sich der Quellport geändert hat socat, also war ich neugierig, die Pfeifen erneut zu versuchen. Ich ging zurück zu meinem Testaufbau.

Ich halte meine lokalen und Remote-Versionen für die Konsistenz mit der Produktionsumgebung, auch wenn dies für meine Testumgebung rückwärts ist.

Fenster 1:

laptop$ ssh 192.168.1.13 local$ mkfifo /tmp/fifo local$ nc -lp 6901 < /tmp/fifo | nc -u 127.0.0.1 69 > /tmp/fifo 

Fenster 2:

laptop$ ssh 192.168.1.13 local$ ssh -R 6902:127.0.0.1:6901 192.168.1.7 remote$ ping -i 60 8.8.8.8 

Fenster 3:

remote$ mkfifo /tmp/fifo remote$ sudo nc -lup 69 < /tmp/fifo | nc 127.0.0.1 6902 > /tmp/fifo 

Ich habe ein einfaches TFTP aus meinem TFTP-Client wieder versucht. Dieses Mal habe ich in Wireshark festgestellt, dass der Quellport für jedes Paket gleich ist! Vielleicht gibt es noch Hoffnung !!

Denken Sie daran, dass die UDP-Pakete unterhalb der Größe der MTU bleiben. Ich glaube, ich habe irgendwo gelesen, dass sie für TFTP sein werden.

Ich muss meine Pfeifen aufräumen:

local$ rm /tmp/fifo remote$ rm /tmp/fifo 

Ich wollte das jetzt in der Produktion ausprobieren.

Fenster 1:

laptop$ ssh user@192.168.1.13 local$ mkfifo /tmp/fifo local$ nc -lp 6901 < /tmp/fifo | nc -u 127.0.0.1 69 > /tmp/fifo 

Fenster 2:

laptop$ ssh user@192.168.1.13 local$ ssh -R 6901:127.0.0.1:6901 user@remote.fqdn.net remote$ ping -i 60 8.8.8.8 

(Der Ping dient dazu, die Verbindung am Leben zu erhalten, falls sie benötigt wird.)

Fenster 3:

laptop$ ssh user@remote.fqdn.net remote$ mkfifo /tmp/fifo remote$ sudo -i remote$ nc -lup 69 < /tmp/fifo | nc 127.0.0.1 6901 > /tmp/fifo 

Als ich den PC hochgefahren hatte, bekam ich laut Wireshark ein ganzes TFTP-Paket zum PXE-Server, aber ich erhielt keine Wiederholungsversuche. Ich hatte gehofft, auch die Wiederholungen zu bekommen und dass alle den gleichen Quellport hätten.

Ich habe die ncEinstellungen auf der linken Seite der Pipes geändert -k, um anzugeben, dass sie am Leben bleiben sollen, und habe dann einen Neustart durchgeführt, aber immer noch nur das erste Paket erhalten.

Ich muss meine Pfeifen aufräumen:

local$ rm /tmp/fifo remote$ sudo rm /tmp/fifo