Järgmine hüpe VPN-marsruudis: miks peab lüüs olema kohapeal kättesaadav

VPN-võrku suunduv marsruut kannab kahte aadressi, mida on lihtne segi ajada: sihtkoha prefiks, milleni pakett jõuda püüab, ja järgmine hüpe, mis liigutab selle ühe sammu lähemale. LAN-hostis peab see järgmine hüpe olema ruuter, milleni te tõesti samal lingil jõuate. Kaug-VPN-i aadress ei ole järgmine hüpe, ükskõik kui korralikult see teie mõttes oleva sihtkohaga kokku sobib.

See juhend käsitleb tavalist juhtumit: sülearvuti aadressil 192.168.20.0/24, VPN-lüüs LAN-aadressiga 192.168.20.5 ja kaugvõrk 10.70.0.0/24 selle lüüsi taga. Kõik allolevad käsud eeldavad, et olete sülearvutis, kui pole öeldud teisiti.

Kaks aadressi, üks marsruut

Kavandatud kirje on 10.70.0.0/24 via 192.168.20.5. Prefiks ütleb, kuhu pakett läheb; via-aadress ütleb, kes selle sinna viib. Kernel keeldub paigaldamast marsruuti, mille lüüsile ta ei pääse teie nimetatud liidese kaudu, ja see keeldumine ongi kogu mõte: järgmine hüpe, mis vajab kättesaadavaks olemiseks tunnelit, ei saa olla järgmine hüpe, mis tunneli ehitab.

Nii et esimene kontroll ei ole «kas lüüs töötab», vaid «kas lüüs on sellel lingil». Sülearvuti enda alamvõrk, selle ARP- või naaberkirje ja marsruudis olev liides peavad kõik kokku langema. Aadress, mis eksisteerib ainult 10.70.0.0/24 sees, võib olla teise marsruudi sihtkoht, kuid mitte kunagi esimese via.

Milleks järgmine hüpe lüüsi kohustab

Marsruudi paigaldamine sülearvutisse otsustab ainult esimese üleandmise. Seejärel vajab lüüs oma teed: edastamine sisse lülitatud, tunnelimarsruut 10.70.0.0/24 jaoks ja mis tahes juurdepääsupoliitika, mis määrab, kes tohib seda kasutada. Linuxis on see net.ipv4.ip_forward=1 pluss tunnelimarsruut; tulemüür selle ees vajab reeglit, mis lubab edastatavat voogu.

Tagasisuund on osa, mille inimesed unustavad. Kaugpoolel peab olema marsruut tagasi 192.168.20.0/24, või peab lahendus tõlkima sülearvuti allika millekski, mida kaugpool tunneb. Töötav ping lüüsist tõestab, et lüüs jõuab kaugvõrku; see ei ütle midagi selle kohta, kas sülearvuti paketid tagasiteel vastu peavad.

Kontrollige otsingut hostist, mis saadab

Küsige kernelilt, millise järgmise hüppe see valiks, ja lugege vastuses olevat liidest:

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

Kui otsing teatab lüüsist ja LAN-liidesest, on esimene lõik kavatsuslikult seadistatud. Kui see teatab tunneliseadmest, on midagi tabelis varasemat konkreetsemat ja võidab. Kui marsruut üldse ei paigalda, ütleb kernel teile, et lüüs pole kättesaadav, ja see teade on kasulikum kui ükskõik milline paketipüük.

Seejärel korrake testi õigest kohast. Lüüsil loodud päring kasutab lüüsi enda lähteaadressi, mis võib varjata puuduvat tagasitee marsruuti või poliitikat, mis lubab ainult teatud allikaid. ip-route'i juhend eraldab sihtkoha, lüüsi ja onlink alistamise, ja alistamist tasub mõista enne selle kasutamist.

Ärge kasutage onlinki kättesaadavuse teesklemiseks

onlink ütleb kernelile, et jätaks lüüsi kättesaadavuse kontrolli vahele ja saadaks ikkagi sinna. See ei loo teed, ei lahenda ARP-i aadressile, mida pole, ega pane kaugruuterit teie Ethernet-segmendil vastama. See on õigustatud lüüside puhul, mis vastavad, kuid ei asu ühendatud alamvõrgus, ja see on lõks, kui seda kasutatakse vea vaigistamiseks, mida te ei ole selgitanud.

Kui marsruut paigaldub ainult onlink abil, on järgmine küsimus, miks lüüs pole seal, kus te arvate. Vale VLAN, teine aadress valel liidesel või trükiviga viimases oktetis tekitavad selle kõik, ja igaüks neist rikub ka tagasitee, kui liiklus hakkab voolama.

Punkt-punkt-tunnelid ei ole Ethernet

Tunneliseade ei tee ARP-i ja sageli pole sellel mõistlikku naabrite alamvõrku. Selle marsruudid näevad sageli välja nagu 10.70.0.0/24 dev tun0, ilma igasuguse via-ta, sest partner on ainus teine lõpp-punkt. LAN-stiilis via kopeerimine sellesse tabelisse tekitab marsruudi, mille kernel võib tagasi lükata või, hullem, mis osutab aadressile, millele partner kunagi ei vasta.

Hoidke kaks mudelit juhendis lahus: LAN-marsruudil on kättesaadav lüüs, tunnelimarsruudil on liides ja partner. WireGuard, OpenVPN ja IPsec esitavad kõik veidi erinevaid kujusid, seega kirjutage üles kuju, mida te tegelikult kasutasite, selle asemel et ühest hostist üldistada.

Lisage, kinnitage, võtke tagasi

Kogu muudatus on kolm käsku ja üks kontroll, ja see tuleks kirja panna just selles järjekorras:

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

Kinnitage tee, kinnitage üks sihtkoht ja hoidke siis kustutusrida käepärast, kui muudatus teeb hosti kättesaamatuks viisil, mida te ei osanud ette näha. Kui marsruut peab taaskäivituse üle elama, pange see hosti võrgukonfiguratsiooni, mitte shelli profiili, ja testige taaskäivitust enne, kui sellele loote. Marsruut, mis eksisteerib ainult selles shellis, mis selle lisas, on marsruut, mida te silute kaks korda.