Divi VPN, viens risinātājs: uzvar tas, kurš rakstīja pēdējais

Ir savienoti divi VPN klienti, viens darbam un otrs laboratorijas tīklam, un iekšējie nosaukumi tiek atrisināti tikai tam klientam, kurš pievienojās pēdējais. Šis modelis izskatās kā kļūda vienā no klientiem. Parasti tas ir paredzams divu programmu rezultāts, kas raksta vienu un to pašu risinātāja konfigurāciju bez vienošanās par to, kam pieder kurš nosaukums.

Mīts: jaunākais VPN pārvalda DNS

Nav vispārēja noteikuma, ka uzvar jaunākais savienojums. Kas notiek, ir atkarīgs no platformas mehānisma un no tā, kā katrs klients to raksta. Klients, kas aizstāj risinātāja failu, dod vienu rezultātu; klients, kas pievieno domēnu katram savienojumam, dod citu; klients, kas neko nedara, atstāj iepriekšējo stāvokli neskartu.

Tātad novērotā uzvedība ir abu implementāciju īpašība, nevis dokumentēta prioritāte. Spriedumi tikai no palaišanas secības dažkārt būs pareizi, bet dažkārt nepareizi tādos veidos, ko grūti atkārtot. Tā vietā pierakstiet kartējumu. Dizains, kas dzīvo divos klientos, nav dizains.

Kartējiet nosaukumu telpas uz risinātājiem

Uzskaitiet privātos sufiksus un risinātāju, kas nepieciešams katram tīklam, pēc tam izlemiet, kur jāiet publiskajiem nosaukumiem. Šis saraksts ir dizains. Bez tā klienti lēmumu pieņem nejauši.

Platforma, kas atbalsta DNS katram savienojumam vai maršrutēšanas domēnus, var apzināti izteikt sadalījumu: viens domēns iet uz vienu savienojumu, otrs domēns uz otru, un viss pārējais seko skaidrai noklusējuma vērtībai. Divi plakani skripti, kas pārraksta vienu un to pašu failu, nevar saglabāt šo dizainu, jo katrs uzskata, ka tam pieder visa konfigurācija.

Sistēmā Windows nosaukumu izšķirtspējas politikas tabula var novirzīt sufiksus uz konkrētiem serveriem, un VPN klients tur var instalēt noteikumus. Pārbaudiet politiku, nevis adapteru sarakstu, jo nosaukumu izšķir nevis adapteru saraksts.

Turiet sāknēšanas ceļu

Katram klientam ir jāatrod savs galapunkts, pirms tas var izmantot pakalpojumu, ko šis galapunkts nodrošina. Ja galapunkta resursdatora nosaukumu var atrisināt tikai caur tuneli, un tunelim ir vajadzīgs atrisinātais resursdatora nosaukums, jums ir cikliska atkarība, kas izpaužas kā savienojuma taimauts. Turiet vienu sāknēšanas ceļu ārpus abiem tuneļiem. Tas neko nemaksā līdz dienai, kad tas izglābj savienojumu.

Skatieties ceļu uz katru risinātāju, ne tikai tam konfigurēto nosaukumu. Risinātājs, kas sasniedzams tikai caur otru tuneli, uzvedas kā trūkstošs, un simptoms ir taimauts, nevis maršrutēšanas kļūda.

Pārklājošās adreses nav DNS problēma

Divus privātos tīklus, kas izmanto vienu un to pašu adrešu diapazonu, nevar salabot ar DNS secību. Ja abi tuneļi pieprasa 10.0.0.0/8, pareizi atrisināts nosaukums joprojām norāda uz adresi, uz kuru resursdators nevar maršrutēt pareizo tuneli. Tam nepieciešams risinājums adreses līmenī, piemēram, atšķirīgi diapazoni, nosaukumu telpa vai tulkošana, nevis vēl viens risinātāja iestatījums. Šī lēmuma pieņemšana agri novērš garu apkārtceļu caur DNS konfigurāciju, kas nekad nebūtu strādājusi.

Salīdziniet abu tuneļu adrešu piešķīrumus, pirms vainojat nosaukumu izšķirtspēju. Kad abas puses virza vienu un to pašu prefiksu, resursdators tam patur vienu maršrutu, un nosaukums, kas atrisināts caur otru tuneli, joprojām nonāk adresē, kas pieder pirmajam tunelim. Atšķirīgi diapazoni, nosaukumu telpa katram tīklam vai tulkošana ir labojumi; pēc katra klienta pievienošanās pārliecinieties, ka maršrutu tabula rāda paredzēto ceļu.

Pierādiet to ar īstām lietojumprogrammām

Izvēlieties divus resursdatorus, kas pastāv tikai savā nosaukumu telpā, un vienu publisku nosaukumu, pēc tam atrisiniet katru caur klientu, kuram tas būtu jāpieder. Pareiza atbilde no gaidītā risinātāja nepierāda, ka lietojumprogramma sasniedz resursdatoru, jo ceļš uz šo adresi joprojām var neizdoties. Pēc katra vaicājuma veiciet savienojuma testu no programmas, ko lietotājs faktiski palaidīs.

Klientam ar savu šifrēto DNS opciju var apiet politiku, kuru tikko pārbaudījāt, tāpēc pārbaudiet šo iestatījumu pārskata ietvaros. Pēc tam atkārtoti pievienojiet abus klientus tādā secībā, kādu atbalsta piegādātājs, un atkārtojiet vaicājumus; ja secības maiņas laikā atbildes samainās, konkurējošs rakstītājs joprojām pārvalda daļu konfigurācijas. Pirms kaut ko labot, noskaidrojiet, kura komponente instalē noteikumu - klients, operētājsistēmas profils vai pārvaldības aģents. Pierakstiet secību un īpašniekus, lai nākamajai personai tie nav jāatklāj no jauna.