Waarom een /32-hostroute het VPN-eindpunt bereikbaar houdt
Een hostroute kiest één adres, geen subnet. Ze kan een tunnel-eindpunt bereikbaar houden of één bron vastpinnen, maar raakt verouderd wanneer adressen veranderen.
Je opent na het verbinden de routingtabel en vindt één adres dat via de tunnel wordt gerouteerd, terwijl het subnet eromheen nog steeds naar de lokale gateway gaat. Die vermelding is een hostroute: één adres, gematcht door een prefix van allemaal enen. Het maakt uit omdat routingbeslissingen de langst passende prefix gebruiken, dus een /32 kan een /24 of een standaardroute overschrijven zonder een van beide te wijzigen. Of dat een zorgvuldige uitzondering of een toekomstige storing is, hangt af van welk adres hij noemt en wie hem onderhoudt.
Eén adres, één vermelding in de tabel
Een IPv4-hostroute draagt een /32-prefix en een IPv6-hostroute draagt /128, wat betekent dat de vermelding precies één bestemmingsadres kan matchen. Niets anders in de tabel beweegt: het omvattende subnet en de standaardroute blijven waar ze waren. De smalle vermelding wint voor dat adres omdat de prefix langer is, niet omdat hij later is toegevoegd.
Die eigenschap maakt een hostroute een goede uitzondering en een slechte gewoonte. Twee /32-vermeldingen die de voordeur van een dienst noemen, dekken niet het tweede adres, het IPv6-adres of het adres waarheen hij volgende maand verhuist. Een tabel vol onverklaarde enkeladresvermeldingen betekent meestal dat iemand bleef doorgaan met lapwerk rond een subnetbeslissing in plaats van die te nemen. Lees eerst de prefixlengte en vraag dan wat de vermelding moet beschermen.
Lees de vermelding van de client naar buiten
Begin bij de machine met het probleem, omdat hetzelfde adres op een laptop en op de gateway ervoor anders gerouteerd kan worden. Vraag de kernel welk pad hij zou kiezen voor het exacte adres dat de toepassing gebruikt, in plaats van de tabel van bovenaf te lezen. Het antwoord omvat de interface en de volgende hop, die samen de beslissing zijn.
ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25
Herhaal de query voor de adresfamilie die de toepassing werkelijk kiest, want een client kan IPv6 verkiezen en stilletjes een IPv4-uitzondering omzeilen. Vergelijk het resultaat voor en nadat de tunnel opkomt, en bewaar beide uitvoer. Die vergelijking toont of de client de vermelding bij het verbinden toevoegde of dat hij er al was.
Een permanente vermelding en een runtime-vermelding falen verschillend. De runtime-vermelding verdwijnt met de sessie, terwijl de permanente een herstart overleeft en verkeer blijft sturen naar een gateway die niet meer bestaat.
De eindpuntuitzondering en de recursieval
VPN-clients installeren gewoonlijk een hostroute naar het buitenadres van de server via de oorspronkelijke gateway voordat ze de standaardroute omleiden. Zonder die vermelding zouden de versleutelde pakketten de tunnel in worden gestuurd die ze proberen te bouwen, en de verbinding zou in een lus lopen tot de tijd verliep.
De val verschijnt wanneer de geaccepteerde subnetten van de tunnel toevallig dat eindpuntadres bevatten, of wanneer een tweede profiel later een bredere route toevoegt. Dan verliest de eindpuntvermelding van een langere prefix en stort de sessie in zodra er verkeer doorheen gaat. Het eindpuntadres naast de geaccepteerde subnetten schrijven is de goedkoopste manier om de botsing vóór de gebruikers op te merken. Het verklaart ook waarom hetzelfde profiel vanuit het ene netwerk werkt en vanuit het andere faalt.
Verifieer het pad dat de toepassing werkelijk gebruikt
Een geslaagde ping naar de hostnaam is zwak bewijs wanneer de toepassing verbinding maakt met een ander adres of een andere familie. Verifieer de exacte combinatie van adres, familie, poort en interface, vanaf de machine die de client uitvoert.
ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net
Als het pad verkeerd is, bepaal dan of de eis een netwerk of één adres is voordat je iets bewerkt. Een eis van één adres rechtvaardigt een hostroute met een opmerking en een eigenaar; een dienst met roterende adressen heeft domeingebaseerde routing of een eerlijke subnetbeslissing nodig.
Verwijder vermeldingen die niet meer naar een echte bestemming verwijzen en noteer de vermeldingen die je houdt. Een onverklaarde /32 is drie maanden later niet te onderscheiden van een fout, en de volgende persoon verwijdert hem zonder te weten wat ervan afhing.