Wanneer routes van een gesplitste tunnel overlappen: welk prefix wint

Twee profielen voor een gesplitste tunnel, twee privéprefixen en één host waar beide aanspraak op maken. Het symptoom is zelden een schone fout: een dienst werkt op maandag, loopt in een time-out na het opnieuw verbinden van de tweede client en werkt weer na een herstart. De volgorde waarin je de clients hebt verbonden bepaalt de uitkomst niet, en de volgorde van de rijen in de interface van de client ook niet. Voer deze controles op volgorde uit en stop bij de eerste die niet klopt, want de latere hebben alleen zin als de eerdere waar zijn.

1. Noteer de bestemming en de bron

Begin met het exacte adres waar de mislukkende aanvraag naartoe gaat, niet met de hostnaam en niet met de naam van de toepassing. Los de naam één keer op, noteer elk antwoord en kies degene die de mislukkende stroom daadwerkelijk gebruikt. Noteer daarna het lokale adres van dezelfde stroom, want het bronadres kan veranderen welke beleidsregel overeenkomt en dus welke tabel wordt geraadpleegd.

Een aanvraag naar een van meerdere A-records kan mislukken terwijl een zusteradres slaagt, wat op een onstabiele tunnel lijkt maar in werkelijkheid twee verschillende paden zijn. Als de bestemming een naam met meerdere antwoorden is, test dan elk antwoord apart voordat je iets wijzigt.

2. Vraag de kernel welke route hij koos

Lees de routetabel niet en leid het antwoord er niet uit af. Stel dezelfde vraag die de stack stelt, met hetzelfde bronadres: ip route get 10.20.4.10 from 10.8.0.2 op Linux, of Find-NetRoute -RemoteIPAddress 10.20.4.10 in PowerShell. De uitvoer noemt de route die werkelijk zou worden gebruikt, en dat is vaak niet degene die je verwachtte bij het lezen van de tabel.

Van de routes die overeenkomen wint meestal het specifiekere prefix: een /24 verslaat een /16 voor een adres dat in beide ligt. Tussen overeenkomsten van gelijke lengte wint de lagere metriek, en een route die op een verbinding staat die down is wordt overgeslagen. Twee tunnels die hetzelfde /24 met dezelfde metriek aankondigen zijn een ander geval: de kernel houdt beide routes en kiest ertussen, zodat de uitkomst kan afwisselen in plaats van de volgorde te volgen waarin de clients verbonden. Dat is precies de situatie die het patroon maandag-werkt-dinsdag-niet oplevert, en opnieuw verbinden in een andere volgorde verandert daar niets aan.

3. Controleer of een beleidsregel de opzoeking heeft omgeleid

Voordat de routetabel wordt geraadpleegd, loopt de kernel zijn beleidsregels door. Een regel kan verkeer van een bepaalde bron, gebruiker of firewallmarkering naar een heel andere tabel sturen, zodat het winnende prefix in de hoofdtabel voor die stroom misschien nooit wordt geraadpleegd. ip rule show somt ze op in evaluatievolgorde, en ip route show table 100 laat zien wat de gekozen tabel werkelijk bevat.

Hier liggen twee valkuilen. Een regel die naar een lege tabel wijst, levert een opzoeking op die doorvalt naar de volgende regel, zodat de regel niets lijkt te doen. De andere is het prioriteitsnummer zelf: regels worden oplopend gelezen, en de ingebouwde waarden zijn 0 local, 32766 main en 32767 default. Een regel met een nummer onder 32767 wordt geraadpleegd vóór de standaardregel die alles afvangt. Een regel met een nummer boven 32767 staat daarachter en wordt alleen bereikt als geen enkele eerdere tabel antwoordt, wat een normale standaardroute in main voorkomt, zodat ze in de praktijk nooit wordt bereikt en stilzwijgend niets doet terwijl ze geïnstalleerd lijkt. Als de client een regel en een route heeft geschreven, controleer dan beide, en controleer ze opnieuw na een nieuwe verbinding, want een herschreven profiel kan een tweede regel met een andere prioriteit toevoegen.

4. Scheid een routeringsgelijkspel van een gedupliceerd adresplan

Soms is het prefix helemaal niet het probleem. Twee locaties die beide 192.168.1.0/24 gebruiken, betekenen dat hetzelfde adres twee verschillende hosts aanduidt, en geen enkele route kan ze onderscheiden. Een hostroute naar een van de twee antwoorden werkt alleen tot de andere locatie voor dezelfde naam antwoordt, en dan wordt de uitzondering stilzwijgend de fout zelf.

De aanwijzing is dat het bestemmingsadres op beide paden identiek is en alleen de bedoelde eigenaar verschilt. Dat is een beslissing over het adresplan, geen routeringsaanpassing: hernummer één kant, zet één kant achter een gateway die vertaalt, of bereik de tweede locatie via een proxy die zijn eigen namen oplost. Een standaardroute verlagen of hostuitzonderingen stapelen verplaatst alleen de botsing.

5. Bevestig dat de resolver het met de route eens is

Een naam die naar het verkeerde privéadres wordt opgelost, levert elk symptoom van een routeringsconflict en geen van de oorzaken. Vergelijk het antwoord dat de host krijgt met het adres dat de bestemming werkelijk gebruikt, en controleer welke resolver heeft geantwoord. Als de tunnel een resolver pusht, zou de client die moeten installeren voor de stromen die de tunnel gebruiken; zo niet, dan blijft de host de lokale resolver vragen, die kan antwoorden uit een zoekdomein of een gecachte registratie.

Vraag de resolver rechtstreeks en noteer de server die antwoordde. Een gecacht antwoord met een korte TTL kan ook verklaren waarom de eerste aanvraag na een nieuwe verbinding zich anders gedraagt dan de vijfde.

6. Verbind opnieuw, inspecteer de toegepaste toestand en test daarna beide stromen

Verbind na een correctie opnieuw en inspecteer wat de client werkelijk heeft geïnstalleerd in plaats van de profieleditor te vertrouwen. Lees de regels, de tabellen en het resulterende antwoord van ip route get opnieuw. Een tweede client kan bij het verbinden zijn eigen route opnieuw installeren en het conflict opnieuw creëren, en daarom moet de toestandscontrole plaatsvinden nadat de laatste client verbindt, niet ervoor.

Test twee stromen, niet één: de aanvraag die eerder mislukte, en een resource die de andere tunnel hoort te gebruiken. Al het privéverkeer naar één verbinding verplaatsen laat de eerste test slagen terwijl de tweede breekt, en alleen een gepaarde test vangt dat. Noteer elke uitzondering die je behoudt, met de bestemming en de reden, zodat de volgende persoon een bewuste hostroute kan onderscheiden van een overgebleven route.