Naziv VPN završne točke nasuprot nazivu privatne usluge: dva vlasnika
Javna VPN završna točka i naziv privatne usluge mijenjaju se iz različitih razloga. Dajte svakome svog vlasnika ažuriranja, put rezolvera i provjeru dostupnosti.
Dva naziva mogu opisivati istu podružnicu i odgovarati na potpuno različita pitanja. vpn.branch.example govori udaljenom partneru gdje pronaći VPN krajnju tačku i mora se razriješiti prije nego što ikakav tunel postoji. inventory.branch.example govori ovlaštenom korisniku gdje živi privatna aplikacija i važan je tek kada je tunel podignut. Održavanje jednog ne čini ništa za drugi.
Imenujte dva zapisa prije nego što bilo koji od njih počnete otklanjati
Zapišite oba zajedno s njihovim vlasnicima. Za krajnju tačku zabilježite ko ažurira javnu adresu i kako VPN klijent osvježava svoj odgovor. Za uslugu zabilježite ko posjeduje privatnu adresu, koja zona drži zapis i koji rezolveri treba da odgovaraju za njega.
Ta kratka lista sprječava najčešću pogrešnu dijagnozu u ovom području: ponovno pokretanje ispravnog tunela podružnice da bi se popravio zapis koji u potpunosti živi unutar njega. Tunel je transport za naziv usluge; on nije njegov izvor istine.
Kada se predloži promjena, pitajte kojeg od dva zapisa se tiče. Ako niko ne može odgovoriti, promjena nije spremna za planiranje.
Krajnja tačka se mora razriješiti prije nego što ikakav tunel postoji
Pretpostavite da internet veza podružnice dobije novu javnu adresu. Ažurirač krajnje tačke objavljuje novu adresu, a udaljena VPN implementacija mora moći pročitati promijenjeni odgovor. Koji god rezolver daje taj odgovor mora biti dostupan bez tunela, inače klijent juri naziv koji može razriješiti samo nakon što se poveže s onim što ne može pronaći.
Ta zavisnost od početnog podizanja vrijedi jasno reći, jer ju je lako slučajno stvoriti kada svi unutrašnji rezolveri stoje iza VPN-a. Zadržite put prije tunela za traženje krajnje tačke i potvrdite ponašanje klijenta pri ponovnom povezivanju umjesto da pretpostavljate da se novi odgovor preuzima odmah.
Dinamički DNS takođe ima granice koje ažuriranje zapisa ne može preći. Ažuriranje zapisa ne otvara nijedan port vatrozida, ne stvara NAT mapiranje i ne dokazuje identitet partnera. Objavljena adresa sa zatvorenim portom daje klijenta koji ispravno razrješava i ipak se ne može povezati ni s čim.
Konačno, pokrenuti klijent može nastaviti koristiti keširanu krajnju tačku dok se ne poveže ponovo. Odvojite objavljivanje, keš i politiku ponovnog povezivanja u svojim bilješkama, da se zastario partner ne zamijeni s pokvarenim ažuriračem.
Naziv usluge opisuje gdje živi aplikacija
Sada pretpostavite da tunel ostaje zdrav, ali inventarni server se pomjera s 172.26.14.20 na 172.26.14.35. Javni zapis krajnje tačke nije pogođen, dok se privatni zapis usluge mora promijeniti. Korištenje adrese rezervisane za tu uslugu ili statičke dodjele čini ovo rjeđim; ovlašteni put ažuriranja rješava slučajeve kada je to predviđeno.
Ovdje se brkaju dva mehanizma ažuriranja. RFC 2136 definiše protokol za dodavanje i brisanje DNS zapisa u zoni, dok komercijalni pružalac dinamičkog DNS-a može izložiti potpuno drugačiji HTTP API za drugu svrhu. Korištenje jednog ne znači da drugi postoji u vašem okruženju. Provjerite koji mehanizam vaša zona zaista prihvata prije nego što napišete ažurirač prema njemu.
Ispravan privatni odgovor je samo prvi uslov. Da bi ga udaljeni pozivalac koristio, klijentu treba rezolver koji nosi privatnu zonu, politika koja dozvoljava upite tom rezolveru i prosljeđivanje za adresu koja se vraća. Naziv koji se razrješava na adresu koju klijent ne može dosegnuti proizvodi istek koji izgleda kao kvar servera.
Testirajte dva puta odvojeno
Provjerite krajnju tačku izvan tunela i uslugu unutar njega, a rezultate čuvajte kao dvije nezavisne činjenice:
$ 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
Ako prvi upit ne uspije, problem je u javnom objavljivanju ili u putu razrješavanja prije tunela i nikakva unutrašnja promjena neće pomoći. Ako drugi vrati adresu ali treći ne pokaže rutu kroz tunel, DNS sloj je u redu, a politika prosljeđivanja nije.
Pokrenite par nakon svake promjene adrese i zabilježite koji se zapis pomjerio. Primopredaja koja kaže samo „DNS je ažuriran“ ostavlja sljedećeg inženjera da nagađa koji je od dva životna ciklusa zaista prošao.