Kaks VPN-i, üks resolver: võidab see, kes kirjutas viimasena

Ühendatud on kaks VPN-klienti, üks töö ja teine laborivõrgu jaoks, ning sisemised nimed lahendatakse ainult selle kliendi jaoks, kes ühendus viimasena. See muster näeb välja nagu viga ühes kliendis. Tavaliselt on see prognoositav tulemus kahest programmist, mis kirjutavad sama resolveri konfiguratsiooni ilma kokkuleppeta, kellele milline nimi kuulub.

Müüt: kõige uuem VPN omab DNS-i

Puudub üldreegel, et võidab kõige hiljutisem ühendus. Mis juhtub, sõltub platvormi mehhanismist ja sellest, kuidas iga klient seda kirjutab. Klient, kes asendab resolveri faili, annab ühe tulemuse; klient, kes lisab lingi kohta domeeni, annab teise; klient, kes ei tee midagi, jätab varasema oleku puutumata.

Seega on vaadeldud käitumine kahe implementatsiooni omadus, mitte dokumenteeritud prioriteet. Ainult käivitamise järjekorrast järeldamine on mõnikord õige ja mõnikord ekslik viisil, mida on raske korrata. Kirjutage vastendus üles. Disain, mis elab kahes kliendis, ei ole disain.

Seostage nimeruumid resolveritega

Loetlege privaatsed sufiksid ja resolver, mida iga võrk nõuab, seejärel otsustage, kuhu avalikud nimed peaksid minema. See loend on disain. Ilma selleta teevad kliendid otsuse kogemata.

Platvorm, mis toetab lingipõhist DNS-i või marsruutimisdomeene, saab jaotuse teadlikult väljendada: üks domeen läheb ühele lingile, teine domeen teisele ja kõik muu järgib selgesõnalist vaikeväärtust. Kaks lamedat skripti, mis kirjutavad sama faili üle, ei suuda seda disaini säilitada, sest kumbki usub, et omab kogu konfiguratsiooni.

Windowsis saab nimelahenduse poliitikatabel suunata sufikseid kindlatele serveritele ja VPN-klient võib sinna reegleid paigaldada. Kontrollige poliitikat, mitte adapterite loendit, sest nime ei lahenda adapterite loend.

Hoidke alglaadimistee

Iga klient peab leidma oma lõpp-punkti enne, kui saab kasutada teenust, mida see lõpp-punkt pakub. Kui lõpp-punkti hostinime saab lahendada ainult tunneli kaudu ja tunnel vajab lahendatud hostinime, on teil ringikujuline sõltuvus, mis ilmneb ühenduse ajalõpuna. Hoidke üks alglaadimistee mõlemast tunnelist väljaspool. See ei maksa midagi kuni päevani, mil see ühenduse päästab.

Vaadake teed iga resolverini, mitte ainult selle jaoks konfigureeritud nime. Resolver, mis on kättesaadav ainult teise tunneli kaudu, käitub nagu puuduv, ja sümptom on ajalõpp, mitte marsruutimisviga.

Kattuvad aadressid ei ole DNS-i probleem

Kahte privaatvõrku, mis kasutavad sama aadressivahemikku, ei saa DNS-i järjekorraga parandada. Kui mõlemad tunnelid nõuavad 10.0.0.0/8, osutab õigesti lahendatud nimi ikkagi aadressile, kuhu host ei saa õigesse tunnelisse marsruutida. See nõuab lahendust aadressi tasandil, näiteks erinevad vahemikud, nimeruum või tõlkimine, mitte veel üks resolveri seade. Selle varajane otsustamine hoiab ära pika ümbersõidu DNS-i konfiguratsiooni kaudu, mis ei oleks kunagi töötanud.

Võrrelge mõlema tunneli aadressimääranguid enne, kui süüdistate nimelahendust. Kui mõlemad pooled suruvad sama prefiksit, hoiab host selle jaoks ühte marsruuti, ja teise tunneli kaudu lahendatud nimi maandub ikkagi aadressile, mida omab esimene tunnel. Erinevad vahemikud, võrgu kohta nimeruum või tõlkimine on parandused; pärast iga kliendi ühendamist kinnitage, et marsruutimistabel näitab kavatsetud teed.

Tõestage seda päris rakendustega

Valige kaks hosti, mis eksisteerivad ainult oma nimeruumis, ja üks avalik nimi, seejärel lahendage igaüks selle kliendi kaudu, kes peaks seda omama. Oodatud resolveri õige vastus ei tõesta, et rakendus jõuab hostini, sest tee sellele aadressile võib ikkagi nurjuda. Pärast iga päringut tehke ühendustest programmist, mida kasutaja tegelikult käivitab.

Kliendil, kellel on oma krüpteeritud DNS-i valik, võib minna mööda poliitikast, mille just kontrollisite, seega kontrollige seda seadet ülevaatuse osana. Seejärel ühendage mõlemad kliendid uuesti järjekorras, mida tarnija toetab, ja korrake päringuid; kui vastused vahetuvad järjekorra muutumisel, omab konkureeriv kirjutaja endiselt osa konfiguratsioonist. Enne millegi muutmist tehke kindlaks, milline komponent reegli paigaldab - klient, operatsioonisüsteemi profiil või haldusagent. Kirjutage üles järjekord ja omanikud, et järgmine inimene ei peaks neid uuesti avastama.