Shtoni route 10.60.0.0 255.255.255.0 në konfigurimin e serverit, rinisni, rilidhni një laptop dhe nënrrjeti është ende i paarritshëm nga ai laptop. Rreshti u pranua, shërbimi nisi pastër dhe asgjë në log nuk duket gabim. Ajo që ndodhi është se rruga u instalua në makinën që redaktuati: porta tani beson se mund ta arrijë atë prefiks, ndërsa klientit nuk iu tha asgjë. Vendosja është e gjithë çështja dhe ka katër vende ku i njëjti rresht mund të jetojë.

Katër vendet dhe kush merr secilin

Një rrugë mund të shtohet nga konfigurimi i vetë klientit, t'i ofrohet çdo klienti përmes një push global, t'i ofrohet një klienti përmes një skedari specifik për klientin, ose të shkruhet në kontekstin e vetë rrugëtimit të serverit.

Këto katër raste përdorin sintaksë pothuajse identike dhe japin rezultate krejtësisht të ndryshme. Tre të parët ndikojnë në atë që klienti dërgon në tunel; i katërti ndikon në mënyrën se si serveri arrin një rrjet, gjë që është e dobishme kur vetë serveri ka nevojë për një shteg dhe e dëmshme kur ngatërrohet me shpërndarje.

Vendosni cilin nga të katërt dëshironi përpara se ta shkruani rreshtin, pastaj konfirmoni marrësin.

PlacementEffectReceiver
Client profile routeInstalled by the client at connectThat client only
Global push "route ..."Sent to every client that accepts pushed optionsAll pulling clients
Client-specific pushSent to the matching client contextOne identity
Server config route, no pushAdded to the server's own tableThe gateway itself

Pse rruga e thatë e serverit i befaso njerëzit

Konfigurimi i serverit është vendi i parë ku shikojnë administratorët, dhe një direktivë rruge atje lexohet si një deklaratë për rrjetin VPN. Nuk është. OpenVPN e trajton atë si një instalim lokal rruge në makinën ku ekzekutohet daemon-i, që është saktësisht i njëjti lloj ndryshimi që do të bënit me ip route dhe më pas do ta harronit.

Shpërndarja kërkon që rruga të pushohet, dhe push kërkon që klienti ta tërheqë. Një klient i nisur me opsionet e tërhequra të çaktivizuara e injoron ofertën plotësisht. Kontrolloni të dy skajet e atij shtrëngimi duarsh përpara se të rishkruani skedarin e serverit, sepse log-u i serverit nuk do të ankohet: nga ana e tij oferta u dërgua. Një rrugë e pranuar gjithashtu hyn në fuqi vetëm në lidhjen tjetër, kurrë në sesionin ku jeni tashmë.

Kur i shihni të dyja si operacione të ndara, dështimi nuk është më misterioz: serveri arrin prefiksin, klienti nuk arrin, dhe të dyja deklaratat janë të vërteta në të njëjtën kohë.

Skedarë për çdo klient dhe identiteti me të cilin përputhen

Një skedar specifik për klientin emërtohet sipas identitetit që serveri autentikoi, i cili si parazgjedhje është emri i përbashkët i certifikatës. Një emër lidhjeje miqësor në një klient desktop nuk është ai vlerë, dhe një mospërputhje prodhon një skedar që nuk lexohet kurrë.

Kontrolloni drejtorinë që serveri përdor në të vërtetë, pastaj konfirmoni që emri i skedarit përputhet saktësisht me identitetin e autentikuar, duke përfshirë shkronjat e mëdha dhe të vogla.

grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/

Brenda atij skedari rruga duhet ende të pushohet, sepse konteksti për çdo klient është një grup opsionesh të aplikuara në sesionin e atij klienti, jo një tabelë lokale rrugëtimi. Një rrugë e thatë atje ka të njëjtin problem si një rrugë e thatë në skedarin global.

Skedari i vetë klientit dhe mjeti që e zotëron

Një rrugë e vendosur në konfigurimin e klientit instalohet kur ai klient lidhet dhe hiqet kur shkëputet, që është cikli i duhur i jetës për një destinacion statik.

Nëse profilin e zotëron një menaxher rrjeti, ai mund t'i importojë një herë ato opsione dhe pastaj të mbajë kopjen e vet. Redaktimi i skedarit të shkarkuar më vonë nuk ndryshon asgjë, që është një shkak i zakonshëm i "rruga është atje por nuk zbatohet".

Kontrolloni profilin aktiv në vend të skedarit që shkarkuat, dhe kontrolloni cilësimet e importuara që shfaq menaxheri. Pastaj lidhuni dhe pyesni sistemin se cilën shteg përdor një adresë e caktuar, në vend që të supozoni se tuneli fitoi sepse rruga ekzistonte në një skedar teksti.

Verifikoni tek klienti, pastaj kontrolloni shtegun e kthimit

Pyetni tabelën e rrugëtimit të vetë klientit për destinacionin, jo atë të serverit. Një kërkim për një host të vetëm brenda prefiksit mjafton për të treguar ndërfaqen dhe kërcimin e radhës që do të përdoren.

ip route get 10.60.0.10

Nëse kërkimi tregon tunelin, shpërndarja funksionoi dhe problemi i mbetur është diku tjetër. Nëse tregon portën e parazgjedhur, rruga nuk u instalua, u filtrua nga një opsion në anën e klientit, ose i përket një profili që klienti nuk e përdor.

Supozoni se shpërndarja funksionoi dhe prapë asgjë nuk përgjigjet: atëherë kontrolloni përcjelljen në portë, shtegun e kthimit të anës tjetër dhe çdo firewall mes tyre. Një rrugë zgjedh një shteg, ajo nuk jep akses.

Artikuj të ngjashëm