Veelroeteerder-Pi-VPN: plaas elke roete op die toestel wat besluit

Om ’n Wi-Fi-boks agter die Pi te plaas, maak een roetebesluit vier, en die plan breek wanneer al vier op een toestel geneem word. Die eerste vraag is nie watter roete om by te voeg nie. Dit is of die nuwe boks brug of roeteer, want daardie antwoord bepaal hoeveel subnetwerke bestaan en watter toestelle daarvan moet leer. Kies eers die aanhegtingsmodel; elke roete volg daaruit.

Brug of roeteer: die keuse wat die aantal bepaal

’n Brug plaas die nuwe kliënte op dieselfde subnet wat die Pi reeds bedien. Een subnet, een DHCP-owerheid, en geen oordrag om te roeteer nie. Dit is die eenvoudiger reëling en die regte een wanneer ’n aparte kliëntnetwerk nooit ’n vereiste was nie. ’n Geroeteerde skakel is ’n ander ontwerp: die boks behou sy eie subnet, en daardie voorvoegsel moet oral gedra word waar die verkeer gaan.

Die res van hierdie plan behou die stroomaf-roeteerder en bewaar kliëntbronadresse. Die doel is een private VPN-netwerk, nie ’n volle internetuitgang nie. Skryf die model neer voor die adresse, want die lys hieronder is slegs ’n voorbeeld van ’n geroeteerde aanhegting.

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/24

Wie besluit wat

Elke toestel neem een besluit, en niemand kan ’n ander se besluit vir hom neem nie. Die Pi benodig twee inskrywings, nie een nie, en die terugpad is die een wat mense vergeet. Deurgevoerde verkeer bereik die private netwerk korrek en sterf dan op die pad terug, want die Pi het geen idee waar 10.41.0.0/24 woon nie. Dit lyk soos ’n brandmuurprobleem en is eintlik ’n ontbrekende roete.

Die verre kant het ook sy eie roete nodig. As die diens aan die ander kant nie weet dat 10.41.0.0/24 deur jou tonnel bereikbaar is nie, stop antwoorde by die eerste hop wat geen antwoord het nie. Voeg beide rigtings by voordat jy pakketfilters lees.

Volgende spronge kom uit die aanhegting

’n Volgende sprong moet ’n adres op ’n netwerk wees wat die toestel werklik kan bereik. Die VPN-eweknie se openbare adres is nie die volgende sprong vir ’n private subnet nie, en die verre diensnetwerk is glad nie ’n volgende sprong nie. ’n Roete na ’n onbereikbare poort lyk korrek in ’n lys en laat elke pakket val. Kontroleer dat die poort antwoord voordat jy die bestemming blameer.

Hou die Pi se buitenste VPN-eweknie bereikbaar deur sy eie onderlaagroete. Daardie inskrywing is apart van die vragroetes, en om hulle te meng gee ’n tonnel wat nie na ’n padverandering kan herstel nie.

Die dokumentasie oor statiese roetes maak die onderskeid tussen bestemming en poort duidelik, al etiketteer elke platform sy menus anders. Lees die dokumentasie vir die toestel voor jou eerder as om ’n ander verskaffer se skerm na te maak. Die opdragte hieronder wys die vorm van die inskrywings 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.1

Wat vertaling aan die bron doen

As die stroomaf-roeteerder sy kliënte reeds na die deurgangsadres vertaal, sien die Pi een vertaalde bron in plaas van elke kliënt se eie adres. Dit is ’n ander ontwerp as die bronbewarende een hierbo. Dit verander brongebaseerde beleid, logboekvoering, en watter kant verbindings kan begin. Albei ontwerpe werk; hulle beantwoord verskillende vrae.

Wanneer ’n opstroom-VPN-diens weier om die kliëntvoorvoegsel terug te roeteer, kan ’n nou vertaling by die Pi se tonneluitgang ’n wettige noodoplossing wees. Dit is nie bewys dat die ontbrekende roete onnodig was nie. Teken aan watter adres die verre netwerk werklik sien en watter terugpad daaruit volg.

Roeteseleksie, deurvoringspermissie en bronvertaling bly drie aparte take. Om ’n gedeelde NAT-ketting te spoel of elke koppelvlak toe te laat omdat een bedrade kliënt werk, is hoe ’n werkende toets ’n oop deurvoerder word.

Bewys dit vanaf ’n kliëntmasjien

Stuur ’n versoek vanaf ’n masjien op die stroomaf-LAN, en volg dan sy bron uit en terug. ’n Ping wat deur die Pi gestuur word, oefen nooit die stroomaf-terugroete nie, en daarom bewys ’n suksesvolle een minder as wat dit lyk. Voeg ’n tweede toets by vanaf ’n bedrade kliënt op die Pi se eie LAN sodat die twee roetes vergelyk kan word. Herhaal albei nadat jy enige toestel herbegin het.

Roetes wat met die hand bygevoeg is en vertalings wat nooit bewaar is nie, verdwyn saam. Die paar lyk dan soos ’n nuwe fout eerder as ’n onvoltooide een.

Bewaar die aanhegtingsmodel saam met die roetes, die toegelate private diens en enige vertaling in een nota. Daardie nota is wat die volgende persoon keer om draadlose plasing as ’n roetebeleidsvraag te behandel.