VPN galinio taško pavadinimas prieš privataus serviso pavadinimą: du savininkai

Du pavadinimai gali apibūdinti tą patį filialą ir atsakyti į visiškai skirtingus klausimus. vpn.branch.example pasako nuotoliniam partneriui, kur rasti VPN galinį tašką, ir jis turi būti išspręstas prieš atsirandant bet kokiam tuneliui. inventory.branch.example pasako įgaliotam naudotojui, kur gyvena privati programa, ir jis svarbus tik tada, kai tunelis jau pakeltas. Vieno priežiūra nieko nedaro kitam.

Įvardykite abu įrašus prieš derindami bet kurį iš jų

Užsirašykite abu kartu su jų savininkais. Galiniam taškui užrašykite, kas atnaujina viešą adresą ir kaip VPN klientas atnaujina savo atsakymą. Servisui užrašykite, kam priklauso privatus adresas, kuri zona laiko įrašą ir kurie sprendėjai turėtų už jį atsakyti.

Šis trumpas sąrašas užkerta kelią dažniausiai neteisingai diagnozei šioje srityje: paleisti iš naujo veikiantį filialo tunelį, kad būtų sutaisytas įrašas, kuris gyvena visiškai jo viduje. Tunelis yra serviso pavadinimo transportas; jis nėra jo valdžia.

Kai siūlomas pakeitimas, paklauskite, kurio iš dviejų įrašų jis liečia. Jei niekas negali atsakyti, pakeitimas neparuoštas planavimui.

Galinis taškas turi būti išspręstas prieš atsirandant bet kokiam tuneliui

Tarkime, filialo interneto ryšys gauna naują viešą adresą. Galinio taško atnaujintojas paskelbia naują adresą, o nuotolinė VPN realizacija turi galėti perskaityti pasikeitusį atsakymą. Kuris be sprendėjas teikia tą atsakymą, jis turi būti pasiekiamas be tunelio, kitaip klientas vejasi vardą, kurį gali išspręsti tik prisijungęs prie to, ko neranda.

Šią paleidimo priklausomybę verta pasakyti tiesiai, nes ją lengva sukurti netyčia, kai visi vidiniai sprendėjai yra už VPN. Laikykite kelią prieš tunelį galinio taško paieškai ir patvirtinkite kliento persijungimo elgseną, o ne manykite, kad naujas atsakymas paimamas iškart.

Dinaminis DNS taip pat turi ribas, kurių įrašo atnaujinimas negali peržengti. Įrašo atnaujinimas neatidaro jokio ugniasienės porto, nesukuria NAT atvaizdavimo ir neįrodo partnerio tapatybės. Paskelbtas adresas su uždaru portu duoda klientą, kuris teisingai išsprendžia ir vis tiek negali prie nieko prisijungti.

Galiausiai, veikiantis klientas gali toliau naudoti podėlyje laikomą galinį tašką, kol persijungs. Atskirkite savo užrašuose paskelbimą, podėlį ir persijungimo politiką, kad pasenęs partneris nebūtų palaikytas sugedusiu atnaujintoju.

Serviso pavadinimas apibūdina, kur gyvena programa

Dabar tarkime, kad tunelis lieka sveikas, bet inventorizacijos serveris persikelia iš 172.26.14.20 į 172.26.14.35. Viešas galinio taško įrašas nepaveiktas, o privatus serviso įrašas turi pasikeisti. Tam servisui rezervuoto adreso arba statinio priskyrimo naudojimas tai daro retesnį; įgaliotas atnaujinimo kelias tvarko atvejus, kai tai numatyta.

Čia sumaišomi du atnaujinimo mechanizmai. RFC 2136 apibrėžia protokolą DNS įrašams zonoje pridėti ir šalinti, o komercinis dinaminio DNS tiekėjas gali pasiūlyti visiškai kitą HTTP API kitam tikslui. Vieno naudojimas nereiškia, kad kitas egzistuoja jūsų aplinkoje. Patikrinkite, kurį mechanizmą jūsų zona iš tikrųjų priima, prieš rašydami jam skirtą atnaujintoją.

Teisingas privatus atsakymas yra tik pirmoji sąlyga. Kad nuotolinis skambintojas galėtų juo naudotis, klientui reikia sprendėjo, kuris neša privačią zoną, politikos, kuri leidžia užklausas tam sprendėjui, ir persiuntimo adresui, kuris grįžta. Vardas, kuris išsprendžiamas į klientui nepasiekiamą adresą, sukuria laukimo ribą, kuri atrodo kaip serverio gedimas.

Išbandykite abu kelius atskirai

Patikrinkite galinį tašką iš tunelio išorės, o servisą iš vidaus, ir laikykite rezultatus dviem nepriklausomais faktais:

$ 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

Jei pirmoji užklausa nepavyksta, problema yra viešame paskelbime arba sprendimo kelyje prieš tunelį, ir joks vidinis pakeitimas nepadės. Jei antroji grąžina adresą, bet trečioji neparodo maršruto per tunelį, DNS sluoksnis tvarkingas, o persiuntimo politika ne.

Vykdykite porą po kiekvieno adreso pakeitimo ir pažymėkite, kuris įrašas pajudėjo. Perdavimas, kuris sako tik „DNS buvo atnaujintas“, palieka kitą inžinierių spėlioti, kuris iš dviejų gyvavimo ciklų iš tikrųjų įvyko.