Pi VPN met meerdere routers: zet elke route op het apparaat dat beslist
Een downstream-router voegt een tweede klantsubnet toe, en elk van de vier apparaten bezit één beslissing. Plaats de routes, controleer de bron en test dan vanaf een echte client.
Een Wi-Fi-doos achter de Pi zetten maakt van één routingbeslissing vier, en het plan breekt wanneer alle vier op één apparaat worden genomen. De eerste vraag is niet welke route je toevoegt. Het is of de nieuwe doos brugt of routeert, want dat antwoord bepaalt hoeveel subnetten er zijn en welke apparaten erover moeten leren. Kies eerst het aansluitmodel; elke route volgt daaruit.
Brug of routing: de keuze die het aantal bepaalt
Een brug zet de nieuwe clients op hetzelfde subnet dat de Pi al bedient. Eén subnet, één DHCP-autoriteit en geen overdracht om te routeren. Dit is de eenvoudiger opzet en de juiste wanneer een apart klantnetwerk nooit een eis was. Een gerouteerde verbinding is een ander ontwerp: de doos houdt zijn eigen subnet en dat prefix moet overal mee naartoe waar het verkeer gaat.
De rest van dit plan houdt de downstream-router en bewaart de bronadressen van clients. Het doel is één privé-VPN-netwerk, geen volledige internetuitgang. Schrijf het model op vóór de adressen, want de lijst hieronder is alleen een voorbeeld van een gerouteerde aansluiting.
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/24Wie beslist wat
| 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 |
Elk apparaat neemt één beslissing, en geen kan die van een ander ervoor nemen. De Pi heeft twee vermeldingen nodig, niet één, en de terugweg is degene die mensen vergeten. Doorgestuurd verkeer bereikt het privénetwerk correct en sterft dan op de terugweg, omdat de Pi geen idee heeft waar 10.41.0.0/24 woont. Dat lijkt een firewallprobleem en is in werkelijkheid een ontbrekende route.
De verre kant heeft ook zijn eigen route nodig. Als de dienst aan de andere kant niet weet dat 10.41.0.0/24 via jouw tunnel bereikbaar is, stoppen antwoorden bij de eerste hop zonder antwoord. Voeg beide richtingen toe voordat je packetfilters leest.
Volgende hops komen uit de aansluiting
Een volgende hop moet een adres zijn op een netwerk dat het apparaat echt kan bereiken. Het openbare adres van de VPN-peer is niet de volgende hop voor een privésubnet, en het verre dienstnetwerk is helemaal geen volgende hop. Een route naar een onbereikbare gateway ziet er in een lijst correct uit en laat elk pakket vallen. Controleer of de gateway antwoordt voordat je het doel de schuld geeft.
Houd de buitenste VPN-peer van de Pi bereikbaar via zijn eigen onderlaagroute. Die vermelding staat los van de payload-routes, en ze mengen levert een tunnel die na een padwijziging niet opnieuw kan worden opgebouwd.
De documentatie over statische routes maakt het onderscheid tussen bestemming en gateway duidelijk, ook al noemt elk platform zijn menu's anders. Lees de documentatie voor het apparaat voor je in plaats van het scherm van een andere leverancier te kopiëren. De opdrachten hieronder tonen de vorm van de vermeldingen op 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.1Wat vertaling met de bron doet
Als de downstream-router zijn clients al naar het transitadres vertaalt, ziet de Pi één vertaalde bron in plaats van het eigen adres van elke client. Dat is een ander ontwerp dan het bronbehoudende hierboven. Het verandert beleid op basis van de bron, logboekregistratie en welke kant verbindingen kan starten. Beide ontwerpen werken; ze beantwoorden verschillende vragen.
Wanneer een upstream-VPN-dienst weigert het clientprefix terug te routeren, kan een smalle vertaling bij de tunneluitgang van de Pi een legitieme tijdelijke oplossing zijn. Het is geen bewijs dat de ontbrekende route overbodig was. Noteer welk adres het verre netwerk werkelijk ziet en welke terugweg daaruit volgt.
Routekeuze, doorstuurrecht en bronvertaling blijven drie aparte taken. Een gedeelde NAT-keten leegmaken of elke interface toestaan omdat één bekabelde client werkt, is hoe een werkende test een open doorstuurder wordt.
Het bewijzen vanaf een clientmachine
Stuur een verzoek vanaf een machine op het downstream-LAN en volg daarna de bron naar buiten en terug. Een ping van de Pi oefent nooit de downstream-terugweg, daarom bewijst een geslaagde ping minder dan het lijkt. Voeg een tweede test toe vanaf een bekabelde client op het eigen LAN van de Pi zodat de twee paden vergeleken kunnen worden. Herhaal beide na het herstarten van een van de apparaten.
Routes die met de hand zijn toegevoegd en vertalingen die nooit zijn opgeslagen, verdwijnen samen. Het paar lijkt dan op een nieuwe fout in plaats van onvoltooid werk.
Sla het aansluitmodel op samen met de routes, de toegestane privédienst en elke vertaling in één notitie. Die notitie is wat de volgende persoon ervan weerhoudt de draadloze plaatsing als een routingbeleidsvraag te behandelen.