Domenebaseret VPN-routing kontra IP-ruter: hvilken passer?
Et værtsnavn i en split-tunnel-boks er ikke en rute. Sammenlign domæneregler og eksplicitte præfikser på opdatering, underdomæneomfang og hvad der sker, når DNS ændrer sig.
En IP-rute matcher et adressepræfiks, og kernen anvender den uden at stille flere spørgsmål. En domænebaseret VPN-regel matcher et navn, hvilket betyder, at noget i stakken skal afgøre, hvilke adresser navnet aktuelt betyder, og holde den afgørelse opdateret. Det er forskellige mekanismer med forskellige fejlmåder, og leverandører bruger det samme ord om begge. At sammenligne dem på funktionslister rammer ved siden af; sammenlign dem på, hvad der sker, når svaret ændrer sig.
Den nyttige opdeling er mellem en regel, der slår op, og en regel, der ikke gør.
Hvad hver regel egentlig matcher
En præfiksregel matcher destinationsadresser i en routingtabel. Intet slås op, intet udløber, og matchningen er præcis for hver pakke. En domæneregel matcher en applikations anmodning om et navn, som RFC 1034 definerer som et træ af etiketter snarere end en adresse. Nogle produkter slår navnet op én gang og installerer de resulterende adresser som ruter, hvilket gør reglen til en IP-regel med en opdateringstimer hængt på.
Vid, hvilken af de to du har, før du fejlfinder, for fejlen ser helt anderledes ud i hvert tilfælde.
Hvor domænereglen bor i stakken
Hvis produktet implementerer domæneregler via en lokal proxy, skal trafikken nå den proxy, og applikationer, der ignorerer systemproxyen, omgår reglen helt. Hvis det implementerer dem ved at slå navne op og tilføje ruter, er adresserne kun så friske som den seneste opdatering. Hvis det hooker resolveren, bliver DNS-adfærd en del af routingpolitikken, og en reserve-resolver kan stille annullere det.
Læs leverandørens model i stedet for indstillingens etiket. To klienter med en boks, der hedder Split Tunnel, kan gøre tre forskellige ting.
Sammenlign hvad der går i stykker
Tre ting går i stykker forskelligt. Adresseudskiftning: et CDN-værtsnavn kan slå op til et andet adressesæt inden for minutter, så en kopieret liste ældes hurtigt. Underdomæneomfang: en regel for example.com dækker måske eller måske ikke api.example.com, og dokumentationen er normalt tydelig om hvilket. Slagopsfejl: når resolveren fejler, kan en klient, der slår op, falde tilbage til at tunnele trafikken eller til at sende den direkte.
Kun den anden er et konfigurationsspørgsmål. De to andre er designspørgsmål om, hvor meget produktet er villigt til at gætte.
| 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 |
Når præfikset er det bedre svar
For et stabilt privat subnet er et eksplicit præfiks klarere, hurtigere og lettere at revidere. Det overlever også et resolverudfald, fordi intet skal slås op. Grib til en domæneregel, når tjenesten er hostet, når adresser roterer, eller når du faktisk ikke kan optælle destinationssættet. Grib ikke til den, bare fordi værtsnavnet er det, du tilfældigvis kender.
En gættet statisk liste er det værste af begge: den ser vedligeholdt ud, og den overser stille trafik den dag, udbyderen tilføjer en vært.
Verificer med en frisk anmodning
Test med en kold anmodning efter en normal genopkobling, fordi en cachet side måske aldrig rører reglen. Slå navnet op, og se derefter, hvor forbindelsen faktisk gik hen. dig +short app.example.com giver det aktuelle adressesæt, og klientens forbindelsesliste fortæller dig, hvilken grænseflade der bar strømmen.
Gentag efter det opdateringsinterval, produktet dokumenterer. Hvis adressesættet driver, og reglen ikke følger med, har du fundet den reelle adfærd.
Hold også resolverpolitikken adskilt. En domæneregel har brug for korrekte navnedata, men den afgør ikke i sig selv, hvilken resolver der svarer på forespørgslen.