Ndryshimi i ofruesit të VPN: planifikoni emrin e hostit, jo vetëm IP-në
Një regjistrim i ri DNS nuk i lëviz sesionet ekzistuese. Planifikoni kush e kontrollon emrin, kur e zgjidh çdo klient dhe si do ta tërheqësh pikën fundore të vjetër.
Regjistrimi juaj DNS është i saktë, zëvendësuesi është i shëndetshëm, dhe megjithatë disa klientë kalojnë orë duke thirrur adresën e vjetër. Disa dështojnë menjëherë përballë një emri që zgjidhet dhe nuk përgjigjet kurrë. Të dy rezultatet vijnë nga një boshllëk: një emër hosti ndryshon atë që kërkon një klient, jo kur e kërkon, dhe as atë që beson kur arrin përgjigjja.
Simptoma: një regjistrim i saktë, tunele të vjetruara
Një profil që ruan një emër nuk është klient që vazhdon ta zgjidhë atë. Shumica e zgjidhin një herë, kur aplikohet konfigurimi ose kur ngrihet tuneli, dhe pastaj e ripërdorin atë adresë deri në fund të sesionit. Një TTL i gjatë sipër kësaj është arsyeja pse kalimi duhet planifikuar rreth rilidhjeve dhe jo rreth redaktimit të DNS.
Asnjëra nga të dyja sjelljet nuk është defekt, dhe pikërisht kjo e bën simptomën konfuze. Klienti punon me një përgjigje që e mori më parë, dhe asgjë në anën e serverit nuk tregon se cila ishte ajo përgjigje. Planifikoni rilidhjen brenda dritares së mirëmbajtjes dhe u tregoni përdoruesve çfarë do të shohin, ose kaloni dritaren duke u përgjigjur tiketave. Një radhë raportesh identike është rezultati i zakonshëm.
Kush e kontrollon emrin dhe çfarë verifikon klienti
Kontrolli mbi zonën vendos sa shpejt mund të lëvizë një migrim. Mbajeni regjistrimin te një regjistrues ku mund të hyni, dhe shkruani kush tjetër mund ta ndryshojë.
Besimi nuk ndjek emrin. Një klient i bazuar në TLS mund të kontrollojë identitetin e një certifikate ose një emër të fiksuar, ndërsa WireGuard vërteton çelësin publik të palës dhe e injoron plotësisht emrin e hostit. Ky ndryshim vendos nëse mjafton një redaktim DNS apo nëse çdo profil ka nevojë për një gjurmë të re. Një ndryshim regjistrimi nuk duhet të autorizojë kurrë një pikë fundore që askush nuk e ka miratuar.
Mbajeni aksesin administrativ dhe aksesin e rikuperimit larg emrit publik të klientit. Humbja e një llogarie hostimi nuk duhet t'ju kushtojë gjithashtu regjistrimin që i ridrejton klientët. Ruani rrugën e rikuperimit diku që nuk varet nga ofruesi që po lini.
Kur çdo klient e lexon përsëri emrin
Momenti i zgjidhjes është veti e secilit klient, prandaj kontrolloni implementimin që vërtet shpërndani përpara se të premtoni një dritare kalimi. wg-quick e zgjidh pikën fundore kur ngrihet ndërfaqja dhe e mban atë adresë derisa tuneli të riniset. Një klient OpenVPN e kërkon emrin kur lidhet, dhe nëse shikon përsëri në rilidhje varet nga opsionet e tij.
| Client | When it resolves | What it verifies |
|---|---|---|
| wg-quick | At interface start, cached for the session | Peer public key, not the name |
| OpenVPN 2.6 | On connect, possibly again on reconnect | Certificate identity or pinned name |
| Mobile clients | May hold the answer across sleep or a network change | Platform trust store, same certificates |
Klientët celularë janë surpriza e zakonshme, sepse mund të mbajnë një adresë të zgjidhur gjatë gjumit ose një ndryshimi rrjeti. Publikoni regjistrime A dhe AAAA vetëm nëse zëvendësuesi përgjigjet në të dyja familjet. Një adresë që përgjigjet në një familje nuk provon asgjë për tjetrën, dhe një regjistrim AAAA i vdekur shton një afat kohor për çdo provë. Dokumentoni sjelljen e zgjidhjes për çdo klient që mbështesni, pastaj testoni në pajisjet që njerëzit përdorin vërtet.
Rilidhja është një veprim i përdoruesit në shumicën e klientëve, dhe serveri nuk mund ta imponojë. Vendoseni atë hap në shënimin e mirëmbajtjes, me një rresht për atë që do të shohë përdoruesi kur të ndodhë.
Kaloni mbi bazën e provave, pastaj tërhiqni pikën fundore të vjetër
Përpara kalimit, provoni çdo shtresë te zëvendësuesi: dëgjuesi përgjigjet, firewalls e lejon portin, rrugët kthehen si duhet, emri zgjidhet në adresën e re, dhe një identitet i njohur pranohet. Një dëgjues që pranon një lidhje nuk është i njëjtë me atë që përfundon një shtrëngim duarsh, prandaj testoni shtrëngimin e duarve dhe jo portin. Mbajeni listën aktuale të shfuqizimit pranë konfigurimit, sepse një kopje rezervë e rikthyer rikrijon listën e palëve ashtu siç ishte dhe do të rihapte aksesin që e kishit mbyllur tashmë. Shënoni me cilin identitet testuat, sepse «funksionon» nuk është provë që dikush mund ta përsërisë.
getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes
Gjatë kalimit, vëzhgoni përpjekjet për lidhje në të dyja pikat fundore për të njëjtin identitet. Një klient që ende vërtetohet kundrejt adresës së vjetër është një profil ose një përgjigje e ruajtur në cache që nuk u zhvendos kurrë. Tërhiqni pikën fundore të vjetër sipas një plani me datë, sepse dy shërbime që pranojnë një identitet lënë dy dyer hapur.
Testi i kalimit është një sesion aplikacioni përmes pikës fundore të re, jo një ping. Sapo ai sesion të funksionojë dhe pika fundore e vjetër të mos regjistrojë asnjë përpjekje të autorizuar gjatë një cikli të plotë rilidhjeje, zhvendosja ka përfunduar.