= Kann per LAN-Peering zum VPS/Cloud-Server alle Eingaben von zwei anderen LAN-Systemen tunneln? =
Darf ich das machen?
Dedizierte WG-Box auf LAN-Tunneln zum VPS/Cloud-WG-Server. Diese lokale WG-Box hat mehrere Ethernet-Schnittstellen. Kann es ungetunnelte Eingaben von zwei anderen LAN-Boxen entgegennehmen und durch den WG-Tunnel an den VPS/Cloud-Server weiterleiten? Außerdem kann eine dieser anderen LAN-Boxen SSH mit der WG-Box mit einer anderen Ethernet-Verbindung verbinden?
Zusammenfassung der kabelgebundenen Schnittstellen der LAN WG-Box:
1: zur LAN-Seite des Routers, für WAN-Zugriff und für SSH mit einem Mac;
2. der Mac über den Router für zu tunnelnden Datenverkehr;
3. die andere LAN-Box für den zu tunnelnden Verkehr.
Der Mac würde seinen zu tunnelnden Datenverkehr an Schnittstelle 2 und den SSH-Datenverkehr an Schnittstelle 1 ausgeben; Beide Schnittstellen verbinden sich mit dem Router. Schnittstelle 3 wird direkt mit der anderen LAN-Box verbunden. Alle LAN-Adressen befinden sich im selben Subnetz und sind statische Adressen.
Probleme, die ich bisher sehe: Ich denke, die WG-Box muss den Verkehr durch NAT tunneln (zusätzlich zum VPS-Serverit wieder); wenn ja, gibt es da ein problem? Und wie kann der SSH-Verkehr vom Tunnel isoliert werden?
Alle LAN-Adressen befinden sich im selben Subnetz und sind statische Adressen.
Es ist eine schlechte Idee, mehrere LANs mit demselben Subnetz zu haben. Jedes LAN sollte sein eigenes Subnetz verwenden. Und die WG-Box sollte nicht mehrere Schnittstellen haben, die mit demselben Subnetz verbunden sind.
Sie sollten NAT auf der WG-Box nicht verwenden müssen, stattdessen sollten Sie die LAN-Subnetze in „allowed-ips“ auf dem Cloud-WG-Server konfigurieren.
Edit: ersetzt durch meine nächste Antwort
OK, hier ist meine Überlegung, nachdem Sie die Multi-Subnetz-Glühbirne angezündet haben. Im Moment gibt es nur ein Subnetz, 192.16816. Es gibt viele Boxen/Hosts/Geräte darauf – Telefone, Thermostate, Computer, Heimkinokomponenten usw. – zusätzlich zu den drei in meinem OP erwähnten (die ich jetzt als 1_LAN_WG_box, 2_ Mac und 3_andere_LAN_box).
Nehmen wir an, 2_Mac wird 172.16.0.6 und 3_other_LAN_box wird 172.17.0.7. Der ETH1-Anschluss der LAN WG-Box bleibt auf 192.16816. Sein ETH2-Anschluss wird zu 172.16.0.2 (Subnetz von 2_Mac) und sein ETH3-Anschluss wird zu 172.17.0.1 (Gateway im Subnetz von 3_other_LAN_box). Das beseitigt das lokale NAT-Problem.
Ich möchte den Mac nicht ständig im VPN haben, sondern nur gelegentlich als Webclient. Ich hatte vor, die Proxy-Server-Browserfunktion mit der LAN-WG-Box als Proxy nur dann einzuschalten, wenn ich das VPN verwenden möchte. Ich glaube, ich habe noch nicht erwähnt, dass die LAN-WG-Box kopflos ist; Ich möchte den Mac verwenden, um ihn über SSH zu steuern und zu konfigurieren. Gleiches gilt für 3_other_LAN_box.
Der Mac, 172.16.0.6, verbindet sich per SSH mit der LAN-WG-Box an deren Adresse 192.16816. Dafür gebe ich dem Hauptrouter eine statische Route. Wenn ich möchte, dass der Mac-Browser das VPN verwendet, verwendet er die ETH2 172.16.0.2-Adresse der LAN WG-Box als Browser-Proxy.
3_other_LAN_hat nur einen RJ45-Anschluss. Es wird die LAN-WG-Box als Gateway verwenden. Wenn 3_other_LAN_box eine Verbindung zu einem Switch herstellt, kann der Mac über eine statische Route des Hauptrouters SSH mit der 3_other_LAN_box verbinden.
Ich schätze, das ist mein erstes Netzwerkdesign! Ein verbleibendes Problem besteht darin, den SSH-Verkehr der LAN-WG-Box vom Tunnel zu isolieren. Ich habe einige Gedanken dazu, aber wenn die Antwort auf meine allgemeine Frage "Kann das funktionieren?"ist ja, ich werde dieses Thema für einen anderen Beitrag verlassen. Auch für einen anderen Beitrag werden die WG-Konf-Dateien enthalten sein, die dieses LAN-Design aufnehmen -- es sei denn, es funktioniert alles bei meinem ersten Versuch!
(Ich habe versucht, diesen Kommentar deutlich zu machen, aber ich verstehe, dass er viele Details enthält. Ich weiß Ihre Hilfe zu schätzen!)
Es gibt einige Aspekte meiner vorherigen Antwort von 13 Uhr. vor, dass ich denke, dass es wahrscheinlich nicht funktioniert, also fange ich von vorne an. Sie können diese Antwort ignorieren, wenn Sie möchten.
Gesamtbild: Ich habe eine kopflose Ubuntu-Box ("WGbox"), mit der ich zwei lokale Geräte, einen Mac und einen kopflosen Datenserver ("DS") mit dem lokalen Ende eines WG-Tunnels zu einem WG-Server auf einem verbinden möchte Cloud-VPS. DS wird rund um die Uhr getunnelt, der Mac jedoch nur gelegentlich. Sowohl die WGbox als auch DS benötigen SSH-Zugriff vom Mac, da sie kopflos sind.
WGbox hat vier RJ45-Anschlüsse. Im Moment habe ich ein LAN-Subnetz, 192.168.1.0/24. Aufgrund der virtuellen Routing-Anforderungen von WG benötige ich mindestens ein zusätzliches Subnetz, um zwei Geräte (Mac und DS) zu tunneln.
Wenn ich zuerst den Mac betrachte, möchte ich gelegentlich den Browser-Webverkehr über WGbox tunneln und in der Lage sein, SSH zu WGbox zu senden, wenn ich keinen Webverkehr tunnele. Derzeit ist die einzige verwendete kabelgebundene Schnittstelle der WGBox 198.168.1.10 zugewiesen und ich SSH vom Mac, der 198.168.1.200 ist.
Wie wäre es, wenn ich ein Subnetz für den Mac mit einem Gateway wie 172.16.0.1/24 hinzufüge und dieses einer zweiten kabelgebundenen Schnittstelle auf der WGbox zuweise. Wenn ich den Mac tunneln möchte, ändere ich die IP/das Gateway des Mac auf 172.16.0.1/172.16.0.1. Da sich der Hauptrouter im 192.168-Subnetz befindet, müsste ich normalerweise eine Brücke in seine iptables einfügen, um zu 172.16.0.1 zu routen. Aber da der Mac und die WGbox am selben Switch angeschlossen sind, kann ich denke ich die Bridge umgehen.
Glaubst du, das funktioniert? Wenn ja, gehe ich zum Tunneling und SSH-Zugriff für das DS-Gerät über. Wenn nicht, teilen Sie mir bitte Ihre Gedanken zur Behebung mit.
"Die WG-Box sollte nicht mehrere Schnittstellen haben, die mit demselben Subnetz verbunden sind."Warum? Ich argumentiere nicht, ich jammere nur, da ich denke, dass ein Verstoß gegen diese Regel meine Aufgabe vereinfachen würde, und ich würde gerne den Grund dafür wissen.
Ich verstehe das vielleicht falsch (langer Tag), aber was hindert Sie daran:
- Verwenden Sie die WGbox als LAN-Gateway für alle Geräte, die Sie dauerhaft durch den Tunnel leiten möchten (Sie müssten dies auf den jeweiligen Geräten einrichten und Ihr DHCP-Setup vom Standard-LAN-Gateway entweder aufgeben oder erschweren)?
- Einrichten eines Proxys auf der WGbox, den Sie auf den Geräten, die Sie verwenden, nach Belieben ein- und ausschalten können
*will nicht* permanent geroutet?
Keine Notwendigkeit (IMHO und schnell gelesen), mit verschiedenen Subnetzen, mehreren Netzwerkverbindungen usw. herumzuspielen. Es sei denn, mir fehlt etwas. Unabhängig davon würde ich Ihnen wärmstens empfehlen, die "IoT"-Geräte (mindestens) in ein anderes Netzwerk zu trennen.
Ein Problem, wenn sich alle Geräte im selben Subnetz befinden, ist die Anforderung, dass die WGbox den Tunnelverkehr per NAT ausführen muss. Ich nehme an, das ist nicht unbedingt fatal, aber es scheint verschwenderisch angesichts der Tatsache, dass das Cloud-VPS-Ende des Tunnels auch NAT haben muss. Es erschwert auch die WGbox-Konfiguration. Aber es vermeidet Komplikationen durch das Einrichten der zusätzlichen Subnetze und deren Bindung in meinem Hauptrouter.
Was das beliebige Ein-/Ausschalten des Tunnelings für das Surfen im Internet von meinem Mac betrifft, hatte ich daran gedacht, eine der WGbox-Schnittstellen als Proxy in meinem Webbrowser einzurichten (meinen Sie das?). Stellen Sie fest, dass der Browser für HTTPS ein CONNECT an den Proxy-Server ausgibt, um einen Tunnel zum Ziel-Webserver aufzubauen. Ich bin mir nicht sicher, was die WGbox mit dem CONNECT machen wird. Allgemeiner denke ich, dass eine Firewall-Konfiguration erforderlich wäre, um zu vermeiden, dass WGbox den Webverkehr des Mac vor WireGuard fallen lässt oder ablehnt. Oder vielleicht würde AllowedIPs 0.0.0.0/0 für die Peer-Abschnitte die permissive Zugriffssteuerung automatisch konfigurieren.
Es stellt sich heraus, dass es (bisher) nur ein Gerät gibt, den Headless-Datenserver, den ich für seine Kernfunktion getunnelt haben möchte. Ich sage "Kernfunktion", weil ich als Headless SSH-Zugriff darauf von einem Mac benötige. Das, nicht DHCP (was ich leicht handhaben kann), ist es, was die Einstellung von WGbox als Gateway erschwert. Außerdem benötigt es während SSH-Sitzungen vorzugsweise ungetunnelten WAN-Zugriff für Betriebssystemaktualisierungen usw.
== Über diese Community ==
Mitglieder
Online
Reddit
