LAN-ruuter pluss VPN-klient: kaks seadet, kaks marsruutimistabelit

Kaks seadet edastavad paketi ja kumbki hoiab oma tabelit. LAN-ruuter teab, et kaugprefiks kuulub VPN-kliendile, ja VPN-klient teab, kuidas selle prefiksini oma tunneli kaudu jõuda. Seadistage ainult esimene tabel ja pakett jõuab masinasse, millel pole sobivat marsruuti, nii et see lahkub uuesti vaikimisi marsruudi kaudu. See on kogu rike ja LAN-i poolt vaadatuna näeb see välja nagu marsruutimistsükkel, sest peaaegu ongi.

Joonistage kaks hüpet enne, kui marsruuti puutute

Võtke illustreeriv paigutus: LAN-i hostid aadressil 192.168.50.0/24, tavaline ruuter aadressil 192.168.50.1, pühendatud klient aadressil 192.168.50.15 ja kaug-LAN aadressil 10.60.0.0/24, mis on kättesaadav ainult selle kliendi hoitava tunneli kaudu. Kumbki privaatvahemik ei kattu teisega, ja tunnelil on oma aadressiplaan.

Mõlemad privaatvahemikud on olulised, sest need otsustavad, milline seade saab vastata. Kaugpool näeb paketti saabuvat kliendi tunneli aadressilt ja selle vastus peab leidma tee tagasi aadressile 192.168.50.0/24. Kui seadistatud on ainult väljuv suund, võib päring töötada, samal ajal kui vastus kaob.

Samm 1: suunake ruuter kliendi, mitte tunneli poole

Lisage LAN-ruuterile sihtkoha marsruut, mille järgmine hüpe on kliendi LAN-i aadress:

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

See kirje ütleb „toimetage see masinasse, mis suudab tunnelit teha“. See ei ütle midagi selle kohta, kuidas tunnel ehitatakse, ja see ei asenda kliendi enda marsruuti. Hallatud ruuteril elab vaste seadme staatiliste marsruutide lehel; Linuxi ruuteril kuulub see LAN-i omava liidese konfiguratsiooni, mitte shelli, mille te sulgete.

Kontrollige teise käsu vastust. Kui see teatab kliendi gateway ja LAN-i liidese device-na, on esimene hüpe õige ja ülejäänud töö on teises masinas.

Samm 2: andke kliendile tunneli pool oma marsruut

Klient saab nüüd paketi aadressile 10.60.0.0/24 ja vaatab oma tabelisse. Kui tema tunneli konfiguratsioon paigaldas sellele prefiksile marsruudi, jätkub pakett krüpteeritult. Kui ei, vastab pakett tavalisele vaikimisi marsruudile ja läheb tagasi aadressile 192.168.50.1, mis saadab selle uuesti kliendile.

Vaadake enne, kui midagi lisate:

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

Puuduv prefiksimarsruut kõigis tabelites on leid, mida otsite. Lisage see tunneli enda konfiguratsiooni kaudu, et järgmine taasühendus paigaldaks selle uuesti; käsitsi antud ip route add kaob seansiga ja toob rikke tagasi kõige ebamugavamal hetkel. Järgmine hüpe on tunneli liides või aadress, mille VPN määrab oma partneriks, olenevalt kliendist, ja partneri aadress peaks tulema praegusest profiilist, mitte vanast märkmest.

Tsükkel ei ole tekkides praktikas lõpmatu: TTL langeb igal läbimisel ja pakett sureb aja ületamise teatega. Seetõttu võib korduv traceroute viidata tsüklile, samal ajal kui klient, kes lihtsalt ei edasta, pillab sama paketi vaikselt.

Samm 3: lubage edastamine ja valige tagasitee

Vastuvõtmine ja edastamine on erinevad õigused. net.ipv4.ip_forward=1 kliendil lubab transiiti kerneli tasandil, ja tulemüürireegel peab selle ikkagi lubama LAN-i liidese ja tunneli vahel. Reegel, mis lubab juurdepääsu kliendi enda halduslehele, ei luba transiiti kaug-LAN-i, ja seda erinevust on lihtne kahe silma vahele jätta, kui sama host vastab pingidele lokaalselt.

Kaugpoolel on peegelprobleem. Ta peab teadma, et 192.168.50.0/24 on selle autenditud kliendi kaudu kättesaadav. OpenVPN puhul tähendab see tavaliselt serveri konfiguratsiooni poolt saadetud kliendipõhist marsruuti või serveril olevat kliendipõhist faili, mis deklareerib kliendi taga oleva LAN-i. Ilma selleta kas pillab kaug-LAN vastuse või saadab selle oma vaikimisi lüüsile, milleks on internet.

Allika tõlkimine on alternatiiv, kui LAN-i prefiksit ei saa kuulutada. Kliendil olev piiratud masquerade-reegel kirjutab allika ümber tunneli aadressiks ja vastused naasevad siis loomulikult. See peidab ka, milline LAN-i host päringu tegi, ja iseenesest ei luba kaugpoolel algatada ühendusi sissepoole. Valige see kompromiss teadlikult, selle asemel et lisada üldine masquerade ja avastada kõrvalmõju hiljem.

Samm 4: tehke mõlemad otsused püsivaks ja testige siis tegelikku teed

Igal marsruudil on omanik ja omanik on konfiguratsioon, mis taastatakse alglaadimisel või taasühendamisel. Ruuteril võib see olla staatilise marsruudi kirje; kliendil võib see olla VPN-profiil, NetworkManager või systemd-networkd. Kontrollige, ühendades tunneli uuesti ja taaskäivitades kliendi, seejärel lugege tabel uuesti, selle asemel et muudatust usaldada.

Hoidke puutumatuna vaikimisi marsruut, mis kannab tunneli välist ühendust. Selle asendamine seadistuse „lihtsustamiseks“ katkestab krüpteeritud tee enne, kui mis tahes sisemine liiklus saab seda kasutada, ja sümptomiks on tunnel, mis ei taastu pärast muudatust kunagi.

Testige tavalisest LAN-i hostist, mitte kliendist, sest kliendil tekkinud päring ei harjuta kunagi ruuteri esimest hüpet. Tooge teenus, mis eksisteerib ainult kaug-LAN-is, ja kinnitage vastuse keha, seejärel vaadake kliendi loendureid või logisid, et transiiti näha. Privaatseid hüppeid näitav sisemine traceroute tõestab edastamist, mitte krüpteerimist: välimine tee on eraldi vaatlus ja ainult tunneli enda liidese loendurid näitavad, mis sealt välja läks.