VPN galapunkta nosaukums pret privāta servisa nosaukumu: divi īpašnieki

Divi nosaukumi var aprakstīt vienu un to pašu filiāli un atbildēt uz pilnīgi atšķirīgiem jautājumiem. vpn.branch.example pasaka attālam partnerim, kur atrast VPN galapunktu, un tas ir jāatrisina pirms jebkura tuneļa pastāvēšanas. inventory.branch.example pasaka pilnvarotam lietotājam, kur dzīvo privāta lietotne, un tam ir nozīme tikai tad, kad tunelis jau ir uzcelts. Viena uzturēšana neko nedara otram.

Nosauciet abus ierakstus pirms jebkura no tiem atkļūdošanas

Pierakstiet abus kopā ar to īpašniekiem. Galapunktam pierakstiet, kas atjaunina publisko adresi un kā VPN klients atsvaidzina savu atbildi. Servisam pierakstiet, kam pieder privātā adrese, kura zona tur ierakstu un kuri atrisinātāji par to ir jāatbild.

Šis īsais saraksts novērš visbiežāk sastopamo nepareizo diagnozi šajā jomā: strādājoša filiāles tuneļa pārstartēšanu, lai salabotu ierakstu, kas pilnībā dzīvo tā iekšienē. Tunelis ir servisa nosaukuma transports; tas nav tā autoritāte.

Kad tiek piedāvātas izmaiņas, pajautājiet, kuru no diviem ierakstiem tās skar. Ja neviens nevar atbildēt, izmaiņas nav gatavas plānošanai.

Galapunktam ir jābūt atrisinātam pirms jebkura tuneļa pastāvēšanas

Pieņemsim, ka filiāles interneta savienojums saņem jaunu publisko adresi. Galapunkta atjauninātājs publicē jauno adresi, un attālajai VPN implementācijai ir jāspēj nolasīt mainīto atbildi. Kurš atrisinātājs arī sniegtu šo atbildi, tam jābūt sasniedzamam bez tuneļa, citādi klients dzenas pēc nosaukuma, kuru tas var atrisināt tikai pēc tam, kad ir pieslēdzies tam, ko tas nevar atrast.

Šo sāknēšanas atkarību ir vērts pateikt tieši, jo to ir viegli izveidot nejauši, kad visi iekšējie atrisinātāji atrodas aiz VPN. Saglabājiet ceļu pirms tuneļa galapunkta meklēšanai un apstipriniet klienta atkārtotas pieslēgšanās uzvedību, nevis pieņemiet, ka jaunā atbilde tiek uzņemta uzreiz.

Dinamiskajam DNS arī ir robežas, ko ieraksta atjaunināšana nevar pārsniegt. Ieraksta atjaunināšana neatver ugunsmūra portu, neveido NAT kartējumu un nepierāda partnera identitāti. Publicēta adrese ar slēgtu portu dod klientu, kas atrisina pareizi un tomēr nevar nekam pieslēgties.

Visbeidzot, strādājošs klients var turpināt izmantot kešatmiņā saglabātu galapunktu, līdz tas atkārtoti pieslēdzas. Savos pierakstos atdaliet publicēšanu, kešatmiņu un atkārtotas pieslēgšanās politiku, lai novecojis partneris netiktu sajaukts ar bojātu atjauninātāju.

Servisa nosaukums apraksta, kur dzīvo lietotne

Tagad pieņemsim, ka tunelis paliek vesels, bet inventarizācijas serveris pārceļas no 172.26.14.20 uz 172.26.14.35. Publiskais galapunkta ieraksts nav ietekmēts, savukārt privātais servisa ieraksts ir jāmaina. Šim servisam rezervētas adreses vai statiskas piešķiršanas izmantošana padara to retāku; pilnvarots atjaunināšanas ceļš apstrādā gadījumus, kad tas ir paredzēts.

Šeit tiek sajaukti divi atjaunināšanas mehānismi. RFC 2136 definē protokolu DNS ierakstu pievienošanai un dzēšanai zonā, kamēr komerciāls dinamiskā DNS nodrošinātājs var piedāvāt pilnīgi citu HTTP API citam mērķim. Viena izmantošana nenozīmē, ka otrs pastāv jūsu vidē. Pārbaudiet, kuru mehānismu jūsu zona patiešām pieņem, pirms rakstāt pret to atjauninātāju.

Pareiza privāta atbilde ir tikai pirmais nosacījums. Lai attāls zvanītājs to varētu izmantot, klientam nepieciešams atrisinātājs, kas nes privāto zonu, politika, kas atļauj vaicājumus šim atrisinātājam, un pāradresācija adresei, kas atgriežas. Nosaukums, kas atrisinās uz adresi, kuru klients nevar sasniegt, rada taimautu, kas izskatās pēc servera kļūmes.

Pārbaudiet abus ceļus atsevišķi

Pārbaudiet galapunktu ārpus tuneļa un servisu tā iekšienē, un saglabājiet rezultātus kā divus neatkarīgus faktus:

$ 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

Ja pirmais vaicājums neizdodas, problēma ir publiskajā publicēšanā vai atrisināšanas ceļā pirms tuneļa, un nekādas iekšējas izmaiņas nepalīdzēs. Ja otrais atgriež adresi, bet trešais neparāda maršrutu caur tuneli, DNS slānis ir kārtībā, bet pāradresācijas politika nav.

Palaidiet pāri pēc katras adreses maiņas un atzīmējiet, kurš ieraksts ir pārvietojies. Nodošana, kas saka tikai «DNS tika atjaunināts», atstāj nākamo inženieri minēt, kurš no diviem dzīves cikliem patiešām notika.