Názov koncového bodu VPN verzus názov súkromnej služby: dvaja vlastníci

Dva názvy môžu opisovať tú istú pobočku a odpovedať na úplne odlišné otázky. vpn.branch.example hovorí vzdialenému partnerovi, kde nájsť koncový bod VPN, a musí sa preložiť skôr, než existuje akýkoľvek tunel. inventory.branch.example hovorí autorizovanému používateľovi, kde žije súkromná aplikácia, a záleží na ňom až po zdvihnutí tunela. Údržba jedného pre druhý nič nerobí.

Pomenujte oba záznamy, skôr než začnete ktorýkoľvek ladeniť

Zapíšte oba spolu s ich vlastníkmi. Pri koncovom bode zaznamenajte, kto aktualizuje verejnú adresu a ako klient VPN obnovuje svoju odpoveď. Pri službe zaznamenajte, kto vlastní súkromnú adresu, ktorá zóna drží záznam a ktoré prekladače zaň majú odpovedať.

Tento krátky zoznam bráni najčastejšej nesprávnej diagnóze v tejto oblasti: reštartovať fungujúci pobočkový tunel, aby sa opravil záznam, ktorý žije celý v jeho vnútri. Tunel je prepravou pre názov služby, nie jej autoritou.

Keď sa navrhne zmena, spýtajte sa, ktorého z dvoch záznamov sa týka. Ak to nikto nevie odpovedať, zmena nie je pripravená na naplánovanie.

Koncový bod sa musí preložiť skôr, než existuje akýkoľvek tunel

Predpokladajme, že internetové pripojenie pobočky dostane novú verejnú adresu. Aktualizátor koncového bodu zverejní novú adresu a vzdialená implementácia VPN musí vedieť prečítať zmenenú odpoveď. Ktorýkoľvek prekladač túto odpoveď poskytuje, musí byť dostupný bez tunela, inak klient naháňa názov, ktorý dokáže preložiť až po tom, čo sa pripojí k tomu, čo nevie nájsť.

Túto závislosť od štartu stojí za to povedať priamo, pretože sa ľahko vytvorí nedopatrením, keď všetky interné prekladače sedia za VPN. Udržujte cestu pred tunelom pre vyhľadanie koncového bodu a potvrďte správanie klienta pri opätovnom pripojení namiesto predpokladu, že nová odpoveď sa zachytí okamžite.

Dynamický DNS má tiež hranice, ktoré aktualizácia záznamu nemôže prekročiť. Aktualizácia záznamu neotvorí žiadny port firewallu, nevytvorí mapovanie NAT a nepreukáže identitu partnera. Zverejnená adresa so zatvoreným portom dáva klienta, ktorý prekladá správne a napriek tomu sa nedokáže k ničomu pripojiť.

Napokon, bežiaci klient môže ďalej používať uložený koncový bod, kým sa znova nepripojí. V poznámkach oddeľte zverejnenie, vyrovnávaciu pamäť a politiku opätovného pripojenia, aby sa zastaraný partner nepomýlil s pokazeným aktualizátorom.

Názov služby opisuje, kde aplikácia žije

Teraz predpokladajme, že tunel zostáva zdravý, ale inventarizačný server sa presúva z 172.26.14.20 na 172.26.14.35. Verejný záznam koncového bodu nie je ovplyvnený, kým súkromný záznam služby sa musí zmeniť. Použitie adresy vyhradenej pre túto službu alebo statického pridelenia robí toto zriedkavejším; autorizovaná cesta aktualizácie zvládne prípady, keď je to zamýšľané.

Miešajú sa tu dva mechanizmy aktualizácie. RFC 2136 definuje protokol na pridávanie a mazanie záznamov DNS v zóne, kým komerčný poskytovateľ dynamického DNS môže vystaviť úplne iné HTTP API na iný účel. Použitie jedného neznamená, že druhé vo vašom prostredí existuje. Overte, ktorý mechanizmus vaša zóna skutočne akceptuje, skôr než proti nemu napíšete aktualizátor.

Správna súkromná odpoveď je len prvou podmienkou. Aby ju vzdialený volajúci mohol použiť, klient potrebuje prekladač, ktorý nesie súkromnú zónu, politiku, ktorá povoľuje dopyty na tento prekladač, a preposielanie pre adresu, ktorá sa vracia. Názov, ktorý sa preloží na adresu, na ktorú sa klient nedostane, vytvára časový limit, ktorý vyzerá ako porucha servera.

Otestujte obe cesty oddelene

Skontrolujte koncový bod zvonka tunela a službu zvnútra a výsledky uchovajte ako dva nezávislé fakty:

$ 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

Ak prvý dopyt zlyhá, problém je vo verejnom zverejnení alebo v ceste prekladu pred tunelom a žiadna interná zmena nepomôže. Ak druhý vráti adresu, ale tretí neukáže trasu cez tunel, vrstva DNS je v poriadku a politika preposielania nie.

Spúšťajte dvojicu po každej zmene adresy a poznamenajte, ktorý záznam sa pohol. Odovzdanie, ktoré hovorí len „DNS bolo aktualizované“, necháva ďalšieho inžiniera hádať, ktorý z dvoch životných cyklov skutočne prebehol.