Miks on OpenVPN-kliendi taga olev alavõrk kättesaamatu?

Pingid serveri tunneliaadressile õnnestuvad, kliendi enda marsruuditabel tundub korras ja selle kliendi taga olev LAN on endiselt kättesaamatu. Kliendi marsruuditabel tundub õige, serveril on tunnelile osutav marsruut ja paketid kaovad endiselt. See on klassikaline layer-3 tunneli sümptom, mis ei tea, et üks selle klientidest on ühtlasi lüüs.

tun-liidesel pole kliendi kohta järgmist hüpet. Kernel näeb ühte liidest paljude partneritega, seega tuleb otsus, milline klient peaks kaug-LAN-i paketi saama, teha OpenVPN-i protsessi sees. Seda otsust konfigureeritakse iroute-ga ja ilma selleta pole paketil kuhugi minna.

Server marsruudib kliendi, mitte liidese järgi

Kui server peab saatma paketi kliendi tunneliaadressile, on vastus üheselt selge: aadress kuulub selle kliendi sessioonile. Kui sihtkohaks on kogu alavõrk selle kliendi taga, ei kuulu aadress kellelegi, keda server teab, ja kerneli marsruut tunnelini ütleb ainult "läbi selle liidese", nimetamata partnerit.

OpenVPN lahendab selle sisemise marsruuditabeliga, mis vastendab sihtkoha prefiksi konkreetse kliendiga. See tabel ehitatakse iroute-kirjetest, seetõttu ei piisa serveri hosti tavalisest marsruudist. Kerneli marsruut viib paketi tunneliliidesesse; sisemine vastendus otsustab, milline sessioon selle saab. Seetõttu ei ilmugi parandus kunagi kerneli marsruudiväljundisse.

Kui vastendus puudub, jõuab pakett serverisse, sobib tunnelimarsruudiga ja visatakse kõrvale, sest ükski klient ei nõua sihtkohta. Miski ei logi puhast viga, seetõttu näeb rike välja nagu vaikne must auk, mitte marsruuditsükkel.

Kirjuta iroute-kirje, mis nimetab kliendi

iroute elab kliendipõhises konfiguratsioonifailis, mitte serveri peakonfiguratsioonis. Suuna server valikuga client-config-dir kausta, seejärel loo fail, mille nimi on kliendi sertifikaadi üldnimi, ja pane prefiks sinna sisse.

Haru puhul, mille LAN on 10.20.0.0/24 ja sertifikaadi üldnimi branch-router, sisaldab selle tee fail rida nagu iroute 10.20.0.0 255.255.255.0. Peakonfiguratsioonil on vaja ainult kausta valikut; prefiks elab kliendi juures.

Üldnimi on habras osa. Erineva subject-iga välja antud sertifikaat või juurutus, mis autendib kasutajaid kasutajanimega, samal ajal kui fail on nimetatud sertifikaadi järgi, loob faili, mida kunagi ei loeta. Kontrolli nime, mille server sessiooni kohta tegelikult teatab, ja kaalu valikut, mis paneb mittevastava kliendi ebaõnnestuma, selle asemel et vaikselt ilma marsruutideta ühenduda. Faili sertifikaadiga vastavaks ümbernimetamine on viie minuti parandus, mis hoiab ära väga pika õhtu.

Üks klient võib omada mitut prefiksit. Lisa üks iroute-rida võrgu kohta ja hoia nimekiri selle kliendi ülejäänud seadete kõrval, et vastendus jääks auditeeritavaks.

Tagasitee ehitamine mõlemas suunas

Pakettide kaug-LAN-i viimine on pool tööd. Klient peab saatma ka selle LAN-i liikluse tunnelisse, mida tavaliselt tehakse marsruudi kliendile lükkamisega: rida nagu push "route 10.8.0.0 255.255.255.0" ütleb igale kliendile, kuidas jõuda serveripoolse võrguni. Haru jaoks osutab samaväärne marsruut tunnelile kõigele, mida see serveripool jõudma peaks.

Tagasisuund vajab omanikku kaugemal poolel. Seal peab keegi teadma teed tagasi: staatiline marsruut LAN-i ruuteril, mis suunab VPN-i basseini serverisse, või aadressitõlge serveris enne, kui liiklus LAN-i siseneb. Staatiline marsruut hoiab algseid aadresse logides ja juurdepääsureeglites nähtavana, kuid nõuab LAN-i omaniku koostööd; tõlge on iseseisev, kuid varjab, kes tegelikult ühendus.

Edastamine peab olema serveri hostis lubatud. Ilma selleta võtab kernel paketi tunnelist vastu ja keeldub seda LAN-liidesesse edastamast, mis kliendi vaatepunktist näeb välja täpselt nagu puuduv iroute.

Kättesaadavuse kontrollimine õigete sondidega

Testi kihtide kaupa, mitte pingi kaugemat otsa ja oleta. Serverist kontrolli, et prefiksi sisemine vastendus on olemas ja kerneli marsruut osutab tunnelile. Kliendist kinnita, et lükatud marsruut on paigaldatud ja selle vaikimisi tee LAN-i aadressile on tunnel.

Seejärel jälgi pakette. Tunneliliidese püüdmine näitab, kas server saadab kliendi poole, ja LAN-liidese püüdmine näitab, kas see edastab. Kui esimene näitab pakette ja teine mitte, on probleem edastamises või filtris; kui kumbki ei näita midagi, ebaõnnestus otsing varem.

Kaks tunneliga ühendatud serverit kordavad mõlemal poolel sama reeglit: kumbki vajab iroute-i teise basseini jaoks ning kumbki vajab marsruuti ja edastamist, mis teevad tee sümmeetriliseks. Marsruutimine ja poliitika on siin eraldi küsimused. Marsruutimine otsustab, kuhu pakett minna võib, samas kui FORWARD-reegel otsustab, kas tohib, seega kahe iroute-reaga klient pääseb mõlemasse prefiksisse, kui filter ei ütle teisiti.