Standard Gateway umbiegen
Guten Tag,
ich habe eine etwas dumme Frage aber aus der Notwendigkeit heraus Frage ich trotzdem.
Ich habe das Problem das ich ein Geräte hinter einem OPEN VPN fähigen Linux Router habe auf dem das Standard Gateway falsch eingestellt ist.
Gibt es eine Möglichkeit das ich durch einen Trick auch ohne der richtigen Einstellung auf diesen Gerät aus dem Vpn raus zugreifen kann? Irgendwie dem Gerät vorgauckeln das es Trafik aus dem Lokalennetz ist?
Danke für die Hilfe
ich habe eine etwas dumme Frage aber aus der Notwendigkeit heraus Frage ich trotzdem.
Ich habe das Problem das ich ein Geräte hinter einem OPEN VPN fähigen Linux Router habe auf dem das Standard Gateway falsch eingestellt ist.
Gibt es eine Möglichkeit das ich durch einen Trick auch ohne der richtigen Einstellung auf diesen Gerät aus dem Vpn raus zugreifen kann? Irgendwie dem Gerät vorgauckeln das es Trafik aus dem Lokalennetz ist?
Danke für die Hilfe
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7207068825
Url: https://administrator.de/contentid/7207068825
Ausgedruckt am: 25.11.2024 um 19:11 Uhr
25 Kommentare
Neuester Kommentar
Kollege @lks hat Recht. Mache mit iptables oder nftables Source NAT (Masquerade) auf dem Linux Rechner über das lokale ethx LAN Interface.
So "merken" die lokalen Rechner auf die du zugreifen willst nicht das du aus einem fremden IP Netz kommst, da du bei ihnen mit der lokalen Absender IP des Linux LAN Interfaces auftauchst.
Damit trägst du dann eine feste statische Route auf das interne OpenVPN IP Netz im Default Gateway ein und fertig ist der Lack!
Alle Details dazu stehen im OpenVPN Tutorial.
So "merken" die lokalen Rechner auf die du zugreifen willst nicht das du aus einem fremden IP Netz kommst, da du bei ihnen mit der lokalen Absender IP des Linux LAN Interfaces auftauchst.
Damit trägst du dann eine feste statische Route auf das interne OpenVPN IP Netz im Default Gateway ein und fertig ist der Lack!
Alle Details dazu stehen im OpenVPN Tutorial.
Zitat von @Legofrau:
Guten Abend,
wie kann ich mich über den vpnrouter auf das Gerät verbinden? wie meinst du das?
Zitat von @Lochkartenstanzer:
Moin,
Verbinde dich vom vpnrouter heraus auf das Gerät oder mache NAT.
lks
Moin,
Verbinde dich vom vpnrouter heraus auf das Gerät oder mache NAT.
lks
Guten Abend,
wie kann ich mich über den vpnrouter auf das Gerät verbinden? wie meinst du das?
z.B. per ssh und von dort aus dann weiter, z.B. per Portforwarding oder direkt per ssh weiter. Aber du müßtest einmal genauer darlegen, welcher Art denn die Verbindung sein soll.
lks
erklärst mir wie ich das anstelle?
WAS nutzt du denn auf deinem VPN Linux Router?? iptables oder nftables??Wenn es ein aktuelles Debian ist (Bullseye) dann macht Debian nur noch nftables.
Ein Masquerading konfiguriert man dann so:
https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Add ...
Für die älteren iptables so:
HIER kannst du dir das einmal im Detail an einem einfachen Praxisbeispiel mit einem Linux Host als IKEv2 VPN Server für alle onboard VPN Clients ansehen wie das genau auszusehen hat!
Das Allereinfachste wird sicher sein wie es der Kollege @MirkoKR oben schon gesagt hast die machst eine Shell Connection (PuTTY etc.) auf dein Linux System auf sofern du zugriff darauf hast.
Von dort aus verbindest du dich dann auf die Systeme im lokalen Netz. Da der Linux Router ja auch eine lokale IP Adresse in dem Netz hast klappt das fehlerlos.
Von Linux Host/Router kannst du dann auf dem dortigen Internet Router bzw. den Default Gateway der dortigen Endgeräte (oder den Endgeräten selber) eine feste, statische Route ins OpenVPN Netz einrichten und kommst auch ganz ohne NAT zu einer schnellen Lösung.
Die NAT/ Masquerading Lösung brauchst du nur wenn das ein Dauerzustand bleiben soll ohne statische Route ins OpenVPN Netz.
Ist dazu nur eine statische Route vom Subnet des Routers zu der VPN IP meines Rechners?
Die ganze Routing Thematik im VPN ist HIER genau erklärt:Merkzettel: VPN Installation mit OpenVPN
Lesen und verstehen...
Dauerzustand sollte es keiner werden.
Hoffentlich, denn so ist dein VPN ja mehr oder minder völlig unbrauchbar. Wie gesagt es ist eine einzige popelige Route die am Default Gateway der Endgeräte statisch eingetragen werden muss um das Problemchen zu fixen. Danach möchte ich aber auch das NAT/ Masquerading probieren.
Das Masquerading solltest du wirklich nur dann machen wenn du keine Chance hast eine korrekte Route einzutragen. Durch das NAT/Masquerading im VPN machst du deinen VPN Router immer zu einer Einbahnstrasse, denn danach kann er nicht mehr transparent bidirektional routen weil man dann das NAT Gateway einseitig nicht mehr überwinden kann.Sprich NAT ist immer nur einem Krücke und Notlösung mit den o.a. nachteiligen Auswirkungen auf das Routing.
Sorry wenn ich wieder nerve.
Keine Sorge, das tust du nicht, dafür ist ein Forum ja da... 😉Mein Netzwerk sieht so aus.
Sprich die FritzBox ist dann eigentlich dein Router und OpenVPN Server?? Oder ist das eine Kaskade mit FritzBox und Linux Router?Das ist dann eine ganz klassische OpenVPN Vernetzung wie sie hier:
OpenVPN - Erreiche Netzwerk hinter Client nicht
im Detail beschrieben ist.
Dort ist alles zum Thema Routing beschrieben. Leider wird aus deiner Zeichnung nicht ersichtlich WER hier jetzt OpenVPN Client (Initiator) und WER OpenVPN Server (Responder) ist. Das hat aber einen erheblichen Einfluss auf die Konfiguration. Das hiesige OpenVPN Tutorial zeigt dir ja Schritt für Schritt auf wie es richtig geht.
Statische Routen muss man in so einem Setup nicht definieren, das passiert alles über die OpenVPN Konfiguration selber wenn es richtig aufgesetzt ist. Hier machst du sehr wahrscheinlich einen weiteren fatalen Denkfehler. Deshalb hat die Frickelei mit den Routen auch keinerlei Effekt. Mit Routenfrickelei kann man ein falsches Setup bekanntlich nicht fixen!
Um hier überhaupt erstmal weiterzukommen solltest du strategisch vorgehen und zuallererst einmal dein OpenVPN Setup des Clients und des Servers hier anonymisiert (ohne Zerts) posten und WER diese Rollen laut Skizze einnimmt.
In einem Setup wie deinem wäre (normalerweise) der vServer der VPN Server (Responder) und Router sowie die mobilen Clients die VPN Clients (Initiators).
Mit großer Wahrscheinlichkeit liegt der Fehler schon in einem falschen OpenVPN Setup an sich!
Das zeigt sich schon offen daran das du unterschiedliche interne OpenVPN IP Netze für die Clients und den Router definiert hast, was so nicht sein sollte und sehr wahrscheinlich (einer) der Kardinalsfehler im Setup ist. Hier ist also schon etwas im Argen?!
Was den Zugriff auf das Endgerät ohne Gateway anbetrifft ist klar das du mit einer Absender IP aus dem internen OpenVPN IP Netz dieses nie erreichen kannst. Ohne jeglichen Gateway Eintrag kann dieses Gerät einzig nur lokale IP Clients im eigenen 192.168.137.0er Netz erreichen.
Klar, denn Traffic der dort aus fremden IP Netzen ankommt kann wegen des fehlenden Gateways nicht rückgeroutet werden. Hier ist also NAT (IP Adress Translation gefordert)
NAT zu aktivieren macht aber erstmal nur dann Sinn wenn die OpenVPN Verbindung an sich sauber und stabil rennt.
Dann kannst du nämlich entweder über den vServer oder die mobilen Clients per SSH (PuTTY) eine Shell Verbindung via SSH und VPN auf den Linux Router machen. Von dort aus solltest du ALLE Endgeräte im lokalen 192.168.137.0er Netz erreichen können (Ping etc.) auch das ohne Gateway.
Logisch, denn der Linux Router hat ja eine eigene Absender IP in diesem IP Netz, kommt damit also nicht aus einem fremden IP Netz.
Bis dahin solltest du überhaupt erst einmal kommen, denn das verifiziert dann dein sauber funktionierendes VPN Backbone.
Wenn das der Fall ist kannst du im 2ten Schritt mit NAT weitermachen sofern du auf dem betroffenen Endgerät keine Chance hast ein Gateway einzutragen.
Mal nebenbei gefragt:
Warum machst du dir mit OpenVPN das Leben schwer? Ein Setup mit dem modernen und deutlich schnelleren Wireguard VPN wäre mit deinem o.a. Design mit mobilen Clients und Router deutlich einfacher umzusetzen. Von der besseren Performance mal nicht zu reden. Gibts da einen triftigen Grund für OpenVPN?
habe einfach ein Bild aus dem Forum geklaut
Das musst du gar nicht. Mit Dia http://dia-installer.de und den freien Cisco Topology Icons machst du das im Handumdrehen selber. Mein Setup funktioniert einwandfrei
Stimmt, das war nicht ganz klar. Obwohl (auch wenns klappt) die zwei unterschiedlichen internen IP Netze sind definitiv ein Design Fehler aber nundenn... Haken dran wenn's rennt.Realisierung dieser NAT IP Adress Translation.
OK, mit nftables ist das schnell erledigt...Die /etc/nftables.conf editieren und am Ende unter dem Default Ruleset das folgende hinzufügen:
table ip nat {
define VPN_NETS = {
10.0.24.0/24, 10.43.137.0/24
}
# Masquerade OpenVPN Clients zum eth0 Interface
chain postrouting {
type nat hook postrouting priority 100; policy accept;
ip saddr $VPN_NETS oif eth0 masquerade
}
}
Was es macht ist selbsterklärend. Aller Traffic der von Absender IPs kommt die von Netzen aus denen in VPN_NETS definierten kommen, werden auf die IP Adresse des lokalen LAN Interface welches ins 192.168.137er Netz geht übersetzt.
Musst du ggf. noch auf dein Interface Namen ändern sollte das nicht eth0 sein.
ist auf dem Router noch Iptables und nicht nftables.
OK, das ist dann genauso einfach:sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 😉
Willst du das NAT nur für spezielle Absender IPs machen dann so:
sudo iptables -t nat -A POSTROUTING -s 10.0.24.0/24 -o eth0 -j MASQUERADE
P.S.: Bitte nicht immer überflüssigerweise alles zitieren. Wir können alle lesen...
Zitate helfen schon, aber nur, wenn man das Wesentliche zitiert und nicht immer alles.
Also ab und zu einen Ausschnitt zitieren, damit man sieht, worauf die Antwort sich bezieht, ist schon in Ordnung, so wie ich das jetzt gemacht habe.
lks
Also ab und zu einen Ausschnitt zitieren, damit man sieht, worauf die Antwort sich bezieht, ist schon in Ordnung, so wie ich das jetzt gemacht habe.
lks
Habe dann versucht anstelle von eth0 br-lan einzusetzen.
br-lan ist ein Bridge Interface vermutlich supportet oder arbeitet der Router mit VLAN Optionen?!Das br-lan Interface ist dann das native Interface (untagged Default VLAN, PVID1). Siehe dazu auch hier:
Netzwerk Management Server mit Raspberry Pi
Wie du siehst nutzt du ja dann vermutlich VLANs auf dem Linux Router! (Was du übrigens auch schon einmal VORHER hättest sagen können! Ebenso das dein Linux in Wahrheit ein Teltonika Router ist. 😡)
Du musst also herausfinden welches der dortigen Subinterfaces in das 192.168.137.0/24 er Netzwerk geht. Laut deinem Output oben ist das keins der Interfaces denn dieses Netz ist dort nicht präsent.
Mit anderen Worten dein Linux/Teltonika Router ist gar nicht mit dem 192.168.137.0er Netz verbunden oder du hast uns hier mit deiner IP Adressierung an der Nase herumgeführt.
Logischerweise sind dadurch dann alle NAT Konfigs völlig sinnfrei wenn die Netz IP nicht stimmt.
So sieht die Ausgabe von Ip a & ip r aus
Kann es vielleicht sein das dein hier gepostetes 192.168.137.0er Netz in Wahrheit ein 10.43.137.0/24er Netz ist?? Das br-lan interface hat ja wundersamerweise jetzt statt .128 eine .137 bekommen... Ansonsten ist es dann das br-lan Interface und die iptables musst du mit dem Masquerading dann mit "-o br-lan" auf dieses Interface loslassen.
Könnte die Nat Einstellung in der Gui zur Lösung beitragen?
Ja, natürlich. Das würde dir die CLI Fricklei ersparen!Hier trägst du als Source Netz oder Zone dein internes VPN IP Netz ein und als NAT interface das lokale LAN.