VPN-i lõpp-punkti nimi versus privaatteenuse nimi: kaks omanikku

Kaks nime võivad kirjeldada sama haru ja vastata täiesti erinevatele küsimustele. vpn.branch.example ütleb kaugemale partnerile, kust VPN-i lõpp-punkti leida, ja see tuleb lahendada enne, kui ükskõik milline tunnel olemas on. inventory.branch.example ütleb volitatud kasutajale, kus privaatne rakendus asub, ja see loeb alles siis, kui tunnel on üleval. Ühe hooldamine ei tee teise jaoks midagi.

Nimeta mõlemad kirjed enne, kui kumbagi neist siluma hakkad

Kirjuta mõlemad üles koos nende omanikega. Lõpp-punkti puhul pane kirja, kes uuendab avalikku aadressi ja kuidas VPN-i klient oma vastust värskendab. Teenuse puhul pane kirja, kellele kuulub privaatne aadress, milline tsoon kirjet hoiab ja millised resolverid peaksid selle eest vastama.

See lühike nimekiri hoiab ära selle valdkonna kõige levinuma vale diagnoosi: töötava harutunneli taaskäivitamise, et parandada kirjet, mis elab täielikult selle sees. Tunnel on teenuse nime transport, mitte selle autoriteet.

Kui muudatust pakutakse, küsi, millist kahest kirjest see puudutab. Kui keegi ei oska vastata, ei ole muudatus planeerimiseks valmis.

Lõpp-punkt tuleb lahendada enne, kui ükskõik milline tunnel olemas on

Oletame, et haru internetiühendus saab uue avaliku aadressi. Lõpp-punkti uuendaja avaldab uue aadressi ja kaugel asuv VPN-i teostus peab suutma muudetud vastust lugeda. Ükskõik milline resolver selle vastuse annab, peab see olema kättesaadav ilma tunnelita, muidu ajab klient taga nime, mida ta saab lahendada alles pärast sellega ühenduse loomist, mida ta ei leia.

See alglaadimissõltuvus tasub selgelt välja öelda, sest seda on lihtne kogemata tekitada, kui kõik sisemised resolverid asuvad VPN-i taga. Hoia lõpp-punkti otsingu jaoks tunnelieelset teed ja kinnita kliendi uuesti ühendamise käitumine, selle asemel et eeldada, et uus vastus võetakse kohe vastu.

Dünaamilisel DNS-il on ka piirid, millest kirje uuendamine üle minna ei saa. Kirje uuendamine ei ava ühtegi tulemüüriporti, ei loo NAT-i vastendust ega tõesta partneri identiteeti. Avaldatud aadress suletud pordiga annab kliendi, mis lahendab õigesti ja ei saa ikkagi millegagi ühendust.

Lõpuks võib töötav klient jätkata vahemällu salvestatud lõpp-punkti kasutamist, kuni ta uuesti ühendub. Eralda märkmetes avaldamine, vahemälu ja uuesti ühendamise poliitika, et aegunud partnerit ei aetaks segi katkise uuendajaga.

Teenuse nimi kirjeldab, kus rakendus asub

Oletame nüüd, et tunnel jääb terveks, kuid inventariserver liigub 172.26.14.20-lt 172.26.14.35-le. Avalik lõpp-punkti kirje jääb puutumata, samas kui privaatne teenusekirje peab muutuma. Selle teenuse jaoks reserveeritud aadressi või staatilise määramise kasutamine teeb selle harvemaks; volitatud uuendustee katab need korrad, kui see on kavatsetud.

Siin aetakse segi kaks uuendusmehhanismi. RFC 2136 määratleb protokolli DNS-kirjete lisamiseks ja kustutamiseks tsoonis, samas kui kommertsiaalne dünaamilise DNS-i pakkuja võib muu eesmärgi jaoks pakkuda hoopis teistsugust HTTP API-t. Ühe kasutamine ei tähenda, et teine sinu keskkonnas olemas on. Kontrolli, millist mehhanismi sinu tsoon tegelikult aktsepteerib, enne kui kirjutad selle vastu uuendaja.

Õige privaatne vastus on alles esimene tingimus. Selleks et kaugem kutsuja saaks seda kasutada, vajab klient resolverit, mis kannab privaatset tsooni, poliitikat, mis lubab sellele resolverile päringuid, ja edasisaatmist aadressile, mis tagasi tuleb. Nimi, mis lahendub aadressiks, mida klient ei saa kätte, tekitab ajutõrke, mis näeb välja nagu serveri rike.

Testi kahte teed eraldi

Kontrolli lõpp-punkti väljastpoolt tunnelit ja teenust selle seest ning hoia tulemused kahe sõltumatu faktina:

$ 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

Kui esimene päring ebaõnnestub, on probleem avalikus avaldamises või tunnelieelses lahendustees ja ükski sisemine muudatus ei aita. Kui teine tagastab aadressi, aga kolmas ei näita tunnelit läbivat marsruuti, on DNS-kiht korras ja edasisaatmispoliitika mitte.

Käivita paar pärast igat aadressimuudatust ja pane kirja, milline kirje liikus. Üleandmine, mis ütleb ainult „DNS uuendati“, jätab järgmise inseneri arvama, milline kahest elutsüklist tegelikult jooksis.