Domenebasert VPN-ruting kontra IP-ruter: kva passar?

Ei IP-rute svarar til eit adresseprefiks, og kjernen brukar ho utan å stille fleire spørsmål. Ein domenebasert VPN-regel svarar til eit namn, noko som tyder på at noko i stakken må avgjere kva adresser namnet tyder akkurat no, og halde den avgjerda oppdatert. Dette er ulike mekanismar med ulike feilmodus, og leverandørar brukar det same ordet om båe. Å samanlikne dei i funksjonslister treff ikkje poenget; samanlikn dei etter kva som skjer når svaret blir endra.

Den nyttige delinga er mellom ein regel som slår opp, og ein regel som ikkje gjer det.

Kva kvar regel faktisk svarar til

Ein prefiksregel svarar til måladdressear i ein rutetabell. Ingenting blir slått opp, ingenting går ut, og samsvaret er eksakt for kvar pakke. Ein domeneregel svarar til ei førespurnad frå ein applikasjon om eit namn, som RFC 1034 definerer som eit tre av etikettar og ikkje som ei adresse. Nokre produkt slår opp namnet éin gong og installerer dei resulterande adressene som ruter, noko som gjer regelen til ein IP-regel med ein oppdateringstidtakar hengd på.

Vit kva av dei to du har før du feilsøkjer, for feilen ser heilt annleis ut i kvart tilfelle.

Kvar domeneregel bur i stakken

Viss produktet implementerer domenereglar via ein lokal proxy, må trafikken nå den proxyen, og applikasjonar som ignorerer systemproxyen, går heilt utanom regelen. Viss det implementerer dei ved å slå opp namn og leggje til ruter, er adressene berre så friske som den siste oppdateringa. Viss det krokar seg på resolvaren, blir DNS-åtferd ein del av rutepolitikken, og ein reserve-resolver kan stille oppheve han.

Les modellen til leverandøren i staden for etiketten på innstillinga. To klientar med ein boks som heiter Split Tunnel kan gjere tre ulike ting.

Samanlikn kva som ryker

Tre ting ryker på ulike måtar. Adresseutskifting: eit CDN-vertsnamn kan slå opp til eit anna adressesett i løpet av minutt, så ei kopiert liste blir raskt utdatert. Underdomeneomfang: ein regel for example.com dekkjer kanskje eller kanskje ikkje api.example.com, og dokumentasjonen er vanlegvis tydeleg på kva som gjeld. Oppslagssvikt: når resolvaren sviktar, kan ein klient som slår opp, falle tilbake på å tunnelere trafikken eller sende han direkte.

Berre den andre er eit konfigurasjonsspørsmål. Dei to andre er designspørsmål om kor mykje produktet er villig til å gjette.

Når prefikset er det betre svaret

For eit stabilt privat subnett er eit eksplisitt prefiks klarare, raskare og lettare å revidere. Det overlever òg eit resolverutfall, fordi ingenting må slåast opp. Grip til ein domeneregel når tenesta er hosta, når adresser roterer, eller når du verkeleg ikkje kan liste opp målsettet. Ikkje grip til han berre fordi vertsnamnet er det du tilfeldigvis kjenner.

Ei gjetta statisk liste er det verste av båe: ho ser vedlikehalden ut, og ho overser stille trafikk den dagen leverandøren legg til ein vert.

Verifiser med ein fersk førespurnad

Test med ein kald førespurnad etter ei normal gjenoppkopling, fordi ei bufreist side kanskje aldri rører regelen. Slå opp namnet, og sjekk deretter kvar forbindinga faktisk gjekk. dig +short app.example.com gir det gjeldande adressesettet, og tilkoplingslista til klienten fortel deg kva grensesnitt som bar straumen.

Gjenta etter oppdateringsintervallet produktet dokumenterer. Viss adressesettet driv og regelen ikkje følgjer etter, har du funne den verkelege åtferda.

Hald òg resolverpolitikken skild. Ein domeneregel treng korrekte namndata, men han avgjer ikkje i seg sjølv kva resolver som svarar på spørjinga.