Is volledige tunneling eenvoudiger dan een lange split-tunnellijst?
Een uitzonderingenlijst die de meeste apps dekt, is een standaard in vermomming. Tel de regels, controleer de gateway en migreer daarna één profiel en verifieer beide randen.
Een split-tunnellijst begint met drie toepassingen en dekt uiteindelijk het grootste deel van de machine, en elke nieuwe regel is iemands uitzondering. Op dat punt is de lijst stilletjes een standaard met extra stappen geworden. Volledige tunneling keert de zaak om: alles gaat de tunnel in, tenzij een gedocumenteerde uitsluiting anders zegt. Of dat eenvoudiger is, hangt af van de gateway en van de lokale diensten die je zou breken.
Begin met het tellen van de regels die je onderhoudt
Tel de vermeldingen en tel daarna hoeveel ervan een genoemde eigenaar hebben en een datum waarop ze voor het laatst zijn geverifieerd. Het tweede getal is het getal dat ertoe doet, want een uitzondering zonder eigenaar kan niet worden beoordeeld wanneer de software waarnaar ze verwijst wordt hernoemd of vervangen. Regels die aan een uitvoerbaar pad zijn gekoppeld, falen stil na een update, en het falen ziet eruit als een haperende VPN in plaats van een verouderde regel. Schrijf de lijst op voordat je er een mening over hebt.
Elke vermelding zou drie vragen moeten beantwoorden: wat er zonder haar stukgaat, wie dat heeft besloten, en hoe je zou merken dat de reden is verstreken. Vermeldingen die niet alle drie kunnen beantwoorden, zijn kandidaten voor verwijdering in plaats van migratie, en ze eerst verwijderen maakt de latere vergelijking eerlijk.
Als de meeste vermeldingen een groot deel van het verkeer routeren, draai je al een volledige tunnel met onderhoudslast erbij. De beslissing gaat dan over waar de standaard woont, niet over of je er een moet hebben.
Controleer of de gateway de standaard kan dragen
Volledige tunneling verplaatst elk pakket naar één apparaat, wat tegelijkertijd de CPU-belasting, de conntrack-tabel, de adresvertaling en de upstream-bandbreedtebehoefte van dat apparaat verandert. Een gateway die een paar interne subnetten comfortabel bediende, is misschien niet gedimensioneerd voor al het browsewerk van een gebruiker. Kijk naar het grootste aantal gelijktijdige sessies dat je verwacht in plaats van het gemiddelde, want de piek breekt het eerst.
ip -s link show dev tun0
conntrack -C
ss -sMeet dezelfde werklast voor en na de wijziging in plaats van te redeneren vanuit specificaties. Eén middag gewoon gebruik op één machine laat zien of de gateway dicht bij een limiet zit, en het kost niets vergeleken met ontdekken tijdens een maandagochtend.
Controleer ook de path-MTU van begin tot eind, want een volledige standaard stelt elke toepassing bloot aan de maximale pakketgrootte van de tunnel. Toepassingen die buiten de tunnel werkten, kunnen nu afhankelijk zijn van fragmentatiegedrag waar je nooit over hoefde na te denken.
Bevestig dat lokale diensten en privé-DNS nog werken
Inventariseer wat lokaal moet blijven op basis van protocol in plaats van applicatienaam: detectieprotocollen voor printers en schermen, een smart-home-bridge, de beheerpagina van een router, een lokale ontwikkelserver die bereikbaar is via een naam die alleen op het LAN wordt opgelost. Die breken wanneer de standaardroute in een tunnel begint te wijzen, en ze breken stil omdat niets een fout logt op de client.
Privé-DNS is de andere afhankelijkheid. Als interne namen voorheen door de resolver van de tunnel werden opgelost, verandert er niets; als ze lokaal werden opgelost, moet een volledige standaard ze naar een resolver brengen die de zones kent. Test na de wijziging één interne naam en één openbare naam in plaats van aan te nemen dat de resolverlijst het heeft overleefd.
Schrijf de lokale uitzonderingen in het profiel dat ze bezit. Een uitzondering die alleen in iemands geheugen wordt bewaard, is het eerste dat de volgende migratie verliest.
Migreer één profiel en verifieer de grenzen
Wijzig het profiel via de configuratie die het bezit, in plaats van een nieuwe standaard bovenop handmatige routes te leggen die eerdere experimenten hebben achtergelaten. Die achtergebleven routes zijn de gebruikelijke oorzaak van een migratie die lijkt te werken en een dag later inconsistent gedraagt. Houd het oude profiel beschikbaar zodat een rollback een keuze is en geen herbouw.
Verifieer daarna twee grenzen afzonderlijk: dat openbare en private bestemmingen beide werken, en dat ongewenst verkeer de tunnel niet buiten verlaat. Een geslaagde paginalading bewijst het eerste en zegt niets over het tweede.
ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.comHerhaal de controle na een herverbinding en na een storing, want een kill switch die verkeer tijdens een onderbreking blokkeert, is een andere eigenschap dan een route die daarna correct herstelt. Het eenvoudiger ontwerp is dat waarvan je de werkelijke dekking nog kunt uitleggen nadat een toepassing of een netwerk verandert.