Forum: PC Hard- und Software Heimnetzzugriff über Wireguard-Container


von Matthias S. (da_user)


Lesenswert?

Servus,

ich möchte von unterwegs aus auf mein Heimnetzwerk (Subnetz 
192.168.178.x) zugreifen und hätte mir dafür Wireguard ausgesucht. Meine 
FB ist leider zu alt, und bekommt dafür ein Update, also habe ich mir 
einen Container gesucht: "https://hub.docker.com/r/weejewel/wg-easy";

Die Einrichtung hat auch Grundsätzlich super einfach funktioniert. Ich 
kann mich mit meinem Handy einloggen, das bekommt die IP 10.8.0.2 
zugeteilt. Der Rechner auf dem der Container läuft hat die 
192.168.178.24.

Ich kann jetzt mit meinem Handy mit verbundenen Wireguard z.B. auf 
wieistmeineip.de gehen und bekomme meine heimische öffentliche IP 
angezeigt. Das scheint also zu funktionieren.

Was ich leider nicht kann, ist auf meine Dienste innerhalb meines 
Heimnetzwerkes zuzugreifen. Ich habe in der FB bereits eine statische 
IPv4-Route angelegt:
IPv4-Netzwerk: 10.8.0.0
Subnetzmaske: 255.255.255.0
Gateway: 192.168.178.24
und natürlich Haken bei "IPv4-Route aktiv".

Was mache ich hier falsch, oder welche Einstellungen muss ich noch 
treffen?

VG
da_user

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Matthias S. schrieb:
> Ich habe in der FB bereits eine statische IPv4-Route angelegt:
Da scheint noch einiges mehr notwendig zu sein:
- 
https://administrator.de/tutorial/merkzettel-vpn-installation-mit-wireguard-660620.html

von Motopick (motopick)


Lesenswert?

Vermutlich greift dein Wischfon eben nicht ueber das
> IPv4-Netzwerk: 10.8.0.0
auf deine heimischen Clients zu, so dass die Route fuer die Katz ist.
Pruefe mal mit welcher IP die Anfragen kommen.

Ein Tunnel ist eben ein Tunnel und nicht unbedingt trivial routbar.

Mein Ansatz war daher etwas anders. Die internen Endpunkte der
Tunnel endeten in einem Subnetz des internen Netzes und wurden
per Post-NAT auf diese Adressen per Tunnel umgeschrieben.
Damit musste am internen Routing exakt gar nichts geaendert werden.
Clientzugriffe erschienen so, als waeren sie aus dem internen Netz
erfolgt.

Der Haken dabei sind nur bidirektional arbeitende Protokolle
wie VoIP die damit natuerlich lang hinschlagen.
Und natuerlich das gute alte FTP im Aktivmodus. :)

von Εrnst B. (ernst)


Lesenswert?

Wireguard ist ein Layer-3-VPN.
Für das richtige "Wie im lokalen Netz angeschlossen"-Feeling brauchst du 
ein Layer-2-VPN, damit kannst du die VPN-Clients ins Netzwerk bridgen, 
sie werden Teil der Broadcast-Domain, melden sich selber am 
Fritzbox-DHCP an etc.

Wenn die Broadcast-Domain nicht so wichtig ist: Dann kannst du bei 
Wireguard mit NAT/MASQUERADE, Proxy-ARP etc. was hinbasteln.
Docker dazwischen (mit seinen eigenen Netzwerk-Namespaces etc) macht das 
nicht einfacher, aber auch nicht unmöglich.

von Matthias S. (da_user)


Lesenswert?

Hi,

Danke für den Input. Dass das Routen ins Heimnetz mit Wireguard so ein 
Aufwand ist, wusste ich nicht. Ich habe mich gefreut, dass das VPN 
grundsätzlich so einfach einzurichten war.

Was würde sich den als Alternative anbieten? Insbesondere in Hinblick 
auf diese Layer 2 VPNs und was gerne im Docker läuft?

von Motopick (motopick)


Lesenswert?

Es ist nichts schlechtes an Layer3 VPNs.

Manches braucht eben aber auch ein wenig Durchhaltevermoegen.
Wenn etwas nicht wie vorgesehen funktioniert, muss man den Fehler
suchen und beseitigen.

von Ich A. (alopecosa)


