Název koncového bodu VPN versus název privátní služby: dva vlastníci

Dvě jména mohou popisovat stejnou pobočku a odpovídat na zcela různé otázky. vpn.branch.example říká vzdálenému protějšku, kde najít koncový bod VPN, a musí se přeložit dřív, než existuje jakýkoli tunel. inventory.branch.example říká oprávněnému uživateli, kde žije privátní aplikace, a záleží na něm až ve chvíli, kdy je tunel zvednutý. Údržba jednoho pro druhý nic nedělá.

Pojmenujte oba záznamy, než začnete kterýkoli ladit

Zapište oba i s jejich vlastníky. U koncového bodu zaznamenejte, kdo aktualizuje veřejnou adresu a jak klient VPN obnovuje svou odpověď. U služby zaznamenejte, kdo vlastní privátní adresu, která zóna záznam drží a které překladače za něj mají odpovídat.

Tento krátký seznam brání nejčastější chybné diagnóze v této oblasti: restartovat fungující pobočkový tunel, aby se opravil záznam, který žije zcela uvnitř něj. Tunel je přenosová cesta pro jméno služby; není jeho autoritou.

Když se navrhne změna, zeptejte se, kterého ze dvou záznamů se týká. Pokud to nikdo nedokáže odpovědět, změna není připravena k naplánování.

Koncový bod se musí přeložit dřív, než existuje jakýkoli tunel

Předpokládejme, že internetové připojení pobočky dostane novou veřejnou adresu. Aktualizátor koncového bodu zveřejní novou adresu a vzdálená implementace VPN musí být schopna přečíst změněnou odpověď. Kterýkoli překladač tuto odpověď poskytuje, musí být dostupný bez tunelu, jinak klient honí jméno, které dokáže přeložit až poté, co se připojí k věci, kterou nemůže najít.

Tato závislost na prvotním nastartování stojí za to říct přímo, protože se snadno vytvoří nedopatřením, když všechny interní překladače sedí za VPN. Udržujte cestu před tunelem pro vyhledání koncového bodu a potvrďte chování klienta při opětovném připojení, místo abyste předpokládali, že nová odpověď se zachytí okamžitě.

Dynamický DNS má také meze, které aktualizace záznamu nemůže překročit. Aktualizace záznamu neotevře žádný port firewallu, nevytvoří mapování NAT a neprokáže identitu protějšku. Zveřejněná adresa se zavřeným portem dává klienta, který překládá správně a přesto se k ničemu nedokáže připojit.

Konečně, běžící klient může dál používat kešovaný koncový bod, dokud se znovu nepřipojí. Oddělte v poznámkách zveřejnění, keš a zásady opětovného připojení, aby se zastaralý protějšek nepletl s rozbitým aktualizátorem.

Jméno služby popisuje, kde aplikace žije

Nyní předpokládejme, že tunel zůstává zdravý, ale inventární server se přesune z 172.26.14.20 na 172.26.14.35. Veřejný záznam koncového bodu to neovlivní, zatímco privátní záznam služby se musí změnit. Použití adresy vyhrazené pro tuto službu nebo statického přiřazení to činí vzácnějším; oprávněná cesta aktualizace zvládá případy, kdy je to zamýšleno.

Zde se slévají dva mechanismy aktualizace. RFC 2136 definuje protokol pro přidávání a mazání záznamů DNS v zóně, zatímco komerční poskytovatel dynamického DNS může vystavit zcela jiné HTTP API pro jiný účel. Použití jednoho neznamená, že druhé ve vašem prostředí existuje. Ověřte, který mechanismus vaše zóna skutečně přijímá, než proti němu napíšete aktualizátor.

Správná privátní odpověď je jen první podmínka. Aby ji vzdálený volající mohl použít, klient potřebuje překladač, který nese privátní zónu, zásady, které povolují dotazy na tento překladač, a předávání pro adresu, která se vrací. Jméno, které se přeloží na adresu, na niž se klient nedostane, vytváří časový limit, jenž vypadá jako porucha serveru.

Testujte obě cesty odděleně

Zkontrolujte koncový bod zvenku tunelu a službu zevnitř a výsledky uchovejte jako dvě nezávislá fakta:

$ 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

Pokud první dotaz selže, problém je ve veřejném zveřejnění nebo v cestě překladu před tunelem a žádná interní změna nepomůže. Pokud druhý vrátí adresu, ale třetí neukáže trasu skrz tunel, vrstva DNS je v pořádku a zásady předávání nejsou.

Spouštějte dvojici po každé změně adresy a poznamenejte, který záznam se pohnul. Předání, které říká jen „DNS bylo aktualizováno“, nechává dalšího inženýra hádat, který ze dvou životních cyklů skutečně proběhl.