Ich habe ein Homelab-Setup mit ein paar Raspberry Pi, die verwendenAvahifür Serviceankündigungen - ich kann per SSH auf sie zugreifen, ssh pi@<hostname>.localanstatt mir einzelne IP-Adressen merken zu müssen. Beachten Sie insbesondere, dass dies nicht nur von meinem Laptop aus funktioniert, sondern auch von den Pis selbst - das heißt, wenn ich per SSH auf verbunden bin pi1, kann ich erfolgreich .ssh [email protected]
Ich habe vor kurzem einWireguard VPNläuft auf einem der Pis, damit ich auch von unterwegs auf mein Homelab zugreifen kann. Wenn ich dieses VPN auf meinem Laptop verwende, kann ich mit SSH auf einen Pi zugreifen ssh pi@<LAN-IP-address-of-pi>, abernichtmit ssh pi@<hostname>.local.
Warum ist das so? Mein (zugegebenermaßen grundlegendes) Verständnis von VPNs ist, dass sie so funktionieren, dass sich Ihre Verbindung so verhält, „als ob“ sie vom VPN-Server stammt. Wenn das der Fall ist, warum sollte ich dann über ein VPN ein anderes SSH-Verhalten erhalten als vom VPN-Server selbst? Oder, wenn das nicht der Fall ist, was ist daran falsch?
Mein Instinkt sagt mir, dass die DNS-Auflösung nicht über das VPN läuft. Wenn ich die Ergebnisse von dig pi.localmeinem über VPN verbundenen Laptop und vom VPN-Server vergleiche, erhalte ich unterschiedliche Ergebnisse (ich gebe nicht die gesamte Nutzlast frei, da ich nicht genug über Netzwerke und Sicherheit weiß, um zu wissen, was sicher freigegeben werden kann und was nicht):
- von meinem Laptop aus
;SERVERverweist die Zeile8.8.8.8(meiner Meinung nach handelt es sich dabei um einen Standard-DNS-Server von Google, der die IP-Adresse meines Pi im LAN korrekterweise „nicht kennt“) - vom VPN-Server
;SERVERverweist die Zeile auf die LAN-IP-Adresse meines LANsPi-Loch
Interessanterweise enthält jedoch keine der Antworten einen ANSWERAbschnitt oder die tatsächliche IP-Adresse des Pi.
Antwort1
Meiner Intuition nach läuft die DNS-Auflösung nicht über das VPN
Ob dies der Fall ist oder nicht, hat keine Auswirkungen auf mDNS (Avahi). Die .localNamen werden von einem separaten mDNS-Resolver aufgelöst, der nicht den standardmäßigen Unicast-DNS-Resolver verwendet, und der Sinn von mDNS besteht darin, dass es ohne DNS-Server funktioniert; es funktioniert, indem ein Abfragepaket an das gesamte lokale Subnetz gesendet wird.
(Technisch gesehen ist es Multicasting, aber da es auf den Link beschränkt ist, können Sie so tun, als wäre es dasselbe wie eine lokale Übertragung.)
Eigentlich sollte man nichtbeliebig„ANSWER“-Antworten von dig whatever.local, selbst wenn auf Pi-Hole verwiesen wird. Falls Sie eine Antwort von Pi-Hole erhalten, ist das nicht Avahi/mDNS – das ist nur normales DNS. (Heimrouter implementieren lokales DNS, indem sie Hostnamen aus DHCP-Lease-Anfragen sammeln; aber sie sammeln normalerweise keine mDNS-Werbung, selbst wenn Sie zufällig .localals DNS-Domäne haben – was Sie nicht sollten.)
Warum ist das so? Mein (zugegebenermaßen grundlegendes) Verständnis von VPNs ist, dass sie so funktionieren, dass sich Ihre Verbindung so verhält, „als ob“ sie vom VPN-Server stammt. Wenn das der Fall ist, warum sollte ich dann über ein VPN ein anderes SSH-Verhalten erhalten als vom VPN-Server selbst? Oder, wenn das nicht der Fall ist, was ist daran falsch?
Allgemeiner gesagt funktionieren VPNs durchVerbinde dichzusammen mit dem VPN-Server an ein Netzwerk an. Man könnte sagen, sie bilden ein virtuelles LAN über das Internet. SienichtIhre Verbindungen müssen nicht unbedingt maskiert werden oder es so aussehen lassen, als ob Sie sich „als ob“ der VPN-Server verbinden würden – das wird bei Bedarf separat erledigt. (Maskierung ist keine VPN-spezifische Funktion, es ist genau dasselbe NAT, das bei physischen LANs verwendet würde.)
(Das ist, abgesehen von der Unterscheidung der OSI-Schicht, der eigentliche Unterschied zwischen VPNs und Proxys. Der Hauptzweck eines Proxyservers besteht darin, Anfragen so weiterzuleiten, dass sie „so kommen, als ob sie“ vom Proxy kommen. Der Hauptzweck eines VPN besteht darin, ein virtuelles Netzwerk aufzubauen.)
Die meisten VPN-Typen verbinden Sie nicht direkt mit dem VPN-Server.bestehendeNetzwerk, sondern schaffen eineneueins. Sie haben zwei separate Netzwerke – das VPN-erstellte „LAN“ und das physische LAN – wobei der VPN-Server fungiertals Routerdazwischen. Wie ein physischer Router eth0 eth1 eth2oder LAN/WAN routet Ihr VPN-Server zwischen eth0(dem LAN) und wg0(dem WireGuard VPN).
Genau wie bei zwei physischen Subnetzen, die durch einen Router getrennt sind, können die beiden reguläre (Unicast-)Pakete zwischen Geräten austauschen, aber ein Router leitet keineLokale Sendungenzwischen Subnetzen, noch leitet es Link-Scope-Multicasts weiter, die mDNS verwendet. Wenn Ihr VPN-Client also eine mDNS-Multicast-Abfrage sendet, geht diese nur bis zum „lokalen“ Subnetz zwischen VPN-Client und VPN-Server. Sie wird nie von der wg0-Schnittstelle des Servers über eth0 oder sonst etwas weitergeleitet. Damit dies funktioniert, müsste der VPN-Server wahrscheinlich seinen eigenen Avahi-Daemon im „Relay“- oder „Reflector“-Modus ausführen, wo er empfangene mDNS-Abfragen an andere Schnittstellen weiterleitet und Antworten zurücksendet.
Darüber hinaus emulieren viele VPN-Verbindungen keine „broadcastfähige“ Schnittstelle wie Ethernet, was die Nutzung von Broadcast- und Multicast-Paketen von vornherein unmöglich macht. Insbesondere WireGuard bildet eine Art „Point-to-Multipoint“-Netzwerk, bei dem es sich unter der Haube eher um eine Reihe von Eins-zu-eins-Verbindungen handelt – alle sind hinter einer einzigen wg0-Schnittstelle verborgen, aber intern verwendet es AllowedIPs, um zu entscheiden, an welchen Peer jedes Paket gesendet werden soll, und es macht keine Ausnahme für Broadcasts oder Multicasts. Ungefähr dasselbe gilt für OpenVPN in seinem standardmäßigen „tun“-Modus (oder für fast alles andere, das „tun“-Schnittstellen verwendet).
Aber einige andere VPNs, wie OpenVPN im "Tap"-Modus, sowie Software wie Tinc oder ZeroTier,Tunemulieren ein Ethernet-ähnliches Netzwerk mit Layer-2-Adressierung, sodass sie Multicasts und Broadcasts auf konventionellere Weise handhaben können. Tatsächlich emulieren sie meist nur normales Ethernet, sodass der VPN-ServerBrückedie VPN- und LAN-Schnittstellen, anstatt zwischen ihnen zu routen. Wenn Sie ein „Bridge“-VPN einrichten, werden verbundene VPN-Clients tatsächlich Teil desselben LAN-Subnetzes wie lokale Geräte und können automatisch die mDNS-Übertragungen der anderen Geräte sehen.
(Der Nachteil besteht außerdem darin, dass sie die mDNS-Übertragungen des jeweils anderen sehen – und ARP-Übertragungen, Dropbox-Übertragungen, UPnP/SSDP-Übertragungen, NetBIOS-Übertragungen, WS-Discovery-Übertragungen und eine ganze Menge Hintergrundrauschen.)