Ďalší skok v trase VPN: prečo musí byť brána dostupná lokálne

Trasa do siete VPN nesie dve adresy, ktoré sa ľahko zamieňajú: prefix cieľa, ku ktorému sa paket snaží dostať, a ďalší skok, ktorý ho posunie o krok bližšie. Na hostiteľovi v LAN musí byť tým ďalším skokom smerovač, ku ktorému sa na tom istom prepojení skutočne dostanete. Vzdialená adresa VPN nie je ďalším skokom, nech sa akokoľvek presne zhoduje s cieľom, ktorý máte na mysli.

Táto príručka pokrýva obvyklý prípad: notebook na 192.168.20.0/24, bránu VPN s adresou LAN 192.168.20.5 a vzdialenú sieť 10.70.0.0/24 za touto bránou. Všetky príkazy nižšie predpokladajú, že ste na notebooku, ak nie je uvedené inak.

Dve adresy, jedna trasa

Zamýšľaný záznam je 10.70.0.0/24 via 192.168.20.5. Prefix hovorí, kam paket ide; adresa via hovorí, kto ho tam nesie. Jadro odmieta nainštalovať trasu, ktorej bránu nedokáže dosiahnuť cez rozhranie, ktoré uvediete, a toto odmietnutie je celý zmysel: ďalší skok, ktorý na dostupnosť potrebuje tunel, nemôže byť ďalším skokom, ktorý tunel stavia.

Prvá kontrola teda nie je «beží brána», ale «je brána na tomto prepojení». Vlastná podsiet notebooku, jeho záznam ARP alebo suseda a rozhranie v trase sa musia zhodovať. Adresa, ktorá existuje len vnútri 10.70.0.0/24, môže byť cieľom druhej trasy, nikdy však via tej prvej.

Na čo ďalší skok zaväzuje bránu

Inštalácia trasy na notebooku rozhoduje len o prvom odovzdaní. Brána potom potrebuje vlastnú cestu: zapnuté preposielanie, tunelovú trasu pre 10.70.0.0/24 a akúkoľvek prístupovú politiku, ktorá určuje, kto ju smie používať. Na Linuxe je to net.ipv4.ip_forward=1 plus tunelová trasa; firewall pred ňou potrebuje pravidlo, ktoré povoľuje preposielaný tok.

Spätný smer je časť, na ktorú ľudia zabúdajú. Vzdialená strana musí mať trasu späť do 192.168.20.0/24, alebo musí návrh preložiť zdroj notebooku na niečo, čo vzdialená strana pozná. Fungujúci ping z brány dokazuje, že brána dosiahne vzdialenú sieť; nič nehovorí o tom, či pakety notebooku prežijú cestu späť.

Overte vyhľadanie z hostiteľa, ktorý odosiela

Opýtajte sa jadra, ktorý ďalší skok by zvolilo, a prečítajte rozhranie v odpovedi:

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

Ak vyhľadanie hlási bránu a rozhranie LAN, prvý úsek je nakonfigurovaný podľa zámeru. Ak hlási tunelové zariadenie, niečo skoršie v tabuľke je konkrétnejšie a vyhráva. Ak sa trasa vôbec nenainštaluje, jadro vám hovorí, že brána nie je dostupná, a tá správa je užitočnejšia než akýkoľvek odchyt paketov.

Potom test zopakujte zo správneho miesta. Požiadavka vytvorená na bráne používa vlastnú zdrojovú adresu brány, čo môže skryť chýbajúcu spätnú trasu alebo politiku, ktorá povoľuje len určité zdroje. Manuál ip-route oddeľuje cieľ, bránu a prepis onlink, a prepis stojí za pochopenie skôr, než ho použijete.

Nepoužívajte onlink na predstieranie dostupnosti

onlink hovorí jadru, aby preskočilo kontrolu dostupnosti brány a napriek tomu tam poslalo. Nevytvára cestu, nerozkladá ARP pre adresu, ktorá tam nie je, a neprinúti vzdialený smerovač odpovedať na vašom segmente Ethernet. Je legitímny pre brány, ktoré odpovedajú, ale nesedia v pripojenej podsieti, a je pascou, keď sa použije na utíšenie chyby, ktorú ste nevysvetlili.

Ak sa trasa nainštaluje len s onlink, ďalšou otázkou je, prečo brána nie je tam, kde si myslíte. Nesprávna VLAN, druhá adresa na nesprávnom rozhraní alebo preklep v poslednom oktete to všetko spôsobujú a každá z nich tiež rozbije spätnú cestu, len čo prevádzka začne tiecť.

Tunely bod-bod nie sú Ethernet

Tunelové zariadenie nerobí ARP a často nemá zmysluplnú podsiet susedov. Jeho trasy často vyzerajú ako 10.70.0.0/24 dev tun0, bez akéhokoľvek via, pretože partner je jediný druhý koncový bod. Kopírovanie via v štýle LAN do tej tabuľky vytvorí trasu, ktorú jadro môže odmietnuť alebo, horšie, takú, ktorá ukazuje na adresu, na ktorú partner nikdy neodpovie.

Držte oba modely v príručke oddelene: trasa LAN má dostupnú bránu, tunelová trasa má rozhranie a partnera. WireGuard, OpenVPN a IPsec ukazujú mierne odlišné tvary, preto si zapíšte tvar, ktorý ste skutočne použili, namiesto zovšeobecňovania z jedného hostiteľa.

Pridajte, potvrďte, vráťte späť

Celá zmena sú tri príkazy a jedna kontrola a mala by byť zapísaná v tomto poradí:

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

Potvrďte cestu, potvrďte jeden cieľ a potom majte poruke riadok na vymazanie pre prípad, že zmena urobí hostiteľa nedostupným spôsobom, ktorý ste nepredvídali. Ak má trasa prežiť reštart, uložte ju do sieťovej konfigurácie hostiteľa, nie do profilu shellu, a reštart otestujte, kým sa na ňu spoliehate. Trasa, ktorá existuje len v shelli, ktorý ju pridal, je trasa, ktorú budete ladiť dvakrát.