Domenebasert VPN-ruting kontra IP-ruter: hvilken passer?

En IP-rute samsvarer med et adresseprefiks, og kjernen bruker den uten å stille flere spørsmål. En domenebasert VPN-regel samsvarer med et navn, noe som betyr at noe i stakken må avgjøre hvilke adresser navnet betyr akkurat nå, og holde den avgjørelsen oppdatert. Dette er forskjellige mekanismer med forskjellige feilmoduser, og leverandører bruker det samme ordet om begge. Å sammenligne dem i funksjonslister treffer ikke poenget; sammenlign dem etter hva som skjer når svaret endrer seg.

Den nyttige delingen er mellom en regel som slår opp, og en regel som ikke gjør det.

Hva hver regel faktisk samsvarer med

En prefiksregel samsvarer med destinasjonsadresser i en rutingtabell. Ingenting slås opp, ingenting utløper, og samsvaret er eksakt for hver pakke. En domeneregel samsvarer med en applikasjons forespørsel om et navn, som RFC 1034 definerer som et tre av etiketter og ikke som en adresse. Noen produkter slår opp navnet én gang og installerer de resulterende adressene som ruter, noe som gjør regelen til en IP-regel med en oppdateringstidtaker hengt på.

Vit hvilken av de to du har før du feilsøker, for feilen ser helt annerledes ut i hvert tilfelle.

Hvor domenereglen bor i stakken

Hvis produktet implementerer domeneregler via en lokal proxy, må trafikken nå den proxyen, og applikasjoner som ignorerer systemproxyen, omgår regelen helt. Hvis det implementerer dem ved å slå opp navn og legge til ruter, er adressene bare så ferske som den siste oppdateringen. Hvis det kroker seg på resolveren, blir DNS-atferd en del av rutingpolitikken, og en reserve-resolver kan stille oppheve den.

Les leverandørens modell i stedet for etiketten på innstillingen. To klienter med en boks som heter Split Tunnel kan gjøre tre forskjellige ting.

Sammenlign hva som ryker

Tre ting ryker på forskjellige måter. Adresseutskiftning: et CDN-vertsnavn kan slå opp til et annet adressesett i løpet av minutter, så en kopiert liste blir raskt utdatert. Underdomeneomfang: en regel for example.com dekker kanskje eller kanskje ikke api.example.com, og dokumentasjonen er vanligvis tydelig på hvilket. Oppslagssvikt: når resolveren svikter, kan en klient som slår opp, falle tilbake på å tunnelere trafikken eller sende den direkte.

Bare den andre er et konfigurasjonsspørsmål. De to andre er designspørsmål om hvor mye produktet er villig til å gjette.

Når prefikset er det bedre svaret

For et stabilt privat subnett er et eksplisitt prefiks klarere, raskere og lettere å revidere. Det overlever også et resolverutfall, fordi ingenting må slås opp. Grip til en domeneregel når tjenesten er hostet, når adresser roterer, eller når du virkelig ikke kan liste opp destinasjonssettet. Ikke grip til den bare fordi vertsnavnet er det du tilfeldigvis kjenner.

En gjettet statisk liste er det verste av begge: den ser vedlikeholdt ut, og den overser stille trafikk den dagen leverandøren legger til en vert.

Verifiser med en fersk forespørsel

Test med en kald forespørsel etter en normal gjenoppkobling, fordi en bufret side kanskje aldri berører regelen. Slå opp navnet, og sjekk deretter hvor forbindelsen faktisk gikk. dig +short app.example.com gir det gjeldende adressesettet, og klientens tilkoblingsliste forteller deg hvilket grensesnitt som bar strømmen.

Gjenta etter oppdateringsintervallet produktet dokumenterer. Hvis adressesettet driver og regelen ikke følger etter, har du funnet den virkelige atferden.

Hold også resolverpolitikken atskilt. En domeneregel trenger korrekte navndata, men den avgjør ikke i seg selv hvilken resolver som svarer på spørringen.