123788
Nov 12, 2021
2453
17
0
Wireguard: Admin-Zugang zu Netzwerk
Hallo zusammen,
ich würde gern Wireguard einsetzen, um mir einen Admin (ein Laptop)-Zugang zu einem bestehenden LAN zu verschaffen.
Wie ich Point-to-Point-Verbindungen mit Wireguard aufbaue ist mir grundsätzlich klar.
Mein Problem besteht nun darin, dass ich das zugehörige Routing noch nicht verstanden habe.
Ich könnte eine klassische Jumphost-Konfiguration nutzen: Mir in der DMZ des Netzes einen VServer aufsetzen, auf welchen ich mich dann mit Wireguard und SSH verbinde. Von dort könnte es weiter auf die eigentlich zu administrierenden Systeme gehen.
Es sollen sowohl Linux-Server, als auch einige Systeme mit GUI administriert werden.
Daher genügt mir als Jumphost leider kein schlankes Konsolen-Linux, es müsste eine GUI her und z.B. xrdp eingesetzt werden, um RDP nutzen zu können.
Das alles scheint mir doch recht umständlich.
Ich würde gern "direkt vom Laptop aus" auf z.B. eine der entfernten GUIs oder eine der entfernten SSH-Shells zugreifen. Das kann man doch bestimmt wesentlich einfacher mit Routing lösen, welches man über Wireguard konfiguriert?
Könnt ihr mir hier weiterhelfen?
ich würde gern Wireguard einsetzen, um mir einen Admin (ein Laptop)-Zugang zu einem bestehenden LAN zu verschaffen.
Wie ich Point-to-Point-Verbindungen mit Wireguard aufbaue ist mir grundsätzlich klar.
Mein Problem besteht nun darin, dass ich das zugehörige Routing noch nicht verstanden habe.
Ich könnte eine klassische Jumphost-Konfiguration nutzen: Mir in der DMZ des Netzes einen VServer aufsetzen, auf welchen ich mich dann mit Wireguard und SSH verbinde. Von dort könnte es weiter auf die eigentlich zu administrierenden Systeme gehen.
Es sollen sowohl Linux-Server, als auch einige Systeme mit GUI administriert werden.
Daher genügt mir als Jumphost leider kein schlankes Konsolen-Linux, es müsste eine GUI her und z.B. xrdp eingesetzt werden, um RDP nutzen zu können.
Das alles scheint mir doch recht umständlich.
Ich würde gern "direkt vom Laptop aus" auf z.B. eine der entfernten GUIs oder eine der entfernten SSH-Shells zugreifen. Das kann man doch bestimmt wesentlich einfacher mit Routing lösen, welches man über Wireguard konfiguriert?
Könnt ihr mir hier weiterhelfen?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1500525701
Url: https://administrator.de/contentid/1500525701
Printed on: May 8, 2024 at 22:05 o'clock
17 Comments
Latest comment
ich würde gern Wireguard einsetzen, um mir einen Admin (ein Laptop)-Zugang zu einem bestehenden LAN zu verschaffen.
Ein simpler Klassiker... 
Ich könnte eine klassische Jumphost-Konfiguration nutzen:
Das wäre ja überflüssiger Unsinn wenn du einen klassischen Internet Zugang hast. Einen Jumphost brauchst du ausschliesslich nur dann wenn du ein DS-Lite_Opfer eines Billigproviders bist der dir keine öffentliche IPv4 Adresse am Router bietet.Wenn du einen klassischen Internet Zugang hast brauchst du das nicht, dann platzierst du den Wireguard Server einfach im internen LAN und machst am Router ein simples Port Forwarding auf den Server, so das am Router eingehende Wireguard Sessions auf den lokalen Wireguard Server weitergereicht werden.
Hier siehst du wie so ein Wireguard Standard Szenario aussieht...
Ideal ist aber wie immer ein Design wo der VPN Server in der Peripherie sitzt auf Router oder Firewall sprich also der WG Server direkt auf dem Router liegt.
Das ist aber nicht immer möglich wenn man einen Zwangsrouter besitzt oder einen Router der keine Wireguard Funktion hat. In dem Falle greift dann immer das o.a. Design mit Port Forwarding.
Welche Endgeräte du dann wie über das VPN administrierst ist vollkommen Wumpe und spielt für das VPN an sich keinerlei Rolle.
Am Laptop machst du einfache inen Klick auf das VPN, so das der Tunnel aufgebaut wird und startest dann einfach deine Anwendung mit der du deine remoten Hosts administrieren willst. Ob per RDP oder SSH oder was auch immer ist dabei völlig unerheblich.
Der tiefere Sinn eines VPNs ist ja gerade das du mit dem Laptop exakt die gleiche Umgebung hast und nutzt die du auch im lokalen LAN hast.
Ein VPN ist übrigens immer Routing. Man hat den leisen Verdacht bei deinem o.a. Thread das du das Prinzip eines VPNs noch nicht wirklich durchdrungen hast...kann das sein ?
Nun, ich würde hier durchaus überlegen einen Jumpserver zu nutzen. Das hat auch weniger mit den IP-Adressen zu tun sondern damit das man eben das Netz etwas besser absichern kann...
Ich habe z.B. bei uns überall nen Jumpserver an Board über den eben einige Zugriffe möglich sind - nur: Erst muss man sich an die Konsole per SSH-Key anmelden. Ausser SSH ist da auch nix offen (und root-login natürlich auch nicht). Damit gibt es genau EINEN Einstiegspunkt den ein externer erst mal kennen muss... Und selbst wenn dann muss er/sie immer noch den Zugang dazu erst mal schaffen.
Von da brauche ich auch keine graphischen Dinge -> wofür auch? Wenn ich DAHINTER auf einen Server z.B. per RDP gehen will mache ich halt per SSH-Portforwarding die Weiterleitung. Was also dafür sorgt das ein evtl. Angreifer auch DA nochmal die Zugangsdaten nich nur zum Jump sondern auch zum Zielsystem benötigt...
Klar - wann immer es geht würde ich nen "richtiges" VPN vorziehen, aber einen "Jumpserver" als "Unsinn" zu bezeichnen den man nur braucht wenn man keine öffentlichen IPs hat sehe ich eher anders. Es geht eben nicht in jeder Umgebung ein VPN (z.B. grad bei Kunden-Netzen muss man da ggf. erst mal nen Kunden von überzeugen) - und selbst innerhalb des VPNs möchte ggf. ein Kunde nicht das man gleich wahrlos auf alles zugriff hat bzw. bei Site2Site-Netzen das jeder "von der anderen Seite" da was tun kann...
Ich habe z.B. bei uns überall nen Jumpserver an Board über den eben einige Zugriffe möglich sind - nur: Erst muss man sich an die Konsole per SSH-Key anmelden. Ausser SSH ist da auch nix offen (und root-login natürlich auch nicht). Damit gibt es genau EINEN Einstiegspunkt den ein externer erst mal kennen muss... Und selbst wenn dann muss er/sie immer noch den Zugang dazu erst mal schaffen.
Von da brauche ich auch keine graphischen Dinge -> wofür auch? Wenn ich DAHINTER auf einen Server z.B. per RDP gehen will mache ich halt per SSH-Portforwarding die Weiterleitung. Was also dafür sorgt das ein evtl. Angreifer auch DA nochmal die Zugangsdaten nich nur zum Jump sondern auch zum Zielsystem benötigt...
Klar - wann immer es geht würde ich nen "richtiges" VPN vorziehen, aber einen "Jumpserver" als "Unsinn" zu bezeichnen den man nur braucht wenn man keine öffentlichen IPs hat sehe ich eher anders. Es geht eben nicht in jeder Umgebung ein VPN (z.B. grad bei Kunden-Netzen muss man da ggf. erst mal nen Kunden von überzeugen) - und selbst innerhalb des VPNs möchte ggf. ein Kunde nicht das man gleich wahrlos auf alles zugriff hat bzw. bei Site2Site-Netzen das jeder "von der anderen Seite" da was tun kann...
Du meinst dann ein VPN auf SSH Tunneling Basis ganz ohne WG, also das bekannte "VPN für Arme" ?
VPN für Arme - TCP in SSH tunneln mit Putty
VPN für Arme - TCP in SSH tunneln mit Putty
Zitat von @aqui:
Du meinst dann ein VPN auf SSH Tunneling Basis ganz ohne WG, also das bekannte "VPN für Arme" ?
VPN für Arme - TCP in SSH tunneln mit Putty
Du meinst dann ein VPN auf SSH Tunneling Basis ganz ohne WG, also das bekannte "VPN für Arme" ?
VPN für Arme - TCP in SSH tunneln mit Putty
nicht zwingend darauf begrenzt.... selbst innerhalb des VPNs kann es ja gründe geben nen jumphost zu bauen. Selbst als Dienstleister kann es von Vorteil sein weil man eben seine Applikation nicht im ganzen "lokalen" Netz freigeben muss sondern Admin-Schnittstellen nur auf die IP vom Jump begrenzen kann. So kann man dann bequem z.B. sicherstellen das der Kunde nicht unerlaubt rumfummelt (klar KANN der das umgehen, aber für gewöhnlich reicht das schon) bzw. das man eben zumindest sehen kann wenn der Kunde sich am JH angemeldet hat das es ne Änderung gab... Oder eben Protokollierung,....
Von daher KANN ein JH auch im VPN durchaus Sinn machen - es hängt eben von der Anforderung ab. Aber die Aussage
---quote---
aqui 13.11.2021 aktualisiert um 09:15:13 Uhr
Goto Top
ich würde gern Wireguard einsetzen, um mir einen Admin (ein Laptop)-Zugang zu einem bestehenden LAN zu verschaffen.
Ein simpler Klassiker...
face-winkIch könnte eine klassische Jumphost-Konfiguration nutzen:
Das wäre ja überflüssiger Unsinn wenn du einen klassischen Internet Zugang hast. Einen Jumphost brauchst du ausschliesslich nur dann wenn du ein DS-Lite_Opfer eines Billigproviders bist der dir keine öffentliche IPv4 Adresse am Router bietet.
---/quote---
ist eben in der generellen Form schlichtweg falsch.
Na ja, aber mal im Ernst: welchen tieferen Sinn sollte ein JH haben wenn man eine klassische Internet Anbindung hat und kein DS Lite Opfer ist ?
Er ist dann nur ein Kosten erzeugender "Durchlauferhitzer" der wenig bis kein Vorteil hat in einem VPN Umfeld. Welcher sollte es auch sein ? Würde ja niemand machen wenn man es nicht müsste...
Es sei denn...wir reden hier von DS-Lite. Da sieht die Welt dann natürlich wieder anders aus.
Er ist dann nur ein Kosten erzeugender "Durchlauferhitzer" der wenig bis kein Vorteil hat in einem VPN Umfeld. Welcher sollte es auch sein ? Würde ja niemand machen wenn man es nicht müsste...
Es sei denn...wir reden hier von DS-Lite. Da sieht die Welt dann natürlich wieder anders aus.
Hallo zusammen
Danke bis hierher für eure rege Diskussion!
Für's Verständnis: Das zu administrierende "Netz" (es geht nicht um's tatsächliche Netz, aber das ist hier nebensächlich) hat eine Firewall, die WireGuard unterstützt, insofern kann der Tunnel direkt darauf laufen. Auch ist ein statische IPv4 vorhanden, ergo kein DS-Lite usw.
Das Prinzip von VPN habe ich auch soweit verstanden, ich habe bloß noch nicht begriffen, wie ich konkret das Routing dafür einrichte.
Ich mach mal ein plumpes Beispiel:
Das ferne LAN habe 10.1.0.0/24, mein VPN bekommt 10.2.0.0/24.
Wie richte ich WireGuard nun so ein, dass das Routing zwischen den Netzen für meinen Client "transparent" funktioniert?
Im fernen LAN gibt es div. VLANs (insb. natürlich für Management) in die ich dann hinein routen muss. Diese haben alle verschiedene IP-Bereiche, aber vmtl. muss ich das dann ja "nur" analog umsetzen.
Sind meine heimischen IP-Bereiche dafür in irgendeiner Weise relevant? Ich frage, weil es vllt. Überschneidungen der Adressvergabe geben könnte.
Danke bis hierher für eure rege Diskussion!
Für's Verständnis: Das zu administrierende "Netz" (es geht nicht um's tatsächliche Netz, aber das ist hier nebensächlich) hat eine Firewall, die WireGuard unterstützt, insofern kann der Tunnel direkt darauf laufen. Auch ist ein statische IPv4 vorhanden, ergo kein DS-Lite usw.
Das Prinzip von VPN habe ich auch soweit verstanden, ich habe bloß noch nicht begriffen, wie ich konkret das Routing dafür einrichte.
Ich mach mal ein plumpes Beispiel:
Das ferne LAN habe 10.1.0.0/24, mein VPN bekommt 10.2.0.0/24.
Wie richte ich WireGuard nun so ein, dass das Routing zwischen den Netzen für meinen Client "transparent" funktioniert?
Im fernen LAN gibt es div. VLANs (insb. natürlich für Management) in die ich dann hinein routen muss. Diese haben alle verschiedene IP-Bereiche, aber vmtl. muss ich das dann ja "nur" analog umsetzen.
Sind meine heimischen IP-Bereiche dafür in irgendeiner Weise relevant? Ich frage, weil es vllt. Überschneidungen der Adressvergabe geben könnte.
insofern kann der Tunnel direkt darauf laufen.
Perfekt !wie ich konkret das Routing dafür einrichte.
Gar nicht !!!Wireguard basiert auf dem sog. Crypto Key Routing:
https://www.wireguard.com/#cryptokey-routing
Sprich mit deinem Peer Key wird dynmaisch bzw. automatisch auch immer die richtige Route für den Client Peer aktiviert.
Mit anderen Worten du musst dafür NICHTS extra konfigurieren bzw. erledigst das schlicht und einfach mit dem Paramater "Allowed IPs".
Beispiel am Client wenn dein WG Server die 10.2.0.1 /24 hat und du IP Netze 192.168.1.0 bis 192.168.31.0 /24 und 172.16.0.0 bis 172.16.15.0 hast.
Im Client steht dann:
AllowedIPs = 10.2.0.1/32, 192.168.0.0/19, 172.16.0.0/20
Das routet dann alle diese IP Netze vom Client in den WG Tunnel.
Eigentlich eine sehr einfache Logik !
Ich frage, weil es vllt. Überschneidungen der Adressvergabe geben könnte.
Die musst du natürlich zwingend vermeiden. Jeder Laie weiss ja mittlerweil das IP Netze immer einzigartig sein müssen. Klar, denn sonst wäre eine eindeutige Wegefindung ja technisch völlig unmöglich.Es gilt also in einem VPN Umfeld immer auf eine möglichst intelligente IP Adressierung zu achten !
Guckst du dazu auch HIER.
Ah super, das liest sich alles recht überschaubar schwer!
Ich weiß jetzt bloß noch nicht, wie ich die verschiedenen IP-Bereiche hin bekommen soll.
Denn ich arbeite des öfteren auch mal von anderen Orten und kann schwer ausschließen, dass der dortige Hotspot zufällig den selben Adressbereich wie bspw. das Management-VLAN nutzt...
Gibt's da Abhilfe?
Ich weiß jetzt bloß noch nicht, wie ich die verschiedenen IP-Bereiche hin bekommen soll.
Denn ich arbeite des öfteren auch mal von anderen Orten und kann schwer ausschließen, dass der dortige Hotspot zufällig den selben Adressbereich wie bspw. das Management-VLAN nutzt...
Gibt's da Abhilfe?
dass der dortige Hotspot zufällig den selben Adressbereich wie bspw. das Management-VLAN nutzt...
Da bleibt natürlich immer ein gewisses Restrisiko, das ist klar.Es macht also Sinn in einem VPN Umfeld dann nicht diese dümmlichen Allerwelts IPs wie 192.168.0.0, .1.0, .178.0 usw. zu verwenden die alle Speedports, FritzBoxen dieser Welt auch benutzen.
Wenn du dort etwas intelligente IP Netze aus dem 10er Kontingent oder dem recht wenig genutzen 172.16er Kontigent der RFC 1918 IPs nutzt minimierst du diese potentielle Gefahr schon mal recht erheblich.
Gibt's da Abhilfe?
Ja, natürlich: Indem DU als Netzwerk Admin entsprechend intelligentes IP Adressing betreibst !! 
Zitat von @aqui:
Na ja, aber mal im Ernst: welchen tieferen Sinn sollte ein JH haben wenn man eine klassische Internet Anbindung hat und kein DS Lite Opfer ist ?
Er ist dann nur ein Kosten erzeugender "Durchlauferhitzer" der wenig bis kein Vorteil hat in einem VPN Umfeld. Welcher sollte es auch sein ? Würde ja niemand machen wenn man es nicht müsste...
Es sei denn...wir reden hier von DS-Lite. Da sieht die Welt dann natürlich wieder anders aus.
Na ja, aber mal im Ernst: welchen tieferen Sinn sollte ein JH haben wenn man eine klassische Internet Anbindung hat und kein DS Lite Opfer ist ?
Er ist dann nur ein Kosten erzeugender "Durchlauferhitzer" der wenig bis kein Vorteil hat in einem VPN Umfeld. Welcher sollte es auch sein ? Würde ja niemand machen wenn man es nicht müsste...
Es sei denn...wir reden hier von DS-Lite. Da sieht die Welt dann natürlich wieder anders aus.
Der Jumphost kann auch eine klassische Adminstation sein, auf der die netzspezifischen Tools installiert sind.
Das hat viele Vorteile, zB geringe Latenzen, Daten die das Netzwerk nicht verlassen etc.
Er erleichtert die Konfig, reduziert die Komplexität und erhöht damit prinzipiell die Sicherheit.
OK, da hast du Recht. Vermutlich hat der Kollege @maretz es auch so gemeint. Das wäre dann in der Tat ein Argument aber ob es die Kosten und Vorteile dann wirklich wettmacht ist dann wieder eine andere Betrachtung. Mal nicht zu reden von der Sicherheit die ja auch noch ein Punkt ist.
Wenn Du mehr als einen Techniker, mehr als einen Laptop hast und der/die Laptops dann auch noch für den "normalen" Alltag genutzt werden, dann ist ein JH eigentlich immer sicherer, zumindest wenn mit irgendwelchen Tools auf die produktiven Server zugegriffen wird.
Die Kosten für einen JH sind in der Regel doch minimal, wie gesagt, gerade wenn Du mehrere Admins hast und nicht für jeden Admin einen eigenen JH vorhältst.
Aus der Sicht einen Systemhauses, dass dann bei jedem Kunden JH warten müsste, also die Anzahl der JH deutlich höher ist als die Anzahl der Admins, ist das etwas anderes und die wenigsten Systemhäuser werden das so machen.
Die Kosten für einen JH sind in der Regel doch minimal, wie gesagt, gerade wenn Du mehrere Admins hast und nicht für jeden Admin einen eigenen JH vorhältst.
Aus der Sicht einen Systemhauses, dass dann bei jedem Kunden JH warten müsste, also die Anzahl der JH deutlich höher ist als die Anzahl der Admins, ist das etwas anderes und die wenigsten Systemhäuser werden das so machen.
Gut, da hast du Recht. Problem ist aber dann wenn 5 Techniker zugleich mit RDP auf irgendwelche Server zugreifen wollen. Mit einem JH kann ja immer nur einer zur Zeit oder man muss verschiedenen TCP Ports nutzen.
Aber OK, sind ja alles kosmetische Fragen. Beide Optionen führen ja problemlos zum Ziel. Muss der TO sich nur das für ihn Schönste aussuchen.
Aber OK, sind ja alles kosmetische Fragen. Beide Optionen führen ja problemlos zum Ziel. Muss der TO sich nur das für ihn Schönste aussuchen.
Ich hätte da auch eine Lösung, die den anderen Technikern zeigt, dass die Session gerade genutzt wird ;)
Zitat von @aqui:
Gut, da hast du Recht. Problem ist aber dann wenn 5 Techniker zugleich mit RDP auf irgendwelche Server zugreifen wollen. Mit einem JH kann ja immer nur einer zur Zeit oder man muss verschiedenen TCP Ports nutzen.
Aber OK, sind ja alles kosmetische Fragen. Beide Optionen führen ja problemlos zum Ziel. Muss der TO sich nur das für ihn Schönste aussuchen.
Gut, da hast du Recht. Problem ist aber dann wenn 5 Techniker zugleich mit RDP auf irgendwelche Server zugreifen wollen. Mit einem JH kann ja immer nur einer zur Zeit oder man muss verschiedenen TCP Ports nutzen.
Aber OK, sind ja alles kosmetische Fragen. Beide Optionen führen ja problemlos zum Ziel. Muss der TO sich nur das für ihn Schönste aussuchen.
Warum? Natürlich kann man doch zig Forwards machen?
Host 1: ssh -L 8080:123.123.123.123:80 user1@deinjh
Host 2: ssh -L 8080:123.123.123.123:80 user2@deinjh
(sofern eben Host1 + Host2 von verschiedenen IPs kommen)
sollte zumindest problemlos gehen. Habe ich aber aktuell nicht getestet da es bei mir eher nicht vorkommt das mehrere Leute zur selben Zeit zum Selben Host ne verbindung aufm gleichen Port aufmachen wollen (und ich idR eh andere Ports dann nehme)
Hi zusammen
Danke für euren Input!
Für mich ist WG da interessanter als SSH. Allein schon, weil es sehr einfach einzurichten ist.
Für mich ist eher das lokale IP-Netz das Problem.
Das habe ich nun so umgangen, dass ich mir eine Admin-VM aufgesetzt habe, die ein eher ungewöhnliches Netz verwendet.
Somit habe ich weder hier, noch Remote Probleme.
Es sei denn, ihr seht da noch andere Schwierigkeiten?
Danke für euren Input!
Für mich ist WG da interessanter als SSH. Allein schon, weil es sehr einfach einzurichten ist.
Für mich ist eher das lokale IP-Netz das Problem.
Das habe ich nun so umgangen, dass ich mir eine Admin-VM aufgesetzt habe, die ein eher ungewöhnliches Netz verwendet.
Somit habe ich weder hier, noch Remote Probleme.
Es sei denn, ihr seht da noch andere Schwierigkeiten?
Allein schon, weil es sehr einfach einzurichten ist.
Einfach ist immer relativ. Für die meisten ist IPsec oder OpenVPN auch einfach... Es sei denn, ihr seht da noch andere Schwierigkeiten?
Nope, alles OKWenns das denn war bitte den Thread dann auch als erledigt schliessen:
How can I mark a post as solved?