Lesenswert?

Matthias S. schrieb:
> Danke für den Input. Dass das Routen ins Heimnetz mit Wireguard so ein
> Aufwand ist, wusste ich nicht. Ich habe mich gefreut, dass das VPN
> grundsätzlich so einfach einzurichten war.
>
> Was würde sich den als Alternative anbieten? Insbesondere in Hinblick
> auf diese Layer 2 VPNs

Ich weiß nicht wo das Problem sein soll.

Wireguard läuft hier direkt auf dem UniFi Security Gateway, war binnen 
weniger Minuten eingerichtet und konfiguriert. Gleiches auf dem Android 
Phone.

Εrnst B. schrieb:
> Für das richtige "Wie im lokalen Netz angeschlossen"-Feeling brauchst du
> ein Layer-2-VPN,

Mein Smartphone, wie auch mein Notebook verhalten sich genauso ...



Matthias S. schrieb:
> und was gerne im Docker läuft?

Vielleicht solltest du genau diesen Ansatz wieder verwerfen. Bringt nur 
eine zusätzliche mögliche Fehlerquelle rein.

von Εrnst B. (ernst)


Lesenswert?

Ich A. schrieb:
> Mein Smartphone, wie auch mein Notebook verhalten sich genauso ...

Fast alles geht ja auch per Layer3.

Wenn du aber willst, dass sich die VPN-Clients auch am zentralen DHCP 
melden (damit der die im DNS bekannt machen kann), dass sie Broadcasts 
empfangen können (Zeroconf&co) usw, dann geht das eben am einfachsten 
per Layer2.

Bei Layer3 ist da etwas Frickelei nötig.
Gut wenn VPN-Server, Gateway, DHCP, DNS alles auf derselben Kiste läuft, 
egal ob Fritte oder Unify, dann hat jemand anderes diese Frickelarbeit 
schon für dich erledigt, und es geht Out-Of-the-Box.

Bei Wireguard-VPN aus einem Docker-Container abseits vom Router ist das 
schwieriger... ich würde mir mit network-mode=host das Leben dort etwas 
leichter machen, aber dann kann man's auch gleich ohne Docker laufen 
lassen.

von Christoph Z. (christophz)


Lesenswert?

Matthias S. schrieb:
> Ich kann jetzt mit meinem Handy mit verbundenen Wireguard z.B. auf
> wieistmeineip.de gehen und bekomme meine heimische öffentliche IP
> angezeigt. Das scheint also zu funktionieren.

Hast du eine Möglichkeit die Routingtabelle deines Telefons anzuzeigen 
und hier zu posten?

von C-hater (c-hater)


Lesenswert?

Motopick schrieb:

> Ein Tunnel ist eben ein Tunnel und nicht unbedingt trivial routbar.

Unsinn. Das ist so einfach wie mit jedem anderen Interface auch. Man muß 
einfach nur begriffen haben, wie Routing funktioniert.

Und man muß begriffen haben, dass (in der konkreten Situation mit 
VPN-Gateway irgendwo im LAN) auch der "Chef" des LAN (also das, was für 
alle LAN-Teilnehmer das default gateway ist), passend konfiguriert 
werden muß.

Wenn man jedenfalls irgendwas wirklich absolut garnicht braucht, um 
einen Tunnel vernünftig zu routen, dann ist das wohl NAT, in welcher 
Form auch immer...

von Motopick (motopick)


Lesenswert?

> Unsinn. Das ist so einfach wie mit jedem anderen Interface auch.

Naja, dann mach mal.

> dann ist das wohl NAT

Du hast NAT eben nicht verstanden. :)

von Michael W. (dbru61)


Lesenswert?

NAT Masquerading im VPN ist völlig überflüssig und kontraproduktiv. Und 
wofür Broadcasts über eine VPN-Verbindung gut sein sollen ist auch nicht 
klar. Das produziert nur überflüssigen,nichtssagend traffic.
Zum Problem: Netzwerk und routinngeinstellungen im Client kontrollieren, 
transfernetzadresse mit 32er Maske, fb-netz mit 24er-maske eintragen und 
keine catch-all Adresse. Hin und Rückroute prüfen.
Im link zum Administrator-forum steht ja schon alles drin

Viel erfolg

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.