Waarom route-nopull alleen de fileserver onbereikbaar laat
Gepushte routes negeren is de helft van een split tunnel. Kies de route-eigenaar, voeg het kantoorprefix met de hand toe en test drie stromen voordat je het opgelost noemt.
De fileserver opent prima, en het videogesprek in het volgende venster begint te haperen. Niets is traag en geen MTU is verkeerd: je client nam de routelijst over die de server hem gaf, dus elk pakket verlaat nu de firewall van kantoor. De oplossing is geen extra tuning-flag maar een beslissing over wie de routetabel van de client bezit. Die beslissing hoort op één plek, en de faalwijzen hieronder vertellen je welke plek je werkelijk hebt gekozen.
Bepaal wie de routetabel bezit
Drie eigenaren zijn mogelijk. De server kan routes en een standaardgateway pushen, en dan installeert de client wat hem wordt gezegd en wordt een volledige tunnel. Het clientprofiel kan het eigendom nemen door pushes te verwerpen en zijn eigen routeregels te dragen. Een desktop-verbindingsbeheerder kan de beslissing ook bezitten via zijn eigen route- en standaardroute-eigenschappen.
Elke keuze faalt anders, en daarom loont het de tabel te lezen voordat je een profiel bewerkt. De rij die bij je symptoom past, is de eigenaar die je werkelijk hebt.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Kies er één en schrijf het op. Twee door elkaar gooien laat een host achter waarvan het standaardpad zijn eigen documentatie tegenspreekt, en de volgende engineer kan niet zien welke laag heeft gewonnen. Verwijder de verliezer expliciet.
route-nopull filtert pushes, het voegt geen routes toe
route-nopull hoort in het clientprofiel, en zijn volgorde in dat bestand is irrelevant omdat het alleen waarden verwijdert die van de server komen. Het verwijdert gepushte routes, inclusief een gepushte standaardroute, terwijl de tunnel nog steeds normaal omhoog komt.
Het gevolg dat mensen missen is dat gepushte DHCP-opties mee verdwijnen. De DNS-instellingen die de server stuurt, worden ook verworpen, dus interne namen lossen niet meer op, ook al is de tunnel gezond en is de server via het adres bereikbaar.
Dat laat een tunnel achter zonder pad naar het kantoorprefix, tenzij je er zelf een toevoegt: route-nopull gevolgd door route 10.30.0.0 255.255.0.0 in hetzelfde profiel. Die regel draagt een adres en een masker; hij noemt geen volgende hop.
Een alternatieve vorm voegt een gateway-token toe, route 10.30.0.0 255.255.0.0 vpn_gateway, dat de vermelding op naam naar de tunnel wijst. Importers verschillen in of ze die variant vertalen, dus bekijk de opgeslagen verbinding als de vermelding in de kerneltabel ontbreekt.
Verifieer met route-opzoekingen, niet met een ping
Een ping vertelt je dat er iets antwoordde. Een route-opzoeking vertelt je welke interface de kernel zou kiezen, en dat is de vraag die je werkelijk stelde. Vier korte opdrachten scheiden een ontbrekende route van een route die naar het verkeerde apparaat wijst.
Lees wat de tunnel installeerde met ip route show dev tun0. Helemaal geen uitvoer betekent nul routes, wat geen werkende split tunnel is, en dat is de gebruikelijke uitkomst van het toevoegen van het filter zonder de expliciete regel.
Controleer dan één kantooradres met ip route get 10.30.5.7, en één gewoon internetadres met ip route get 1.1.1.1. De tweede moet de fysieke interface noemen; noemt hij de tunnel, dan is de push helemaal niet gefilterd.
Lees ten slotte ip rule, want een beleidsregel die een eerdere poging achterliet kan de tabel die je net hebt gecorrigeerd overstemmen. Een correct profiel met een verouderde regel erboven ziet er precies zo uit als een kapot profiel. Verwijder de regel die je de vorige keer toevoegde voordat je een nieuwe toevoegt.
Overlappende subnetten lijken op een kapotte tunnel
Twee privébereiken kunnen identiek zijn vanuit het standpunt van de client, en daar krijgt een split tunnel de schuld van iets dat hij niet veroorzaakte. Als kantoor hetzelfde prefix uitgeeft dat je thuisrouter gebruikt, dekt de tunnelroute de router en lijkt het thuisnetwerk te verdwijnen.
Vergelijk het adres op je eigen interface met de route die het profiel installeert, met een gewone adressenlijst voordat je iets verandert. De overlap is echt, en geen profieloptie lost die op. Wat je wel kunt repareren is de naamgeving, zodat de volgende persoon twee bereiken ziet in plaats van één.
De eerlijke oplossingen zijn één kant hernummeren of adressen op kantoor vertalen. Eén hostroute aan de router vastpinnen werkt tot het routeradres verandert, en dan wordt het een tweede raadsel bovenop het eerste.
Laat de beslissing een herverbinding overleven
Met de hand getypte vermeldingen overleven geen herverbinding, en een verbindingsbeheerder bouwt de tabel elke keer opnieuw op als het profiel start. Zet de beslissing waar de verbinding wordt gemaakt, of dat nu het profiel is of de opgeslagen instellingen van de beheerder. Herstart de verbinding dan één keer expres in plaats van het gedrag tijdens een gesprek te ontdekken. Een profiel dat alleen tot de volgende herverbinding werkt, is niet af.
Oefen drie paden tegelijk: een kantoorhost op het letterlijke adres, dezelfde host op naam, en een gewone openbare site. De middelste hangt af van de naamdienst die je hebt geconfigureerd nadat je de gepushte DNS-opties liet vallen, en dat is degene die stil faalt.