VPN-ja u zhvendos: pse klienti juaj OpenVPN vazhdon të telefonojë IP-në e vjetër

Ofruesi ndryshoi adresën tuaj publike, ju përditësuat rekordin dinamik DNS dhe klienti ende nuk mund të lidhet. Nga jashtë duket sikur rekordi nuk u përhap. Shumicën e kohës rekordi është në rregull dhe klienti telefonon adresën që zgjidhi përpara zhvendosjes, sepse tuneli që punon dhe profili i ruajtur kanë secili idenë e vet se ku jeton serveri. Tre shtresa duhet të bien dakord, dhe ato përditësohen sipas kalendarëve të ndryshëm.

Shikoni çfarë telefonon profili, jo çfarë thotë DNS

Hapni lidhjen që përdorni në të vërtetë dhe lexoni rreshtin remote. Një adresë numerike atje nuk ndjek kurrë përditësimin e emrit të hostit, sado i saktë të bëhet rekordi.

Më pas kontrolloni nëse profili që redaktuate është ai që ngarkoi klienti. Profilet e importuara janë të zakonshme: një administrator mund të ketë marrë një kopje muaj më parë dhe të ketë mbajtur versionin e vet, kështu që skedari në dosjen tuaj të shkarkimeve dhe zëri në aplikacion mund të ndryshojnë. Krahasoni pikën përfundimtare në detajet e lidhjes së vetë klientit përpara se të merreni fare me korrigjimin e DNS.

Dy skedarë, një pikë përfundimtare — ky është gjetja e zakonshme këtu.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Lexoni përpjekjen tjetër të lidhjes së klientit

Rinisni lidhjen me regjistrim të detajuar dhe lexoni rreshtin ku emërtohet adresa me të cilën do të kontaktojë. Ai vlerë është ai që ka rëndësi, jo ai që zgjidhi shfletuesi juaj.

Cache-i i zgjidhësit mund të mbajë ende përgjigjen e mëparshme, dhe disa rrjete e mbajnë më gjatë sesa kërkon TTL-ja e rekordit. Pyetni zgjidhësin që klienti përdor në të vërtetë, jo një publik që e keni testuar nga diku tjetër.

Nëse regjistri tregon adresën e re dhe lidhja ende dështon, problemi është zhvendosur: paketa shkon diku dhe askush nuk përgjigjet. Kjo është çështje dëgjuesi, muri të zjarrit ose ridrejtimi i portës, dhe ndodhet në anën e serverit, jo në rrugën e zgjidhjes së klientit. Mbani të ndara këto dy dështime, sepse trajtimi i një dëgjuesi të paarritshtë si problem DNS ju bën të bëni dy herë të njëjtin qark.

Dijeni cilën rinisje po bëni

Jo të gjitha rinisjet ruajnë të njëjtin gjendje, prandaj ndryshimi i adresës mund të sillet ndryshe sipas mënyrës se si riciklohet procesi. Një rinisje e butë e shkaktuar nga një sinjal ruan më shumë kontekst të sesionit të mëparshëm, ndërsa një ndalje dhe nisje e plotë fillon përsëri nga konfigurimi. Nëse po provoni nëse klienti zgjidh përsëri, dëshironi rrugën që fillon nga konfigurimi.

Cilësimet e vazhdueshmërisë gjithashtu kanë rëndësi, sepse janë krijuar për të mbajtur atë që u vërtetua, jo për të ndjekur adresa të reja.

Testi më i pastër është një nisje e re nga profili i synuar, e ndjekur nga një vështrim në rreshtin e regjistrit që emërton pikën përfundimtare. Çdo gjë që mësoni nga një sesion pjesërisht i ruajtur është një pohim për atë sesion.

Katër opsionet dhe punët e tyre të ndara

remote me emër hosti është cilësimi që e bën të mundur fare zgjidhjen e përsëritur; një adresë fjalë për fjalë në atë rresht e përjashton. resolv-retry kontrollon çfarë ndodh kur një kërkim dështon, dhe 2.6 e vendos tashmë si të pafund si parazgjedhje. Shtimi i tij pra nuk ndryshon asgjë, dhe ai nuk planifikon kurrë një kontroll periodik për një përgjigje tjetër. Kush thotë se ai anketon adresa të reja ka ngatërruar rikuperimin me freskinë.

persist-remote-ip ka të bëjë me vazhdimësinë, jo me freskinë: ai ripërdor pikën përfundimtare që u vërtetua i fundit, përmes rinisjeve të buta që mbështet. Ndërsa provoni një zhvendosje, kjo është e kundërta e asaj që dëshironi. Çaktivizojeni për testin nëse ndërtimi juaj e aktivizon, dhe më pas rikthejeni kur pika e re të jetë vërtetuar. Nëse mbetet aktiv, një rilidhje e suksesshme mund të mos ju thotë asgjë për DNS.

float pranon një partner të vërtetuar, adresa e të cilit ndryshoi në mes të sesionit, dhe vetëm në konfigurime që e mbështesin. Ai nuk e rifreskon DNS-në dhe nuk do të ndjekë vetë një ndryshim të ofruesit. Trajtojeni si funksion elasticiteti për partnerë që enden, jo si mekanizëm adresash dinamike për servera.

Konfirmoni pikën e re përpara se të fajësoni klientin

Nga jashtë rrjetit tuaj, kontrolloni që adresa e re ka një dëgjues në portën e konfiguruar dhe që ridrejtimi i ofruesit tregon drejt saj. Një rekord A i saktë për një makinë pa portë të hapur prodhon pikërisht simptomën që njerëzit ia atribuojnë cache-it.

Pastaj rilidhuni dhe verifikoni dy gjëra: klienti u vërtetua ndaj certifikatës së pritur të serverit, dhe sesioni arrin burimin që kishit si synim. Një ndryshim adrese nuk i ul kërkesat për identitet, dhe një lidhje që ka sukses drejt pikës së gabuar është më e keqe se një që dështon. Manuali i OpenVPN 2.6 rendit të katër opsionet me shtrirjen e tyre, dhe ky është lista e kontrollit që mbahet pranë profilës.

Mbani një rrugë jashtë brezit drejt serverit përpara se të rinisni tunelin që mbart aksesin tuaj administrativ. Ai një masë parandaluese parandalon shumicën e incidenteve që prodhon ky skenar.