Pi VPN med flere rutere: legg hver rute på enheten som bestemmer
En ruter lenger ned legger til et andre klientnett, og hver av fire enheter eier én beslutning. Plasser rutene, kontroller kilden, og test deretter fra en ekte klient.
Å sette en Wi-Fi-boks bak Pi gjør én rutingsbeslutning til fire, og planen bryter sammen når alle fire tas på én enhet. Det første spørsmålet er ikke hvilken rute som skal legges til. Det er om den nye boksen broer eller ruter, fordi svaret avgjør hvor mange subnett som finnes og hvilke enheter som må lære om dem. Velg tilkoblingsmodellen først; hver rute følger av den.
Bro eller ruting: valget som fastsetter antallet
En bro setter de nye klientene på det samme subnettet som Pi allerede betjener. Ett subnett, én DHCP-autoritet og ingen overlevering å rute. Dette er den enklere ordningen og den riktige når et separat klientnett aldri var et krav. En rutet lenke er et annet design: boksen beholder sitt eget subnett, og det prefikset må bæres overalt hvor trafikken går.
Resten av planen beholder ruteren lenger ned og bevarer klientenes kildeadresser. Målet er ett privat VPN-nett, ikke en full internettutgang. Skriv ned modellen før adressene, fordi listen nedenfor bare er et eksempel på en rutet tilkobling.
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/24Hvem bestemmer hva
| 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 |
Hver enhet tar én beslutning, og ingen kan ta en annens for den. Pi trenger to oppføringer, ikke én, og returveien er den folk glemmer. Videresendt trafikk når riktig frem til det private nettet og dør deretter på veien tilbake, fordi Pi ikke aner hvor 10.41.0.0/24 bor. Det ser ut som et brannmurproblem og er egentlig en manglende rute.
Den fjerne siden trenger også sin egen rute. Hvis tjenesten i den fjerne enden ikke vet at 10.41.0.0/24 er nåbar gjennom tunnelen din, stopper svar ved første hopp uten svar. Legg til begge retninger før du leser pakkefiltre.
Neste hopp kommer fra tilkoblingen
Et neste hopp må være en adresse på et nett som enheten faktisk kan nå. VPN-peerens offentlige adresse er ikke neste hopp for et privat subnett, og det fjerne tjenestenettet er ikke noe neste hopp i det hele tatt. En rute til en utilgjengelig gateway ser riktig ut i en liste og slipper hver pakke. Kontroller at gatewayen svarer før du skylder på målet.
Hold Pi-ens ytre VPN-peer tilgjengelig gjennom sin egen underliggende rute. Den oppføringen er atskilt fra nyttelastrutene, og å blande dem gir en tunnel som ikke kan gjenopprettes etter en veiendring.
Dokumentasjonen for statiske ruter gjør skillet mellom mål og gateway klart, selv om hver plattform navngir menyene sine ulikt. Les dokumentasjonen for enheten foran deg i stedet for å kopiere skjermen til en annen leverandør. Kommandoene nedenfor viser formen på oppføringene 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.1Hva oversettelse gjør med kilden
Hvis ruteren lenger ned allerede oversetter klientene sine til transitadressen, ser Pi én oversatt kilde i stedet for hver klients egen adresse. Det er et annet design enn det kildebevarende ovenfor. Det endrer kildebasert policy, logging og hvilken side som kan starte tilkoblinger. Begge designene virker; de svarer på forskjellige spørsmål.
Når en VPN-tjeneste oppstrøms nekter å rute klientprefikset tilbake, kan en smal oversettelse ved Pi-ens tunnelutgang være en legitim midlertidig løsning. Det er ikke bevis for at den manglende ruten var unødvendig. Noter hvilken adresse det fjerne nettet faktisk ser og hvilken returvei som følger.
Rutevalg, videresendingstillatelse og kildeoversettelse forblir tre separate jobber. Å tømme en delt NAT-kjede eller tillate hvert grensesnitt fordi én kablet klient virker, er måten en fungerende test blir en åpen videresender.
Bevis det fra en klientmaskin
Send en forespørsel fra en maskin på det nedre LAN-et, og følg deretter kilden ut og tilbake. En ping fra Pi bruker aldri den nedre returveien, derfor beviser en vellykket ping mindre enn det ser ut som. Legg til en andre test fra en kablet klient på Pi-ens eget LAN slik at de to veiene kan sammenlignes. Gjenta begge etter omstart av en av enhetene.
Ruter lagt til for hånd og oversettelser som aldri ble lagret, forsvinner sammen. Da ser paret ut som en ny feil i stedet for uferdig arbeid.
Lagre tilkoblingsmodellen sammen med rutene, den tillatte private tjenesten og enhver oversettelse i ett notat. Det notatet er det som hindrer den neste personen i å behandle trådløs plassering som et rutingspørsmål.