Domenbaserad VPN-routing kontra IP-rutter: vilken passar?
Ett värdnamn i en split tunnel-ruta är inte en rutt. Jämför domänregler och explicita prefix vad gäller uppdatering, underdomänomfattning och vad som händer när DNS ändras.
En IP-rutt matchar ett adressprefix, och kärnan tillämpar den utan att ställa fler frågor. En domänbaserad VPN-regel matchar ett namn, vilket innebär att något i stacken måste avgöra vilka adresser namnet betyder just nu och hålla det beslutet uppdaterat. Det är olika mekanismer med olika felmoder, och leverantörer använder samma ord för båda. Att jämföra dem i funktionslistor missar poängen; jämför dem efter vad som händer när svaret ändras.
Den användbara uppdelningen är mellan en regel som slår upp och en regel som inte gör det.
Vad varje regel faktiskt matchar
En prefixregel matchar destinationsadresser i en routingtabell. Inget slås upp, inget löper ut, och matchningen är exakt för varje paket. En domänregel matchar en applikations begäran om ett namn, som RFC 1034 definierar som ett träd av etiketter och inte som en adress. Vissa produkter slår upp namnet en gång och installerar de resulterande adresserna som rutter, vilket gör regeln till en IP-regel med en uppdateringstimer påhängd.
Ta reda på vilken av de två du har innan du felsöker, för felet ser helt annorlunda ut i varje fall.
Var domänregeln bor i stacken
Om produkten implementerar domänregler via en lokal proxy måste trafiken nå den proxyn, och applikationer som ignorerar systemproxyn kringgår regeln helt. Om den implementerar dem genom att slå upp namn och lägga till rutter är adresserna bara så färska som den senaste uppdateringen. Om den hakar sig fast i resolvern blir DNS-beteendet en del av routingpolicyn, och en reservresolver kan tyst upphäva den.
Läs leverantörens modell och inte etiketten på inställningen. Två klienter med en ruta som heter Split Tunnel kan göra tre olika saker.
Jämför vad som går sönder
Tre saker går sönder på olika sätt. Adressväxling: ett CDN-värdnamn kan slå upp till en annan adressuppsättning inom några minuter, så en kopierad lista blir snabbt inaktuell. Underdomänomfattning: en regel för example.com täcker kanske eller kanske inte api.example.com, och dokumentationen är oftast tydlig med vilket. Uppslagningsfel: när resolvern fallerar kan en klient som slår upp falla tillbaka på att tunnla trafiken eller skicka den direkt.
Bara den andra är en konfigurationsfråga. De andra två är designfrågor om hur mycket produkten är villig att gissa.
| 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 prefixet är det bättre svaret
För ett stabilt privat subnät är ett explicit prefix tydligare, snabbare och lättare att granska. Det överlever också ett resolveravbrott, eftersom inget behöver slås upp. Ta till en domänregel när tjänsten är hostad, när adresser roterar eller när du verkligen inte kan räkna upp destinationsmängden. Ta inte till den bara för att värdnamnet är det du råkar känna till.
En gissad statisk lista är det sämsta av båda: den ser underhållen ut, och den missar tyst trafik den dag leverantören lägger till en värd.
Verifiera med en färsk begäran
Testa med en kall begäran efter en normal återanslutning, eftersom en cachad sida kanske aldrig rör regeln. Slå upp namnet och kontrollera sedan vart anslutningen faktiskt tog vägen. dig +short app.example.com ger den aktuella adressuppsättningen, och klientens anslutningslista berättar vilket gränssnitt som bar flödet.
Upprepa efter det uppdateringsintervall som produkten dokumenterar. Om adressuppsättningen driver och regeln inte följer med, har du hittat det verkliga beteendet.
Håll också resolverpolicyn åtskild. En domänregel behöver korrekta namndata, men avgör inte i sig vilken resolver som svarar på frågan.