ICMP-omleidingen versus je VPN-routes: wat er echt verandert
Een omleiding is een suggestie van een router, geen routewijziging. Of de host er gehoor aan geeft, hangt af van per-interface beleid dat verschilt tussen IPv4 en IPv6.
Een stroom die door de tunnel zou moeten lopen, neemt een andere volgende hop, en iemand vindt een ICMP-omleiding in een capture. Dat is een hypothese, geen diagnose. Een omleiding is een suggestie van een router over een betere volgende hop, en of de host er iets mee doet, hangt af van instellingen die per platform, per interface en per adresfamilie verschillen.
Een omleiding is een suggestie van een router
IPv4 ICMP-omleidingen hebben een eigen berichttype en een smalle set voorwaarden: de router stuurt een pakket uit via de interface waarop het binnenkwam, en kent op diezelfde link een volgende hop die dichter bij de bestemming ligt. Daarna zegt hij tegen de afzender dat die hop rechtstreeks moet worden gebruikt. Het bericht noemt de nieuwe gateway en bevat een deel van het oorspronkelijke pakket, zodat de afzender het aan een stroom kan koppelen. Het is een hoffelijk bericht over de lokale topologie, en het gaat ervan uit dat de afzender de link met de voorgestelde gateway deelt.
De afzender mag het negeren. Niets in het protocol verplicht een host zijn tabel te wijzigen, en een vastgelegde omleiding bewijst alleen dat een router er een heeft gestuurd.
Op dat onderscheid gaan de meeste onderzoeken naar omleidingen de mist in.
IPv4 en IPv6 leveren het verschillend af
IPv6 heeft een vergelijkbaar mechanisme binnen buurtdetectie in plaats van in ICMPv4, met andere berichtformaten en andere validatieregels. De begrippen rijmen, de pakketten niet. Een capturefilter dat voor ICMP-type 5 is geschreven, toont niets op een IPv6-netwerk, wat soms wordt gelezen als bewijs dat er geen omleiding is geweest.
De beleidsknoppen staan ook apart, dus een host kan IPv4-omleidingen accepteren en IPv6-omleidingen negeren, of andersom.
Controleer beide families als de betrokken stroom er een van beide kan gebruiken.
Acceptatie is hostbeleid, geen netwerkfeit
Op Linux wordt het accepteren van omleidingen per interface en globaal geregeld, en de standaardwaarden verschillen tussen de host- en de routerrol. Een tunnelinterface die omleidingen accepteert is een vreemd ontwerp, want binnen een point-to-pointtunnel is er geen zinvolle alternatieve volgende hop op dezelfde link. Daarom is deze instelling het lezen waard in plaats van het aannemen.
Instellingen voor secure redirects beperken verder welke gateways geloofd mogen worden.
Als je een host aanscherpt, zijn dat de knoppen om te bekijken, en ze zijn ook de reden dat twee machines op hetzelfde netwerk zich anders kunnen gedragen. Wijzig ze als beleid, niet als debugkorteroute.
Wat een omleiding niet kan verklaren
Specifieke routes, beleidsroutingregels en lokale interfaces verklaren de meeste onverwachte paden zonder enige omleiding. Een specifieker prefix, een regel die bij het bronadres past, of een tweede standaardroute in een andere tabel elk daarvan overschrijft de route die je verwachtte. Controleer die eerst, want ze zijn deterministisch en zichtbaar.
Een verouderde capture is de andere valkuil, want een client die van netwerk is gewisseld, heeft een andere lokale gateway.
Een oude omleiding van de vorige verbinding verklaart niets over het huidige pad, dus leg vast welke interface het controlverkeer nu ontvangt.
Controleer de route voordat je de tunnel de schuld geeft
Vraag de kernel welke route hij voor de bestemming zou gebruiken, vergelijk die dan met de tabel die je bedoelde. Als het antwoord overeenkomt met de tabel, heeft geen enkele omleiding iets veranderd en hoort het onderzoek elders thuis. Komt het niet overeen, zoek dan naar een gecachte omleiding, een beleidsregel of een tweede tabel voordat je aanneemt dat de tunnel schuldig is. De routelookup is de grondwaarheid, en al het andere is een verhaal over hoe het zo is gekomen.
Een omleiding mag nooit de reden zijn dat een beschermd pad stilzwijgend een onbeschermd pad wordt, en daarom hoort acceptatiebeleid in de ontwerpbeoordeling. RFC 792-definitie blijft de referentie voor wat het IPv4-bericht mag zeggen.
Schrijf de routelookup en de tijdstempel van de capture samen op, dan kan de volgende persoon je conclusie reproduceren.