Shtoni një rrugë, rinisni shërbimin, rilidheni dhe tabela e klientit duket saktësisht si më parë. Dy gjëra të ndryshme mund të jenë të vërteta: serveri nuk e ngarkoi kurrë ndryshimin tuaj, ose klienti nuk instaluar kurrë atë që mori. Nuk kanë asgjë të përbashkët përveç simptomës, prandaj hapi i parë është të zbuloni se cilin prej dy rasteve keni.

Krahasimi më poshtë shkon nga procesi jashtë, sepse procesi është autoriteti i vetëm për atë se cili skedar është në fuqi.

Skedari që redaktuat dhe skedari që lexon procesi

Filloni me unit dhe me rreshtin e komandës që prodhoi. Në një host systemd, systemctl cat openvpn@server printon rreshtin ExecStart, dhe unit-i i instancës zakonisht e nxjerr rrugën e konfigurimit nga emri i instancës, kështu që një daemon i nisur si openvpn@office lexon një skedar tjetër nga ai i nisur si openvpn@server. Krahasojeni atë me argv të procesit që po ekzekutohet. Një mjet për menaxhimin e konfigurimit shton një mënyrë tjetër për të humbur ndryshimin: mund të shkruajë një skedar të saktë në një vend që unit-i nuk e përmend kurrë, dhe atëherë një vendosje e suksesshme duket si asgjë.

Vulat kohore e zgjidhin shpejt: nëse skedari është më i ri se ora e nisjes së procesit, procesi nuk mund ta ketë lexuar. Firmware-i i ruterit shton një rast të tretë, sepse shumë modele i mbajnë cilësimet në flash dhe e rindërtojnë konfigurimin gjatë nisjes, gjë që e bën redaktimin e një skedari në disk shtresën krejt të gabuar.

Çfarë shtyn serveri dhe çfarë instalon klienti

Një rrugë e shtyrë duhet të kalojë dy filtra. Në server duhet të jetë në konfigurimin e ngarkuar, jo në një bllok të komentuar ose në një skedar specifik për klientin emri i të cilit nuk përputhet. Në klient, pull duhet të jetë i aktivizuar dhe asnjë pull-filter nuk duhet ta hedhë poshtë opsionin. Lidhuni me verbosity 4 dhe lexoni opsionet e shtyra që raporton klienti: nëse rruga është në atë listë, serveri e bëri punën e tij dhe klienti po zgjedh të mos e instalojë.

Skedarët specifikë për klientin janë një burim i shpeshtë konfuzioni. Një skedar i emërtuar sipas common name të certifikatës shtyn opsione vetëm për atë klient, dhe një ndryshim prej një karakteri e ndalon shtyrjen në heshtje, pa gabim nga asnjëra anë. Serveri regjistron common name që pa në lidhje, prandaj krahasoni atë vlerë me emrin e skedarit, jo me atë që mendoni se quhet klienti.

Prefiksi i shtyrë dhe rruga e kthimit janë probleme të ndryshme

Një klient që e injoron me qëllim redirect-gateway për të mbajtur rrugën e vet lokale të internetit krijon një boshllëk të dytë, të palidhur. Sondat e serverit arrijnë në adresën e tunelit, por përgjigjet nuk vijnë kurrë, sepse një përgjigje e adresuar te IP-ja e tunelit të serverit rrugëtohet përmes gateway-it të zakonshëm parazgjedhur të klientit. Këtu nuk është fajtore rruga e subnetit e shtyrë; ajo që mungon është një rrugë që e kthen trafikun për rrjetin e tunelit të serverit përmes pajisjes së tunelit.

Shtimi i asaj rruge në klient rregullon përgjigjet ndaj sondave që nis serveri. Nuk e zëvendëson rrugën e subnetit të shtyrë, dhe e kundërta është gjithashtu e vërtetë, sepse të dyja përshkruajnë drejtime të kundërta të udhëtimit.

Krahasoni tabelat në të dy skajet

Pas çdo ndryshimi, rilidhuni dhe lexoni tabelën e klientit për prefiksin e shtyrë dhe për pajisjen e tunelit. Pastaj provoni në të dy drejtimet: nga klienti te një host në subnetin e shtyrë, dhe nga ai host përsëri te klienti. Një rrugë që ekziston por nuk mbart trafik do të thotë një nga tre gjëra: ana tjetër nuk përcjell, një firewall po e hedh rrjedhën, ose përgjigja nuk ka rrugë kthimi.

Mbani tre identifikues së bashku: rrugën e konfigurimit, emrin e unit-it ose të instancës dhe identitetin e klientit me të cilin testuat.

Këta tre e kthejnë rastin tjetër në një kontroll pesëminutësh në vend të një hetimi të ri, dhe janë pikërisht ato që i duhen një kolegu kur tuneli bëhet problem i dikujt tjetër.

Një problem rruge që i mbijeton një rinisjeje shpesh nuk është fare problem rrugëtimi; defekti ndodhet mbi tabelën që vazhdoni të lexoni.

Artikuj të ngjashëm