Domeingebaseerde VPN-routering versus IP-routes: welke past?

Een IP-route komt overeen met een adresprefix, en de kernel past hem toe zonder verdere vragen. Een domeingebaseerde VPN-regel komt overeen met een naam, wat betekent dat iets in de stack moet bepalen welke adressen die naam op dit moment aanduidt en die beslissing actueel moet houden. Dat zijn verschillende mechanismen met verschillende faalwijzen, en leveranciers gebruiken hetzelfde woord voor beide. Ze vergelijken in functielijsten mist het punt; vergelijk ze op wat er gebeurt als het antwoord verandert.

De nuttige scheiding is tussen een regel die oplost en een regel die dat niet doet.

Waarmee elke regel feitelijk overeenkomt

Een prefixregel komt overeen met bestemmingsadressen in een routingtabel. Niets wordt opgelost, niets verloopt, en de overeenkomst is exact voor elk pakket. Een domeinregel komt overeen met de aanvraag van een toepassing om een naam, die RFC 1034 definieert als een boom van labels en niet als een adres. Sommige producten lossen de naam één keer op en installeren de resulterende adressen als routes, waardoor de regel een IP-regel wordt met een vernieuwingstimer eraan vast.

Weet welke van de twee u hebt voordat u gaat debuggen, want de fout ziet er in elk geval heel anders uit.

Waar de domeinregel in de stack zit

Als het product domeinregels via een lokale proxy implementeert, moet verkeer die proxy bereiken, en toepassingen die de systeemproxy negeren, omzeilen de regel volledig. Als het ze implementeert door namen op te lossen en routes toe te voegen, zijn de adressen alleen zo vers als de laatste vernieuwing. Als het de resolver aankoppelt, wordt DNS-gedrag onderdeel van het routingbeleid, en een terugvalresolver kan dat stil ongedaan maken.

Lees het model van de leverancier en niet het label van de instelling. Twee clients met een vak dat Split Tunnel heet, kunnen drie verschillende dingen doen.

Vergelijk wat er stukgaat

Drie dingen gaan op verschillende manieren stuk. Adreswisseling: een CDN-hostnaam kan binnen enkele minuten naar een andere adressenset verwijzen, dus een gekopieerde lijst veroudert snel. Subdomeinbereik: een regel voor example.com dekt api.example.com misschien wel of niet, en de documentatie is meestal expliciet over welke. Oplosfout: als de resolver uitvalt, kan een client die oplost terugvallen op het tunnelen van het verkeer of op het rechtstreeks versturen ervan.

Alleen de tweede is een configuratievraag. De andere twee zijn ontwerpvragen over hoeveel het product bereid is te gissen.

Wanneer het prefix het betere antwoord is

Voor een stabiel privé-subnet is een expliciet prefix duidelijker, sneller en eenvoudiger te auditen. Het overleeft ook een resolverstoring, omdat niets opgelost hoeft te worden. Kies een domeinregel wanneer de dienst gehost wordt, wanneer adressen roteren of wanneer u de bestemmingsset echt niet kunt opsommen. Kies er niet voor alleen omdat de hostnaam het ding is dat u toevallig kent.

Een geraden statische lijst is het slechtste van beide: hij ziet onderhouden uit, en hij mist stil verkeer op de dag dat de provider een host toevoegt.

Controleer met een verse aanvraag

Test met een koude aanvraag na een normale herverbinding, omdat een pagina uit de cache de regel misschien nooit raakt. Los de naam op en controleer dan waar de verbinding werkelijk heen ging. dig +short app.example.com geeft de huidige adressenset, en de verbindingslijst van de client vertelt u welke interface de stroom droeg.

Herhaal na het vernieuwingsinterval dat het product documenteert. Als de adressenset verschuift en de regel volgt niet, hebt u het werkelijke gedrag gevonden.

Houd ook het resolverbeleid apart. Een domeinregel heeft correcte naamgegevens nodig, maar bepaalt niet op zichzelf welke resolver de query beantwoordt.