Pot IP se ujema s predpono naslova in jedro jo uporabi, ne da bi postavljalo dodatna vprašanja. Pravilo VPN na podlagi domene se ujema z imenom, kar pomeni, da mora nekaj v skladu odločiti, katere naslove to ime trenutno pomeni, in to odločitev ohranjati ažurno. To so različni mehanizmi z različnimi načini odpovedi in ponudniki uporabljajo isto besedo za oba. Primerjanje na seznamih funkcij zgreši bistvo; primerjajte ju po tem, kaj se zgodi, ko se odgovor spremeni.

Koristna delitev je med pravilom, ki razreši, in pravilom, ki ne razreši.

S čim se vsako pravilo dejansko ujema

Pravilo predpone se ujema s ciljnimi naslovi v usmerjevalni tabeli. Nič se ne razreši, nič ne poteče in ujemanje je natančno za vsak paket. Pravilo domene se ujema z zahtevo aplikacije po imenu, ki jo RFC 1034 opredeljuje kot drevo oznak in ne kot naslov. Nekateri izdelki ime razrešijo enkrat in dobljene naslove namestijo kot poti, kar pravilo spremeni v pravilo IP s priloženim časovnikom osveževanja.

Pred razhroščevanjem ugotovite, katero od teh dveh imate, ker je napaka v vsakem primeru videti povsem drugače.

Kje v skladu živi pravilo domene

Če izdelek uveljavlja domenska pravila prek lokalnega posrednika, mora promet priti do tega posrednika, aplikacije, ki ne upoštevajo sistemskega posrednika, pa pravilo popolnoma obidejo. Če jih uveljavlja z razreševanjem imen in dodajanjem poti, so naslovi sveži le do zadnjega osveževanja. Če se pripne na razreševalnik, postane vedenje DNS del usmerjevalne politike in rezervni razreševalnik jo lahko tiho razveljavi.

Berite model ponudnika in ne oznake nastavitve. Dva odjemalca s poljem z imenom Split Tunnel lahko počneta tri različne stvari.

Primerjajte, kaj se zlomi

Tri stvari se zlomijo različno. Spreminjanje naslovov: ime gostitelja CDN se lahko v nekaj minutah razreši v drugačen nabor naslovov, zato kopirani seznam hitro zastara. Obseg poddomen: pravilo za example.com lahko pokriva api.example.com ali pa ne, in dokumentacija je običajno izrecna glede tega. Napaka razreševanja: ko razreševalnik odpove, se odjemalec, ki razrešuje, lahko vrne k tuneliranju prometa ali k njegovemu neposrednemu pošiljanju.

Le drugo je vprašanje konfiguracije. Drugi dve sta vprašanji zasnove o tem, koliko je izdelek pripravljen ugibati.

BehaviourPrefix ruleDomain rule
Match basisdestination addressrequested name or resolved addresses
Stalenessnonedepends on refresh policy
Subdomain scopenot applicableproduct-defined
Resolver outageunaffectedproduct-defined fallback
Where to debugrouting tableclient log plus resolver state

Kdaj je predpona boljši odgovor

Za stabilno zasebno podomrežje je eksplicitna predpona jasnejša, hitrejša in lažja za revizijo. Preživi tudi izpad razreševalnika, ker ni treba ničesar razrešiti. Po pravilo domene posezite, ko je storitev gostovana, ko se naslovi vrtijo ali ko resnično ne morete našteti nabora ciljev. Ne posegajte po njem le zato, ker je ime gostitelja tisto, kar slučajno poznate.

Uganjen statični seznam je najslabši od obojega: videti je vzdrževan in tiho zgreši promet na dan, ko ponudnik doda gostitelja.

Preverite s svežo zahtevo

Preizkusite s hladno zahtevo po običajni ponovni povezavi, ker se predpomnjena stran morda nikoli ne dotakne pravila. Razrešite ime in nato preverite, kam je povezava v resnici šla. dig +short app.example.com da trenutni nabor naslovov, seznam povezav odjemalca pa vam pove, kateri vmesnik je nosil tok.

Ponovite po intervalu osveževanja, ki ga izdelek dokumentira. Če se nabor naslovov premakne in mu pravilo ne sledi, ste našli resnično vedenje.

Tudi politiko razreševalnika imejte ločeno. Pravilo domene potrebuje pravilne podatke o imenih, vendar samo po sebi ne odloča, kateri razreševalnik odgovori na poizvedbo.

Sorodni članki