Ime končne točke VPN proti imenu zasebne storitve: dva lastnika

Dve imeni lahko opisujeta isto podružnico in odgovarjata na povsem različna vprašanja. vpn.branch.example pove oddaljenemu partnerju, kje najti končno točko VPN, in mora biti razrešeno preden obstaja kakršenkoli tunel. inventory.branch.example pove pooblaščenemu uporabniku, kje živi zasebna aplikacija, in je pomembno šele, ko je tunel postavljen. Vzdrževanje enega ne naredi nič za drugo.

Poimenujte oba zapisa, preden začnete razhroščevati katerega koli

Zapišite oba skupaj z njunimi lastniki. Pri končni točki zabeležite, kdo posodablja javni naslov in kako odjemalec VPN osveži svoj odgovor. Pri storitvi zabeležite, kdo ima v lasti zasebni naslov, katera cona drži zapis in kateri razreševalniki naj odgovarjajo zanj.

Ta kratek seznam preprečuje najpogostejšo napačno diagnozo na tem področju: ponovni zagon delujočega tunela podružnice, da bi popravili zapis, ki živi v celoti znotraj njega. Tunel je transport za ime storitve; ni njena avtoriteta.

Ko je predlagana sprememba, vprašajte, katerega od dveh zapisov se dotika. Če nihče ne more odgovoriti, sprememba ni pripravljena za načrtovanje.

Končna točka mora biti razrešena preden obstaja kakršenkoli tunel

Recimo, da internetna povezava podružnice prejme nov javni naslov. Posodabljalnik končne točke objavi novi naslov, oddaljena izvedba VPN pa mora znati prebrati spremenjeni odgovor. Kateri koli razreševalnik ponuja ta odgovor, mora biti dosegljiv brez tunela, sicer odjemalec lovi ime, ki ga lahko razreši šele potem, ko se poveže s tem, česar ne najde.

To odvisnost od zagona velja povedati naravnost, ker jo je zlahka ustvariti po nesreči, ko vsi notranji razreševalniki sedijo za VPN. Ohranite pot pred tunelom za iskanje končne točke in potrdite vedenje odjemalca pri ponovni povezavi, namesto da predpostavljate, da se novi odgovor prevzame takoj.

Tudi dinamični DNS ima meje, ki jih posodobitev zapisa ne more prestopiti. Posodobitev zapisa ne odpre nobenih vrat požarnega zidu, ne ustvari preslikave NAT in ne dokaže identitete partnerja. Objavljen naslov z zaprtimi vrati da odjemalca, ki pravilno razreši in se vseeno ne more povezati z ničimer.

Nazadnje, delujoči odjemalec lahko še naprej uporablja predpomnjeno končno točko, dokler se ne poveže znova. V svojih zapiskih ločite objavo, predpomnilnik in politiko ponovnega povezovanja, da zastarelega partnerja ne zamenjate s pokvarjenim posodabljalnikom.

Ime storitve opisuje, kje živi aplikacija

Zdaj recimo, da tunel ostane zdrav, vendar se inventarni strežnik premakne z 172.26.14.20 na 172.26.14.35. Javni zapis končne točke ni prizadet, medtem ko se mora zasebni zapis storitve spremeniti. Uporaba naslova, rezerviranega za to storitev, ali statične dodelitve naredi to redkejše; pooblaščena pot posodobitve obravnava primere, ko je to namerno.

Tu se mešata dva mehanizma posodabljanja. RFC 2136 opredeljuje protokol za dodajanje in brisanje zapisov DNS v coni, medtem ko lahko komercialni ponudnik dinamičnega DNS izpostavi povsem drugo HTTP API za drug namen. Uporaba enega ne pomeni, da drugo obstaja v vašem okolju. Preverite, kateri mehanizem vaša cona dejansko sprejema, preden napišete posodabljalnik zanj.

Pravilen zasebni odgovor je le prvi pogoj. Da bi ga oddaljeni klicatelj lahko uporabil, odjemalec potrebuje razreševalnik, ki nosi zasebno cono, politiko, ki dovoljuje poizvedbe do tega razreševalnika, in posredovanje za naslov, ki se vrne. Ime, ki se razreši v naslov, ki ga odjemalec ne more doseči, ustvari časovno omejitev, ki je videti kot okvara strežnika.

Preizkusite obe poti ločeno

Preverite končno točko od zunaj tunela in storitev od znotraj, rezultate pa hranite kot dve neodvisni dejstvi:

$ 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

Če prva poizvedba ne uspe, je težava v javni objavi ali v poti razreševanja pred tunelom, in nobena notranja sprememba ne bo pomagala. Če druga vrne naslov, tretja pa ne pokaže poti skozi tunel, je plast DNS v redu, politika posredovanja pa ne.

Zaženite par po vsaki spremembi naslova in zabeležite, kateri zapis se je premaknil. Predaja, ki pravi le »DNS je bil posodobljen«, pusti naslednjemu inženirju ugibanje, kateri od dveh življenjskih ciklov je v resnici potekal.