Emri i pikës fundore VPN kundrejt emrit të shërbimit privat: dy pronarë

Dy emra mund të përshkruajnë të njëjtën degë dhe të përgjigjen për pyetje krejtësisht të ndryshme. vpn.branch.example i tregon një pale të largët ku ta gjejë pikën fundore VPN, dhe duhet të zgjidhet para se të ekzistojë ndonjë tunel. inventory.branch.example i tregon një përdoruesi të autorizuar ku banon një aplikacion privat, dhe ka rëndësi vetëm pasi tuneli të jetë ngritur. Mirëmbajtja e njërit nuk bën asgjë për tjetrin.

Emërtojini të dy regjistrimet para se të korrigjoni ndonjërin

Shkruajini të dy bashkë me pronarët e tyre. Për pikën fundore, shënoni kush përditëson adresën publike dhe si e rifreskon klienti VPN përgjigjen e tij. Për shërbimin, shënoni kush zotëron adresën private, cila zonë e mban regjistrimin dhe cilët zgjidhës duhet të përgjigjen për të.

Ai listë i shkurtër parandalon diagnozën e gabuar më të zakonshme në këtë fushë: rinisja e një tuneli dege që funksionon për të rregulluar një regjistrim që jeton plotësisht brenda tij. Tuneli është transporti për emrin e shërbimit; nuk është autoriteti i tij.

Kur propozohet një ndryshim, pyetni cilin nga dy regjistrimet prek. Nëse askush nuk mund të përgjigjet, ndryshimi nuk është gati për planifikim.

Pika fundore duhet të zgjidhet para se të ekzistojë ndonjë tunel

Supozoni se lidhja e internetit e degës merr një adresë të re publike. Përditësuesi i pikës fundore publikon adresën e re, dhe implementimi i largët i VPN duhet të mund të lexojë përgjigjen e ndryshuar. Cilido zgjidhës që e jep atë përgjigje duhet të jetë i arritshëm pa tunel, përndryshe klienti ndjek një emër që mund ta zgjidhë vetëm pasi të jetë lidhur me atë që nuk arrin ta gjejë.

Vlen ta thuash hapur këtë varësi fillestare, sepse është e lehtë ta krijosh aksidentalisht kur të gjithë zgjidhësit e brendshëm qëndrojnë pas VPN-së. Mbani një rrugë para tunelit për kërkimin e pikës fundore, dhe konfirmoni sjelljen e rilidhjes së klientit në vend që të supozoni se një përgjigje e re merret menjëherë.

DNS dinamik ka gjithashtu kufij që përditësimi i regjistrimit nuk mund t'i kalojë. Përditësimi i një regjistrimi nuk hap asnjë port muri zjarri, nuk krijon asnjë mapim NAT dhe nuk provon identitetin e palës. Një adresë e publikuar me port të mbyllur jep një klient që zgjidh saktë dhe prapë nuk mund të lidhet me asgjë.

Së fundi, një klient në punë mund të vazhdojë të përdorë një pikë fundore të ruajtur në cache derisa të rilidhet. Ndani publikimin, cache-in dhe politikën e rilidhjes në shënimet tuaja, që një palë e vjetruar të mos ngatërrohet me një përditësues të prishur.

Emri i shërbimit përshkruan ku banon aplikacioni

Tani supozoni se tuneli mbetet i shëndoshë, por serveri i inventarit kalon nga 172.26.14.20 në 172.26.14.35. Regjistrimi publik i pikës fundore nuk preket, ndërsa regjistrimi privat i shërbimit duhet të ndryshojë. Përdorimi i një adrese të rezervuar për atë shërbim, ose një caktimi statik, e bën këtë më të rrallë; një rrugë e autorizuar përditësimi trajton rastet kur kjo është e qëllimshme.

Këtu ngatërrohen dy mekanizma përditësimi. RFC 2136 përcakton një protokoll për të shtuar dhe fshirë regjistrime DNS në një zonë, ndërsa një ofrues komercial i DNS dinamik mund të ekspozojë një API HTTP krejtësisht tjetër për një qëllim tjetër. Përdorimi i njërit nuk nënkupton se tjetri ekziston në mjedisin tuaj. Kontrolloni cilin mekanizëm zona juaj pranon vërtet, para se të shkruani një përditësues kundër tij.

Një përgjigje private e saktë është vetëm kushti i parë. Që një thirrës i largët ta përdorë, klienti ka nevojë për një zgjidhës që mban zonën private, një politikë që lejon pyetjet drejt atij zgjidhësi, dhe përcjellje për adresën që kthehet. Një emër që zgjidhet në një adresë që klienti nuk mund ta arrijë prodhon një afat të skaduar që duket si defekt serveri.

Testojini dy rrugët veçmas

Kontrolloni pikën fundore nga jashtë tunelit dhe shërbimin nga brenda tij, dhe mbani rezultatet si dy fakte të pavarura:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Nëse pyetja e parë dështon, problemi është publikimi publik ose rruga e zgjidhjes para tunelit, dhe asnjë ndryshim i brendshëm nuk ndihmon. Nëse e dyta kthen një adresë por e treta nuk tregon asnjë rrugë përmes tunelit, shtresa DNS është në rregull dhe politika e përcjelljes nuk është.

Ekzekutoni çiftin pas çdo ndryshimi adrese, dhe shënoni cili regjistrim lëvizi. Një dorëzim që thotë vetëm «DNS u përditësua» lë inxhinierin e radhës të hamendësojë cili nga dy ciklet e jetës vërtet u ekzekutua.