Pi VPN med fleire rutarar: legg kvar rute på eininga som bestemmer
Ein ruter lenger nede legg til eit andre klientnett, og kvar av fire einingar eig éi avgjerd. Plasser rutene, kontroller kjelda og test deretter frå ein ekte klient.
Å setje ein Wi-Fi-boks bak Pi gjer éi rutingsavgjerd til fire, og planen bryt saman når alle fire blir tekne på éi eining. Det første spørsmålet er ikkje kva rute som skal leggjast til. Det er om den nye boksen bruar eller rutar, fordi svaret avgjer kor mange subnett som finst og kva einingar som må lære om dei. Vel tilkoplingsmodellen først; kvar rute følgjer av han.
Bru eller ruting: valet som fastset talet
Ei bru set dei nye klientane på det same subnettet som Pi allereie tener. Eitt subnett, éin DHCP-autoritet og inga overlevering å rute. Dette er den enklare ordninga og den rette når eit separat klientnett aldri var eit krav. Ei ruta lenkje er eit anna design: boksen held på sitt eige subnett, og det prefikset må berast overalt der trafikken går.
Resten av planen held på rutaren lenger nede og bevarer kjeldene til klientane. Målet er eitt privat VPN-nett, ikkje ein full internettutgang. Skriv ned modellen før adressene, fordi lista nedanfor berre er eit døme på ei ruta tilkopling.
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/24Kven bestemmer kva
| 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 |
Kvar eining tek éi avgjerd, og ingen kan ta ei anna si for henne. Pi treng to oppføringar, ikkje éi, og returvegen er den folk gløymer. Vidaresend trafikk når rett fram til det private nettet og døyr deretter på vegen tilbake, fordi Pi ikkje anar kvar 10.41.0.0/24 bur. Det ser ut som eit brannmurproblem og er eigentleg ei manglande rute.
Den fjerne sida treng også si eiga rute. Viss tenesta i den fjerne enden ikkje veit at 10.41.0.0/24 er nåbar gjennom tunnelen din, stoppar svar ved første hopp utan svar. Legg til begge retningar før du les pakkefilter.
Neste hopp kjem frå tilkoplinga
Eit neste hopp må vere ei adresse på eit nett som eininga faktisk kan nå. Den offentlege adressa til VPN-peer-en er ikkje neste hopp for eit privat subnett, og det fjerne tenestenettet er ikkje noko neste hopp i det heile. Ei rute til ein utilgjengeleg gateway ser rett ut i ei liste og slepp kvar pakke. Kontroller at gatewayen svarar før du gir målet skulda.
Hald Pi-en sin ytre VPN-peer tilgjengeleg gjennom sin eigen underliggjande rute. Den oppføringa er skild frå nyttelastrutene, og å blande dei gir ein tunnel som ikkje kan gjenopprettast etter ei vegendring.
Dokumentasjonen for statiske ruter gjer skiljet mellom mål og gateway klart, sjølv om kvar plattform namngir menyane sine ulikt. Les dokumentasjonen for eininga framfor deg i staden for å kopiere skjermen til ein annan leverandør. Kommandoane nedanfor viser forma på oppføringane 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.1Kva omsetjing gjer med kjelda
Viss rutaren lenger nede allereie omset klientane sine til transittadressa, ser Pi éi omsett kjelde i staden for kvar klients eiga adresse. Det er eit anna design enn det kjeldebevarande ovanfor. Det endrar kjeldebasert politikk, logging og kva side som kan starte tilkoplingar. Begge designa verkar; dei svarar på ulike spørsmål.
Når ei VPN-teneste oppstraums nektar å rute klientprefikset tilbake, kan ei smal omsetjing ved tunnelutgangen til Pi vere ei legitim mellombels løysing. Det er ikkje prov på at den manglande ruta var unødvendig. Noter kva adresse det fjerne nettet faktisk ser og kva returveg som følgjer.
Ruteval, vidaresendingløyve og kjeldeomsetjing blir tre separate jobbar. Å tømme ei delt NAT-kjede eller tillate kvart grensesnitt fordi éin kabelklient verkar, er måten ein verkningsfull test blir ein open vidaresendar.
Prov det frå ein klientmaskin
Send ein førespurnad frå ein maskin på det nedre LAN-et, og følg deretter kjelda ut og tilbake. Ein ping frå Pi brukar aldri den nedre returvegen, difor provar ein vellukka ping mindre enn det ser ut som. Legg til ein andre test frå ein kabelklient på Pi-en sitt eige LAN slik at dei to vegane kan samanliknast. Gjenta begge etter omstart av éi av einingane.
Ruter lagde til for hand og omsetjingar som aldri vart lagra, forsvinn saman. Då ser paret ut som ein ny feil i staden for uferdig arbeid.
Lagre tilkoplingsmodellen saman med rutene, den tillatne private tenesta og kvar omsetjing i eitt notat. Det notatet er det som hindrar den neste personen i å handsame trådlaus plassering som eit rutingsspørsmål.