Nomo de VPN-fina punkto kontraŭ nomo de privata servo: du posedantoj

Du nomoj povas priskribi la saman filion kaj respondi al tute malsamaj demandoj. vpn.branch.example diras al malproksima partnero, kie troviĝas la VPN-fina punkto, kaj ĝi devas esti solvita antaŭ ol ekzistas iu ajn tunelo. inventory.branch.example diras al rajtigita uzanto, kie loĝas privata aplikaĵo, kaj ĝi gravas nur post kiam la tunelo funkcias. Prizorgi unu el ili faras nenion por la alia.

Nomu la du rikordojn antaŭ ol vi sencimigi iun ajn el ili

Skribu ambaŭ kune kun iliaj posedantoj. Por la fina punkto, notu, kiu ĝisdatigas la publikan adreson kaj kiel la VPN-kliento refreŝigas sian respondon. Por la servo, notu, kiu posedas la privatan adreson, kiu zono tenas la rikordon kaj kiuj solviloj devus respondi pri ĝi.

Tiu mallonga listo malhelpas la plej oftan eraran diagnozon en ĉi tiu kampo: restartigi funkciantan filian tunnelon por ripari rikordon, kiu tute loĝas interne de ĝi. La tunelo estas la transporto por la serva nomo, ne ĝia aŭtoritato.

Kiam ŝanĝo estas proponita, demandu, kiun el la du rikordoj ĝi tuŝas. Se neniu povas respondi, la ŝanĝo ne pretas por planado.

La fina punkto devas esti solvita antaŭ ol ekzistas iu ajn tunelo

Supozu, ke la interreta konekto de la filio ricevas novan publikan adreson. La ĝisdatigilo de la fina punkto publikigas la novan adreson, kaj la malproksima VPN-realigo devas povi legi la ŝanĝitan respondon. Kiun ajn solvilon provizas tiun respondon, ĝi devas esti atingebla sen la tunelo, alie la kliento ĉasas nomon, kiun ĝi povas solvi nur post kiam ĝi konektiĝis al la afero, kiun ĝi ne povas trovi.

Tiu dependeco de komenca ŝarĝo indas esti dirita malkaŝe, ĉar ĝi facile kreiĝas hazarde, kiam ĉiuj internaj solviloj sidas malantaŭ la VPN. Tenu vojon antaŭ la tunelo por la serĉo de la fina punkto kaj konfirmu la rekonektan konduton de la kliento anstataŭ supozi, ke nova respondo estas prenita tuj.

Dinamika DNS ankaŭ havas limojn, kiujn la rikorda ĝisdatigo ne povas transiri. Ĝisdatigi rikordon malfermas neniun fajroŝirman pordon, kreas neniun NAT-mapadon kaj pruvas neniun partneran identecon. Publikigita adreso kun fermita pordo donas klienton, kiu solvas ĝuste kaj tamen ne povas konektiĝi al io ajn.

Fine, funkcianta kliento povas daŭre uzi kaŝmemoran finan punkton ĝis ĝi rekonektiĝos. Apartigu la publikigon, la kaŝmemoron kaj la rekonektan politikon en viaj notoj, por ke eksmoda partnero ne estu konfuzita kun difektita ĝisdatigilo.

La serva nomo priskribas, kie loĝas la aplikaĵo

Nun supozu, ke la tunelo restas sana sed la inventara servilo moviĝas de 172.26.14.20 al 172.26.14.35. La publika finpunkta rikordo ne estas tuŝita, dum la privata serva rikordo devas ŝanĝiĝi. Uzi adreson rezervitan por tiu servo aŭ statikan asignadon maloftegas tion; rajtigita ĝisdatiga vojo traktas la fojojn, kiam tio estas intencita.

Ĉi tie du ĝisdatigaj mekanismoj estas konfuzitaj. RFC 2136 difinas protokolon por aldoni kaj forigi DNS-rikordojn en zono, dum komerca provizanto de dinamika DNS povas elmontri tute alian HTTP-API por alia celo. Uzi unu ne implicas, ke la alia ekzistas en via medio. Kontrolu, kiun mekanismon via zono efektive akceptas, antaŭ ol vi skribos ĝisdatigilon kontraŭ ĝi.

Ĝusta privata respondo estas nur la unua kondiĉo. Por ke malproksima vokanto povu uzi ĝin, la kliento bezonas solvilon, kiu portas la privatan zonon, politikon, kiu permesas demandojn al tiu solvilo, kaj plusendadon por la adreso, kiu revenas. Nomo, kiu solviĝas al adreso, kiun la kliento ne povas atingi, produktas tempolimon, kiu aspektas kiel servila paneo.

Testu la du vojojn aparte

Kontrolu la finan punkton de ekster la tunelo kaj la servon de interne, kaj tenu la rezultojn kiel du sendependajn faktojn:

$ 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

Se la unua demando malsukcesas, la problemo estas publika publikigo aŭ la solva vojo antaŭ la tunelo, kaj neniu interna ŝanĝo helpos. Se la dua redonas adreson sed la tria montras neniun itineron tra la tunelo, la DNS-tavolo estas en ordo kaj la plusenda politiko ne.

Rulu la paron post ĉiu adresa ŝanĝo kaj notu, kiu rikordo moviĝis. Transdono, kiu diras nur «DNS estis ĝisdatigita», lasas la sekvan inĝenieron diveni, kiu el la du vivcikloj efektive kuris.