De console biedt een schakelaar voor split-tunnel, dus de beslissing voelt als een selectievakje. Dat is het niet. Wat de client werkelijk bereikt, is de gepubliceerde routenset van het eindpunt, en die lijst bepaalt welke privé-prefixen de tunnel gebruiken, of algemeen internetverkeer lokaal blijft of via AWS naar buiten gaat, en met welke resolver de client nog kan praten. Drie vragen beslissen het ontwerp, en elk ervan kan slecht worden beantwoord terwijl de verbinding toch slaagt.

Een split-tunnelvlag is geen bestemmingslijst

AWS beschrijft split-tunneling als het toevoegen van eindpunt-routes aan de routetabel van de client bij het opzetten van de verbinding. Een route naar de privé-VPC beperkt de tunnel tot die bestemming; al het andere volgt het gewone pad van de client. Een standaardroute is een andere instructie met een ander effect, daarom waarschuwt de documentatie over split-tunneling tegen het publiceren van 0.0.0.0/0 op een eindpunt dat voor deze modus is geconfigureerd: dat breekt de connectiviteit meestal eerder dan dat het die uitbreidt. De routetabel van het eindpunt is het beleid, en de routetabel van de client is het resultaat dat je kunt inspecteren.

Lees de routetabel van het eindpunt en de geïnstalleerde routes van de client samen. Het label beschrijft een bedoeling; de routes beschrijven wat er gebeurt.

Eerste beslissing: moet algemeen internetverkeer lokaal blijven?

Als browsen de eigen verbinding van de gebruiker moet gebruiken, publiceer dan alleen de privé-bestemmingen die het werk nodig heeft en stop daar. Voeg geen internetroute toe omdat een handleiding voor volledige tunnels er een bevatte, en ga er niet van uit dat de extra route de beveiliging verbetert. Ze verandert het pad, voegt geen beleid toe, en kost meestal latentie die je niet had begroot.

Als internetverkeer via AWS naar buiten moet, bouw dan de gedocumenteerde internettoegangsarchitectuur: eindpunt-route, autorisatieregels, het pad van het gekoppelde subnet, beveiligingsbeleid en een werkende upstream-uitgang. Een standaardroute alleen levert niets daarvan.

Tweede beslissing: welke privé-prefixen, geautoriseerd door wie?

Publiceer de kleinste set bestemmingen die de werkelijke werklast dient, en controleer dat elk gekoppeld subnet ernaartoe kan routeren. Het route-doel van het eindpunt en de VPC-routering van het subnet zijn verschillende lagen, en een route die in de ene bestaat is geen bewijs over de andere. Autorisatie is weer apart: een bestemming kan bereikbaar zijn en toch geweigerd worden omdat de groep van de client geen regel heeft die het toestaat.

Eén geslaagde sessie testen bewijst één pad. Controleer elk gekoppeld subnet, want een subnetkoppeling die later is toegevoegd is precies waar de ontbrekende route meestal zit.

Wanneer een bestemming op naam bereikbaar moet zijn, let erop dat de volgende vraag naamresolutie is, niet de route.

Derde beslissing: welke resolver volgt de tunnel?

Een client kan een DNS-server ontvangen die alleen via de VPN bereikbaar is, en die resolver werkt alleen als het adres zelf binnen een geautoriseerde route ligt. Verifieer beide helften: het adres van de resolver volgt een gepubliceerde route, en de server antwoordt op de namen die de applicatie vraagt. Een verzoek dat op adres slaagt maar op hostnaam faalt, wijst op naamgeving, niet op routering, en de tunnel debuggen kost in dat geval de middag.

Openbare namen moeten worden opgelost zoals voor de verbinding, wat nog een reden is om precies te zijn over wat je publiceert.

Wijzig de routenset en verifieer daarna beide werelden

AWS documenteert dat het wijzigen van routes op een split-tunnel-eindpunt clientverbindingen reset. Plan de wijziging met dat in gedachten: pas haar toe, verbind opnieuw via de ondersteunde client en lees de geïnstalleerde routes opnieuw in plaats van te vertrouwen op de status die vóór de bewerking is toegepast. Verouderde toegepaste status is de meest voorkomende reden dat een correcte wijziging kapot lijkt.

Accepteer het ontwerp alleen als één privébron en één openbare bestemming zich beide gedragen zoals bedoeld, op naam en op adres, in de adresfamilies die je werkelijk ondersteunt. Een tunnel die authenticeert is niet hetzelfde als een tunnel die correct splitst.

Schrijf de routelijst in de runbook naast de redenering, zodat de volgende persoon een bewuste uitsluiting kan onderscheiden van een vergeten.

Gerelateerde artikelen