Pse nënrrjeti pas një klienti OpenVPN është i paaksesueshëm?

Ping-et drejt adresës së tunelit të serverit kalojnë, tabela e rrugëve e klientit duket e saktë, dhe LAN-i pas atij klienti është ende i paaksesueshëm. Tabela e rrugëtimit e klientit duket e saktë, serveri ka një rrugë që tregon drejt tunelit, dhe paketat vazhdojnë të zhduken. Ky është simptoma klasike e një tuneli layer-3 që nuk e di se një nga klientët e tij është gjithashtu portë.

Një ndërfaqe tun nuk ka hap tjetër për klient. Kernel-i sheh një ndërfaqe të vetme me shumë partnerë, prandaj vendimi se cili klient duhet të marrë një paketë për një LAN të largët duhet të merret brenda procesit OpenVPN. Ky vendim konfigurohet me iroute, dhe pa të paketa nuk ka ku të shkojë.

Serveri rrugëton sipas klientit, jo sipas ndërfaqes

Kur serveri duhet të dërgojë një paketë në adresën e tunelit të një klienti, përgjigja është e qartë: adresa i përket sesionit të atij klienti. Kur destinacioni është një nënrrjet i tërë pas atij klienti, adresa nuk i përket askujt që serveri njeh, dhe rruga e kernel-it drejt tunelit thotë vetëm "përmes kësaj ndërfaqeje", pa thënë se cili partner.

OpenVPN e zgjidh këtë me një tabelë rrugëtimi të brendshme që lidh një prefiks destinacioni me një klient të caktuar. Ajo tabelë ndërtohet nga hyrjet iroute, prandaj një rrugë e zakonshme në hostin e serverit nuk mjafton. Rruga e kernel-it e çon paketën te ndërfaqja e tunelit; lidhja e brendshme vendos se cili sesion e merr. Prandaj edhe rregullimi nuk shfaqet kurrë në daljen e rrugëve të kernel-it.

Nëse mungon lidhja, paketa arrin te serveri, përputhet me rrugën e tunelit dhe hidhet, sepse asnjë klient nuk e kërkon destinacionin. Asgjë nuk regjistron një gabim të pastër, prandaj dështimi duket si një vrimë e zezë e heshtur, jo si një lak rrugëtimi.

Shkrimi i hyrjes iroute që emërton klientin

iroute jeton në një skedar konfigurimi specifik për klientin, jo në konfigurimin kryesor të serverit. Drejtojeni serverin nga një drejtori me opsionin client-config-dir, më pas krijoni një skedar emri i të cilit është emri i përbashkët i certifikatës së klientit dhe vendosni prefiksin brenda.

Për një degë LAN-i i së cilës është 10.20.0.0/24 dhe emri i përbashkët i certifikatës është branch-router, skedari në atë shteg përmban një rresht si iroute 10.20.0.0 255.255.255.0. Konfigurimi kryesor ka nevojë vetëm për opsionin e drejtorisë; prefiksi jeton te klienti.

Emri i përbashkët është pjesa e brishtë. Një certifikatë e lëshuar me subject tjetër, ose një vendosje që vërteton përdoruesit me emrin e përdoruesit ndërsa skedari emërtohet sipas certifikatës, prodhon një skedar që nuk lexohet kurrë. Kontrolloni emrin që serveri raporton në të vërtetë për sesionin dhe merrni në konsideratë opsionin që bën një klient të papërputhshëm të dështojë në vend që të lidhet në heshtje pa rrugët e tij. Riemërtimi i skedarit që të përputhet me certifikatën është një rregullim pesëminutësh që parandalon një mbrëmje shumë të gjatë.

Një klient mund të zotërojë disa prefikse. Shtoni një rresht iroute për çdo rrjet dhe mbani listën pranë pjesës tjetër të cilësimeve të atij klienti, që lidhja të mbetet e auditueshme.

Ndërtimi i rrugës së kthimit në të dy drejtimet

Sjellja e paketave në LAN-in e largët është gjysma e punës. Klienti duhet të dërgojë gjithashtu trafikun e atij LAN-i në tunel, gjë që zakonisht bëhet duke shtyrë një rrugë te klienti: një rresht si push "route 10.8.0.0 255.255.255.0" i thotë çdo klienti se si ta arrijë rrjetin në anën e serverit. Për degën, rruga ekuivalente tregon drejt tunelit për gjithçka që duhet të arrijë në anën e serverit.

Drejtimi i kthimit ka nevojë për një pronar në anën e largët. Atje dikush duhet ta dijë rrugën e kthimit: një rrugë statike në ruterin e LAN-it që drejton grupin VPN te serveri, ose përkthim adresash në server para se trafiku të hyjë në LAN. Rruga statike i mban adresat origjinale të dukshme në regjistra dhe në rregullat e aksesit, por kërkon bashkëpunimin e pronarit të LAN-it; përkthimi është i vetëmjaftueshëm, por fsheh se kush u lidh në të vërtetë.

Përcjellja duhet të jetë e aktivizuar në hostin e serverit. Pa të kernel-i e pranon paketën nga tuneli dhe refuzon ta kalojë te ndërfaqja e LAN-it, gjë që nga këndvështrimi i klientit duket njësoj si një iroute që mungon.

Verifikimi i aksesueshmërisë me sondat e duhura

Testoni me shtresa në vend që të bëni ping në skajin e largët dhe të hamendësoni. Nga serveri, kontrolloni që lidhja e brendshme për prefiksin ekziston dhe që rruga e kernel-it tregon drejt tunelit. Nga klienti, konfirmoni që rruga e shtyrë është instaluar dhe që rruga e tij e paracaktuar për adresën e LAN-it është tuneli.

Më pas vëzhgoni paketat. Një kapje në ndërfaqen e tunelit tregon nëse serveri transmeton drejt klientit, dhe një kapje në ndërfaqen e LAN-it tregon nëse përcjell. Nëse e para tregon paketa dhe e dyta asgjë, problemi është përcjellja ose një filtër; nëse asnjëra nuk tregon asgjë, kërkimi dështoi më herët.

Dy serverë të lidhur me një tunel përsëritin të njëjtin rregull në të dyja anët: secili ka nevojë për një iroute për grupin e tjetrit dhe secili ka nevojë për rrugën dhe përcjelljen që e bëjnë shtegun simetrik. Rrugëtimi dhe politika janë çështje të veçanta këtu. Rrugëtimi vendos se ku mund të shkojë një paketë, ndërsa një rregull FORWARD vendos nëse lejohet, prandaj një klient me dy rreshta iroute arrin të dy prefikset, përveç nëse një filtër thotë ndryshe.