Pi VPN med flera routrar: lägg varje rutt på enheten som bestämmer
En router längre ned lägger till ett andra klientnät, och var och en av fyra enheter äger ett beslut. Placera rutterna, kontrollera källan och testa sedan från en riktig klient.
Att sätta en Wi-Fi-box bakom Pi gör ett routingbeslut till fyra, och planen bryts när alla fyra tas på en enda enhet. Den första frågan är inte vilken rutt som ska läggas till. Det är om den nya boxen bryggar eller routar, eftersom svaret avgör hur många subnät som finns och vilka enheter som måste lära sig om dem. Välj anslutningsmodell först; varje rutt följer av den.
Brygga eller routning: valet som bestämmer antalet
En brygga sätter de nya klienterna på samma subnät som Pi redan betjänar. Ett subnät, en DHCP-auktoritet och ingen överlämning att routa. Detta är den enklare ordningen och den rätta när ett separat klientnät aldrig var ett krav. En routad länk är en annan design: boxen behåller sitt eget subnät, och det prefixet måste bäras överallt dit trafiken går.
Resten av planen behåller routern längre ned och bevarar klienternas källadresser. Målet är ett privat VPN-nät, inte en full internetutgång. Skriv ned modellen före adresserna, eftersom listan nedan bara är ett exempel på en routad anslutning.
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/24Vem bestämmer vad
| 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 |
Varje enhet fattar ett beslut, och ingen kan fatta en annans åt den. Pi behöver två poster, inte en, och returvägen är den folk glömmer. Vidarebefordrad trafik når det privata nätet korrekt och dör sedan på vägen tillbaka, eftersom Pi inte har en aning om var 10.41.0.0/24 bor. Det ser ut som ett brandväggsproblem och är egentligen en saknad rutt.
Den avlägsna sidan behöver också sin egen rutt. Om tjänsten i den bortre änden inte vet att 10.41.0.0/24 går att nå via din tunnel, stannar svaren vid första hoppet utan svar. Lägg till båda riktningarna innan du läser paketfilter.
Nästa hopp kommer från anslutningen
Ett nästa hopp måste vara en adress på ett nät som enheten faktiskt kan nå. VPN-peerens publika adress är inte nästa hopp för ett privat subnät, och det avlägsna tjänstenätet är inte något nästa hopp alls. En rutt till en onåbar gateway ser korrekt ut i en lista och tappar varje paket. Kontrollera att gatewayen svarar innan du skyller på målet.
Håll Pi:s yttre VPN-peer nåbar via sin egen underliggande rutt. Den posten är skild från nyttolastrutterna, och att blanda dem ger en tunnel som inte kan återupprättas efter en vägändring.
Dokumentationen för statiska rutter gör skillnaden mellan mål och gateway tydlig, även om varje plattform namnger sina menyer olika. Läs dokumentationen för enheten framför dig i stället för att kopiera en annan leverantörs skärm. Kommandona nedan visar hur posterna ser ut i 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.1Vad översättning gör med källan
Om routern längre ned redan översätter sina klienter till transitadressen ser Pi en enda översatt källa i stället för varje klients egen adress. Det är en annan design än den källbevarande ovan. Det ändrar källbaserad policy, loggning och vilken sida som kan initiera anslutningar. Båda designerna fungerar; de svarar på olika frågor.
När en VPN-tjänst uppströms vägrar att routa klientprefixet tillbaka kan en snäv översättning vid Pi:s tunnelutgång vara en legitim tillfällig lösning. Det är inte bevis för att den saknade rutten var onödig. Notera vilken adress det avlägsna nätet faktiskt ser och vilken returväg som följer.
Ruttval, vidarebefordringstillstånd och källöversättning förblir tre separata jobb. Att tömma en delad NAT-kedja eller tillåta varje gränssnitt eftersom en kabelansluten klient fungerar är hur ett fungerande test blir en öppen vidarebefordrare.
Bevisa det från en klientmaskin
Skicka en förfrågan från en maskin på det nedre LAN:et och följ sedan dess källa ut och tillbaka. En ping från Pi använder aldrig den nedre returvägen, därför bevisar en lyckad ping mindre än det ser ut som. Lägg till ett andra test från en kabelansluten klient på Pi:s eget LAN så att de två vägarna kan jämföras. Upprepa båda efter omstart av någon av enheterna.
Rutter som lagts till för hand och översättningar som aldrig sparades försvinner tillsammans. Paret ser då ut som ett nytt fel i stället för oavslutat arbete.
Spara anslutningsmodellen tillsammans med rutterna, den tillåtna privata tjänsten och varje översättning i en enda anteckning. Den anteckningen är det som hindrar nästa person från att behandla trådlös placering som en routingpolitisk fråga.