Pi VPN med flere routere: læg hver rute på den enhed, der beslutter
En router længere nede tilføjer et andet klientundernet, og hver af fire enheder ejer én beslutning. Placer ruterne, kontrollér kilden, og test derefter fra en rigtig klient.
At sætte en Wi-Fi-boks bag Pi'en gør én routingbeslutning til fire, og planen bryder sammen, når alle fire træffes på én enhed. Det første spørgsmål er ikke, hvilken rute der skal tilføjes. Det er, om den nye boks brobygger eller router, for det svar afgør, hvor mange undernet der findes, og hvilke enheder der skal lære om dem. Vælg tilslutningsmodellen først; hver rute følger af den.
Bro eller routing: det valg, der fastsætter antallet
En bro sætter de nye klienter på det samme undernet, som Pi'en allerede betjener. Ét undernet, én DHCP-autoritet og ingen overdragelse at route. Det er den enklere ordning og den rigtige, når et separat klientnetværk aldrig var et krav. Et routet link er et anderledes design: boksen beholder sit eget undernet, og det præfiks skal bæres overalt, hvor trafikken går.
Resten af planen beholder routeren længere nede og bevarer klienternes kildeadresser. Målet er ét privat VPN-netværk, ikke en fuld internetudgang. Skriv modellen ned før adresserne, for listen nedenfor er kun et eksempel på en routet tilslutning.
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 beslutter hvad
| 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 enhed træffer én beslutning, og ingen kan træffe en andens for den. Pi'en har brug for to poster, ikke én, og returvejen er den, folk glemmer. Videresendt trafik når korrekt frem til det private netværk og dør derefter på vejen tilbage, fordi Pi'en ikke aner, hvor 10.41.0.0/24 bor. Det ligner et firewallproblem og er i virkeligheden en manglende rute.
Den fjerne side har også brug for sin egen rute. Hvis tjenesten i den fjerne ende ikke ved, at 10.41.0.0/24 kan nås gennem din tunnel, stopper svarene ved det første hop uden svar. Tilføj begge retninger, før du læser pakkefiltre.
Næste hop kommer fra tilslutningen
Et næste hop skal være en adresse på et netværk, som enheden faktisk kan nå. VPN-peerens offentlige adresse er ikke næste hop for et privat undernet, og det fjerne tjenestenetværk er slet ikke et næste hop. En rute til en utilgængelig gateway ser korrekt ud på en liste og dropper hver pakke. Kontrollér, at gatewayen svarer, før du bebrejder destinationen.
Hold Pi'ens ydre VPN-peer tilgængelig gennem dens egen underliggende rute. Den post er adskilt fra payload-ruterne, og blander man dem, får man en tunnel, der ikke kan genoprettes efter en vejændring.
Dokumentationen for statiske ruter gør forskellen mellem destination og gateway klar, selv om hver platform navngiver sine menuer forskelligt. Læs dokumentationen for den enhed, du har foran dig, i stedet for at kopiere en anden leverandørs skærm. Kommandoerne nedenfor viser formen på posterne 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.1Hvad oversættelse gør ved kilden
Hvis routeren længere nede allerede oversætter sine klienter til transitadressen, ser Pi'en én oversat kilde i stedet for hver klients egen adresse. Det er et andet design end det kildebevarende ovenfor. Det ændrer kildebaseret politik, logning og hvilken side der kan starte forbindelser. Begge design virker; de besvarer forskellige spørgsmål.
Når en VPN-tjeneste opstrøms nægter at route klientpræfikset tilbage, kan en snæver oversættelse ved Pi'ens tunneludgang være en legitim midlertidig løsning. Det er ikke bevis for, at den manglende rute var unødvendig. Notér, hvilken adresse det fjerne netværk faktisk ser, og hvilken returvej det giver.
Rutevalg, videresendelsestilladelse og kildeoversættelse forbliver tre separate opgaver. At skylle en delt NAT-kæde eller tillade hver grænseflade, fordi én kablet klient virker, er måden, hvorpå en fungerende test bliver en åben videresender.
Bevis det fra en klientmaskine
Send en anmodning fra en maskine på det nederste LAN, og følg derefter dens kilde ud og tilbage. Et ping fra Pi'en bruger aldrig den nedre returvej, og derfor beviser et vellykket ping mindre, end det ser ud til. Tilføj en anden test fra en kablet klient på Pi'ens eget LAN, så de to veje kan sammenlignes. Gentag begge efter genstart af en af enhederne.
Ruter tilføjet i hånden og oversættelser, der aldrig blev gemt, forsvinder sammen. Parret ser så ud som en ny fejl i stedet for et uafsluttet arbejde.
Gem tilslutningsmodellen sammen med ruterne, den tilladte private tjeneste og enhver oversættelse i ét notat. Det notat er det, der forhindrer den næste person i at behandle trådløs placering som et routingpolitisk spørgsmål.