LAN-roeteerder plus VPN-kliënt: twee toestelle, twee roetetabelle

Twee toestelle stuur die pakket aan en elkeen hou sy eie tabel. Die LAN-roeteerder weet dat die afgeleë voorvoegsel aan die VPN-kliënt behoort, en die VPN-kliënt weet hoe om daardie voorvoegsel deur sy tonnel te bereik. Konfigureer net die eerste tabel, en die pakket kom by 'n masjien aan wat geen ooreenstemmende roete het nie, so dit vertrek weer via die verstekroete. Dit is die hele fout, en dit lyk soos 'n roeteringslus van die LAN-kant af, want dit is byna een.

Teken die twee spronge voordat jy aan 'n roete raak

Neem 'n illustratiewe uitleg: LAN-gashere op 192.168.50.0/24, die gewone roeteerder by 192.168.50.1, 'n toegewyde kliënt by 192.168.50.15, en 'n afgeleë LAN by 10.60.0.0/24 wat net deur die tonnel bereikbaar is wat daardie kliënt het. Nie een van die private reekse oorvleuel die ander nie, en die tonnel het sy eie adresplan.

Beide private reekse maak saak, want hulle bepaal watter toestel kan antwoord. Die afgeleë kant sal sien dat die pakket van die kliënt se tonneladres kom, en sy antwoord moet 'n pad terug na 192.168.50.0/24 vind. As net die uitgaande rigting gekonfigureer is, kan die versoek werk terwyl die antwoord verdwyn.

Stap 1: wys die roeteerder na die kliënt, nie na die tonnel nie

Voeg op die LAN-roeteerder 'n bestemmingsroete by waarvan die volgende sprong die kliënt se LAN-adres is:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Daardie inskrywing sê “lewer dit aan die masjien wat kan tonnel”. Dit sê niks oor hoe die tonnel gebou word nie, en dit is nie 'n plaasvervanger vir die kliënt se eie roete nie. Op 'n bestuurde roeteerder woon die ekwivalent in die toestel se bladsy vir statiese roetes; op 'n Linux-roeteerder hoort dit in die koppelvlakkonfigurasie wat die LAN besit, nie in 'n skulp wat jy gaan sluit nie.

Kyk na die antwoord van die tweede opdrag. As dit die kliënt as gateway en die LAN-koppelvlak as device rapporteer, is die eerste sprong korrek en is die res van die werk op die ander masjien.

Stap 2: gee die kliënt 'n eie roete aan die tonnelkant

Die kliënt ontvang nou 'n pakket vir 10.60.0.0/24 en raadpleeg sy eie tabel. As sy tonnelkonfigurasie 'n roete vir daardie voorvoegsel geïnstalleer het, gaan die pakket geënkripteer voort. As dit nie het nie, pas die pakket by die gewone verstek en gaan terug na 192.168.50.1, wat dit weer na die kliënt stuur.

Kyk eers voordat jy iets byvoeg:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

'n Ontbrekende voorvoegselroete in elke tabel is die bevinding waarna jy soek. Voeg dit deur die tonnel se eie konfigurasie by, sodat die volgende herverbinding dit weer installeer; 'n handmatige ip route add verdwyn saam met die sessie en laat die fout op die ongerieflikste oomblik terugkeer. Die volgende sprong is die tonnelkoppelvlak of die adres wat die VPN as sy eweknie toeken, afhangende van die kliënt, en die eweknie-adres moet uit die huidige profiel kom eerder as uit 'n ou notisie.

Die lus, wanneer dit gebeur, is in die praktyk nie oneindig nie: die TTL daal by elke passage en die pakket sterf met 'n boodskap oor tyd wat oorskry is. Daarom kan 'n herhalende traceroute 'n siklus suggereer, terwyl 'n kliënt wat bloot nie aanstuur nie dieselfde pakket stilweg laat val.

Stap 3: laat aanstuur toe en kies die terugpad

Ontvang en aanstuur is verskillende regte. net.ipv4.ip_forward=1 op die kliënt laat deurvoer op kernevlak toe, en 'n firewall-reël moet dit steeds tussen die LAN-koppelvlak en die tonnel toelaat. 'n Reël wat toegang tot die kliënt se eie bestuursbladsy toelaat, sal nie deurvoer na die afgeleë LAN toelaat nie, en die onderskeid is maklik om mis te kyk wanneer dieselfde gasheer plaaslik op pings antwoord.

Die afgeleë kant het die spieëlprobleem. Dit moet weet dat 192.168.50.0/24 deur hierdie geoutentiseerde kliënt bereikbaar is. Met OpenVPN bedoel dit gewoonlik 'n roete per kliënt wat deur die bedienerkonfigurasie gestoot word, of 'n kliënspesifieke lêer op die bediener wat die LAN agter die kliënt verklaar. Sonder dit laat die afgeleë LAN die antwoord óf val óf stuur dit na sy eie verstekgateway, wat die internet is.

Bronvertaling is die alternatief wanneer die LAN-voorvoegsel nie geadverteer kan word nie. 'n Beperkte masquerade-reël op die kliënt herskryf die bron na die tonneladres, en antwoorde keer dan natuurlik terug. Dit verberg ook watter LAN-gasheer die versoek gemaak het, en dit laat die afgeleë kant nie op sigself inwaartse verbindings begin nie. Kies daardie afweging doelbewus eerder as om 'n oorkoepelende masquerade by te voeg en die newe-effek later te ontdek.

Stap 4: maak beide besluite blywend en toets dan die werklike pad

Elke roete het 'n eienaar, en die eienaar is die konfigurasie wat by die opstart of by herverbinding weer geskep word. Op die roeteerder kan dit 'n statiese roete-inskrywing wees; op die kliënt kan dit die VPN-profiel, NetworkManager of systemd-networkd wees. Verifieer deur die tonnel te herverbind en die kliënt te herbegin, en lees dan die tabel weer eerder as om die wysiging te vertrou.

Hou die verstekroete wat die tonnel se buitenste verbinding dra, ongeskonde. Om dit te vervang om die opstelling te “vereenvoudig”, breek die geënkripteerde pad voordat enige binneste verkeer dit kan gebruik, en die simptoom is 'n tonnel wat ná die verandering nooit weer vestig nie.

Toets vanaf 'n gewone LAN-gasheer, nie vanaf die kliënt nie, want 'n versoek wat op die kliënt ontstaan, oefen nooit die roeteerder se eerste sprong uit nie. Haal 'n diens wat net op die afgeleë LAN bestaan en bevestig die antwoordliggaam, kyk dan na die kliënt se tellers of logboeke om die deurvoer te sien gebeur. 'n Binneste traceroute wat private spronge wys, bewys aanstuur, nie enkripsie nie: die buitenste pad is 'n aparte waarneming, en net die tonnel se eie koppelvlak-tellers wys wat daardeur vertrek het.