Domajna-bazita VPN-enkursigo kontraŭ IP-itineroj: kiu taŭgas?

IP-itinero kongruas kun adresa prefikso, kaj la kerno aplikas ĝin sen pliaj demandoj. Domajna-bazita VPN-regulo kongruas kun nomo, kio signifas, ke io en la stako devas decidi, kiujn adresojn tiu nomo nun signifas, kaj teni tiun decidon ĝisdata. Tiuj estas malsamaj mekanismoj kun malsamaj fiaskomanieroj, kaj vendistoj uzas la saman vorton por ambaŭ. Kompari ilin en trajto-listoj maltrafas la aferon; komparu ilin laŭ tio, kio okazas kiam la respondo ŝanĝiĝas.

La utila divido estas inter regulo, kiu solvas, kaj regulo, kiu ne solvas.

Kun kio ĉiu regulo efektive kongruas

Prefiksa regulo kongruas kun celadresoj en enkursiga tabelo. Nenio solviĝas, nenio eksvalidiĝas, kaj la kongruo estas preciza por ĉiu pakaĵo. Domajna regulo kongruas kun peto de aplikaĵo pri nomo, kiun RFC 1034 difinas kiel arbon de etikedoj prefere ol adreson. Iuj produktoj solvas la nomon unufoje kaj instalaĵas la rezultajn adresojn kiel itinerojn, kio igas la regulon IP-regulo kun alkroĉita refreŝiga tempigilo.

Sciu, kiun el la du vi havas, antaŭ ol vi sencimigos ĝin, ĉar la fiasko aspektas tute malsame en ĉiu kazo.

Kie la domajna regulo loĝas en la stako

Se la produkto realigas domajnajn regulojn per loka prokurilo, la trafiko devas atingi tiun prokurilon, kaj aplikaĵoj, kiuj ignoras la sisteman prokurilon, tute preterpasas la regulon. Se ĝi realigas ilin per solvado de nomoj kaj aldonado de itineroj, la adresoj estas same freŝaj kiel la lasta refreŝigo. Se ĝi hokas la solvilon, DNS-konduto fariĝas parto de la enkursiga politiko, kaj rezerva solvilo povas silente nuligi ĝin.

Legu la modelon de la vendisto, ne la etikedon de la agordo. Du klientoj kun skatolo nomata Split Tunnel povas fari tri malsamajn aferojn.

Komparu kio rompiĝas

Tri aferoj rompiĝas malsame. Adresŝanĝiĝo: CDN-gastnomo povas solviĝi al malsama adresaro ene de minutoj, do kopiita listo maljuniĝas malbone. Subdomajna amplekso: regulo por example.com povas aŭ ne povas kovri api.example.com, kaj la dokumentaro kutime eksplicite diras kiun. Solva fiasko: kiam la solvilo fiaskas, solvanta kliento povas retiriĝi al tuneligo de la trafiko aŭ al rekta sendado.

Nur la dua estas agorda demando. La aliaj du estas dezajnaj demandoj pri kiom la produkto pretas diveni.

Kiam la prefikso estas la pli bona respondo

Por stabila privata subreto, eksplicita prefikso estas pli klara, pli rapida kaj pli facile revidebla. Ĝi ankaŭ postvivas solvilan paneon, ĉar nenio bezonas solviĝi. Uzu domajnan regulon kiam la servo estas gastigita, kiam adresoj rotacias aŭ kiam vi vere ne povas listigi la celaron. Ne uzu ĝin nur ĉar la gastnomo estas tio, kion vi hazarde scias.

Divenita statika listo estas la plej malbona el ambaŭ: ĝi aspektas prizorgata kaj silente maltrafas trafikon en la tago, kiam la provizanto aldonas gaston.

Kontrolu per freŝa peto

Testu per malvarma peto post normala rekonekto, ĉar kaŝmemorigita paĝo eble neniam tuŝos la regulon. Solvu la nomon, poste kontrolu, kien la konekto efektive iris. dig +short app.example.com donas la nunan adresaron, kaj la konekta listo de la kliento diras al vi, kiun interfacon portis la fluo.

Ripetu post la refreŝiga intervalo, kiun la produkto dokumentas. Se la adresaro drivas kaj la regulo ne sekvas, vi trovis la realan konduton.

Tenu la solvilan politikon ankaŭ aparte. Domajna regulo bezonas ĝustajn nomdatumojn, sed ĝi per si mem ne decidas, kiu solvilo respondas la mendon.