Usmerjanje VPN po domenah proti IP potem: kaj ustreza?
Ime gostitelja v polju razdeljenega tunela ni pot. Primerjajte domenska pravila in eksplicitne predpone glede osveževanja, obsega poddomen in tega, kaj se zgodi, ko se spremeni DNS.
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.
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client 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.