Volgende sprong in VPN-roetes: waarom die poort plaaslik bereikbaar moet wees

’n Roete na ’n VPN-netwerk dra twee adresse wat maklik verwar word: die bestemmingsvoorvoegsel wat die pakkie probeer bereik en die volgende sprong wat dit een stap nader skuif. Op ’n LAN-gasheer moet daardie volgende sprong ’n router wees wat jy werklik op dieselfde skakel kan bereik. Die afgeleë VPN-adres is nie ’n volgende sprong nie, hoe netjies dit ook al by die bestemming in jou kop pas.

Hierdie handleiding dek die gewone geval: ’n skootrekenaar op 192.168.20.0/24, ’n VPN-poort met ’n LAN-adres van 192.168.20.5, en ’n afgeleë netwerk 10.70.0.0/24 agter daardie poort. Elke opdrag hieronder aanvaar dat jy op die skootrekenaar is, tensy dit anders sê.

Twee adresse, een roete

Die bedoelde inskrywing is 10.70.0.0/24 via 192.168.20.5. Die voorvoegsel sê waarheen die pakkie gaan; die via-adres sê wie dit daarheen dra. Die kernel weier om ’n roete te installeer waarvan hy die poort nie deur die koppelvlak wat jy noem kan bereik nie, en daardie weiering is juis die punt: ’n volgende sprong wat die tonnel nodig het om bereikbaar te wees, kan nie die volgende sprong wees wat die tonnel bou nie.

Die eerste kontrole is dus nie “is die poort aan” nie, maar “is die poort op hierdie skakel”. Die skootrekenaar se eie subnet, sy ARP- of buurinskrywing en die koppelvlak in die roete moet almal ooreenstem. ’n Adres wat net binne 10.70.0.0/24 bestaan, kan die bestemming van ’n tweede roete wees, nooit die via van die eerste nie.

Waartoe die volgende sprong die poort verplig

Om die roete op die skootrekenaar te installeer, bepaal net die eerste oorhandiging. Die poort het daarna sy eie pad nodig: aanstuur geaktiveer, ’n tonnelroete vir 10.70.0.0/24, en enige toegangsbeleid wat bepaal wie dit mag gebruik. Op Linux is dit net.ipv4.ip_forward=1 plus ’n tonnelroete; ’n vuurmuur daarvoor het ’n reël nodig wat die aangestuurde vloei toelaat.

Die terugrigting is die deel wat mense vergeet. Die afgeleë kant moet ’n roete terug na 192.168.20.0/24 hê, of die ontwerp moet die skootrekenaar se bron vertaal in iets wat die afgeleë kant ken. ’n Werkende ping vanaf die poort bewys die poort kan die afgeleë netwerk bereik; dit sê niks oor of die skootrekenaar se pakkies die terugreis oorleef nie.

Kontroleer die opsoek vanaf die gasheer wat stuur

Vra die kernel watter volgende sprong hy sou kies, en lees die koppelvlak in die antwoord:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

As die opsoek die poort en die LAN-koppelvlak rapporteer, is die eerste been soos bedoel opgestel. As dit die tonneltoestel rapporteer, is iets vroeër in die tabel meer spesifiek en wen dit. As die roete glad nie installeer nie, sê die kernel vir jou die poort is onbereikbaar, en daardie boodskap is nuttiger as enige pakkie-opname.

Herhaal dan die toets vanaf die regte plek. ’n Versoek wat op die poort geskep word, gebruik die poort se eie bronadres, wat ’n ontbrekende terugroete of ’n beleid wat net sekere bronne toelaat, kan verberg. Die ip-route-handleiding skei bestemming, poort en die onlink-oorheersing, en die oorheersing is die moeite werd om te verstaan voordat jy dit gebruik.

Moenie onlink gebruik om bereikbaarheid te veins nie

onlink sê vir die kernel om die bereikbaarheidskontrole vir ’n poort oor te slaan en tog daarheen te stuur. Dit skep nie ’n pad nie, los nie ARP op vir ’n adres wat nie daar is nie, en maak nie ’n afgeleë router op jou Ethernet-segment antwoord nie. Dit is wettig vir poorte wat antwoord maar nie in ’n gekoppelde subnet sit nie, en dit is ’n lokval wanneer dit gebruik word om ’n fout toe te maak wat jy nie verduidelik het nie.

As die roete net met onlink installeer, is die volgende vraag waarom die poort nie is waar jy dink dit is nie. ’n Verkeerde VLAN, ’n tweede adres op die verkeerde koppelvlak of ’n tikfout in die laaste okteet lewer dit alles op, en elkeen van hulle breek ook die terugpad sodra verkeer begin vloei.

Punt-tot-punt-tonnels is nie Ethernet nie

’n Tonneltoestel doen nie ARP nie en het dikwels geen betekenisvolle subnet van bure nie. Sy roetes lyk dikwels soos 10.70.0.0/24 dev tun0, sonder enige via, want die eweknie is die enigste ander eindpunt. Om ’n LAN-styl via in daardie tabel te kopieer, lewer ’n roete wat die kernel kan verwerp of, erger, een wat na ’n adres wys wat die eweknie nooit antwoord nie.

Hou die twee modelle apart in die handleiding: ’n LAN-roete het ’n bereikbare poort, ’n tonnelroete het ’n koppelvlak en ’n eweknie. WireGuard, OpenVPN en IPsec bied almal effens verskillende vorms, so teken die vorm aan wat jy werklik gebruik het eerder as om van een gasheer te veralgemeen.

Voeg by, bevestig, rol terug

Die hele verandering is drie opdragte en een kontrole, en dit moet in daardie volgorde neergeskryf word:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Bevestig die pad, bevestig een bestemming, en hou dan die verwyderingsreël gereed ingeval die verandering die gasheer onbereikbaar maak op ’n manier wat jy nie voorsien het nie. As die roete ’n herlaai moet oorleef, sit dit in die gasheer se netwerkkonfigurasie eerder as in ’n dop-profiel, en toets die herlaai voordat jy daarop staatmaak. ’n Roete wat net in die dop bestaan wat dit bygevoeg het, is ’n roete wat jy twee keer sal ontfout.