Pi-VPN mit mehreren Routern: jede Route auf das Gerät, das entscheidet
Ein nachgelagerter Router fügt ein zweites Client-Subnetz hinzu, und vier Geräte besitzen jeweils eine Entscheidung. Setzen Sie die Routen, prüfen Sie die Quelle und testen Sie dann von einem echten Client.
Eine Wi-Fi-Box hinter dem Pi macht aus einer Routingentscheidung vier, und der Plan bricht, wenn alle vier auf einem Gerät getroffen werden. Die erste Frage ist nicht, welche Route hinzugefügt werden soll. Sie lautet, ob die neue Box bridgt oder routet, denn diese Antwort entscheidet, wie viele Subnetze existieren und welche Geräte davon erfahren müssen. Wählen Sie zuerst das Anbindungsmodell; jede Route folgt daraus.
Bridge oder Routing: die Wahl, die die Anzahl festlegt
Eine Bridge setzt die neuen Clients in dasselbe Subnetz, das der Pi bereits bedient. Ein Subnetz, eine DHCP-Autorität und keine Übergabe zum Routing. Das ist die einfachere Anordnung und die richtige, wenn ein separates Clientnetz nie eine Anforderung war. Eine geroutete Verbindung ist ein anderes Design: Die Box behält ihr eigenes Subnetz, und dieses Präfix muss überallhin mitgeführt werden, wohin der Verkehr geht.
Der Rest dieses Plans behält den nachgelagerten Router und bewahrt die Client-Quelladressen. Das Ziel ist ein privates VPN-Netz, kein vollständiger Internetausgang. Schreiben Sie das Modell vor den Adressen auf, denn die Liste unten ist nur ein Beispiel einer gerouteten Anbindung.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24Wer was entscheidet
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Jedes Gerät trifft eine Entscheidung, und keines kann die eines anderen für es treffen. Der Pi braucht zwei Einträge, nicht einen, und der Rückweg ist der, den Leute vergessen. Weitergeleiteter Verkehr erreicht das private Netz korrekt und stirbt dann auf dem Rückweg, weil der Pi keine Ahnung hat, wo 10.41.0.0/24 lebt. Das sieht nach einem Firewallproblem aus und ist in Wahrheit eine fehlende Route.
Auch die Gegenseite braucht ihre eigene Route. Wenn der Dienst am fernen Ende nicht weiß, dass 10.41.0.0/24 über Ihren Tunnel erreichbar ist, bleiben Antworten am ersten Hop ohne Antwort stehen. Fügen Sie beide Richtungen hinzu, bevor Sie Paketfilter lesen.
Nächste Hops kommen aus der Anbindung
Ein nächster Hop muss eine Adresse in einem Netz sein, das das Gerät tatsächlich erreichen kann. Die öffentliche Adresse des VPN-Peers ist nicht der nächste Hop für ein privates Subnetz, und das entfernte Dienstnetz ist überhaupt kein nächster Hop. Eine Route zu einem unerreichbaren Gateway sieht in einer Liste korrekt aus und verwirft jedes Paket. Prüfen Sie, ob das Gateway antwortet, bevor Sie das Ziel beschuldigen.
Halten Sie den äußeren VPN-Peer des Pi über seine eigene Underlay-Route erreichbar. Dieser Eintrag ist getrennt von den Nutzlast-Routen, und ihre Vermischung ergibt einen Tunnel, der sich nach einer Pfadänderung nicht neu aufbauen kann.
Die Dokumentation zu statischen Routen macht den Unterschied zwischen Ziel und Gateway klar, obwohl jede Plattform ihre Menüs anders benennt. Lesen Sie die Dokumentation für das Gerät vor sich, statt den Bildschirm eines anderen Herstellers zu kopieren. Die Befehle unten zeigen die Form der Einträge unter Linux.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1Was Übersetzung mit der Quelle macht
Wenn der nachgelagerte Router seine Clients bereits auf die Transitadresse übersetzt, sieht der Pi eine übersetzte Quelle statt der eigenen Adresse jedes Clients. Das ist ein anderes Design als das quellenbewahrende oben. Es ändert quellenbasierte Richtlinien, Protokollierung und welche Seite Verbindungen aufbauen kann. Beide Designs funktionieren; sie beantworten verschiedene Fragen.
Wenn ein vorgelagerter VPN-Dienst sich weigert, das Client-Präfix zurückzurouten, kann eine enge Übersetzung am Tunnelausgang des Pi eine legitime Übergangslösung sein. Das ist kein Beweis, dass die fehlende Route unnötig war. Notieren Sie, welche Adresse das entfernte Netz tatsächlich sieht und welcher Rückweg daraus folgt.
Routenauswahl, Weiterleitungserlaubnis und Quellenübersetzung bleiben drei getrennte Aufgaben. Eine gemeinsame NAT-Kette zu leeren oder jede Schnittstelle zu erlauben, weil ein kabelgebundener Client funktioniert, ist der Weg, auf dem ein funktionierender Test zu einem offenen Weiterleiter wird.
Es von einer Client-Maschine beweisen
Senden Sie eine Anfrage von einer Maschine im nachgelagerten LAN und verfolgen Sie ihre Quelle hinaus und zurück. Ein Ping vom Pi übt nie den nachgelagerten Rückweg aus, deshalb beweist ein erfolgreicher weniger, als er aussieht. Fügen Sie einen zweiten Test von einem kabelgebundenen Client im eigenen LAN des Pi hinzu, damit die beiden Wege verglichen werden können. Wiederholen Sie beide nach einem Neustart eines der Geräte.
Von Hand hinzugefügte Routen und Übersetzungen, die nie gespeichert wurden, verschwinden zusammen. Dann sieht das Paar wie ein neuer Fehler aus statt wie unfertige Arbeit.
Speichern Sie das Anbindungsmodell zusammen mit den Routen, dem erlaubten privaten Dienst und jeder Übersetzung in einer Notiz. Diese Notiz ist es, die den Nächsten davon abhält, die Funkplatzierung als routingpolitische Frage zu behandeln.