Route afgewezen door hostbits? Vind de bedoelde prefix

Je routelijn komt afgewezen terug, en het advies dat je vindt zegt dat je IP-doorgifte moet inschakelen. Die twee dingen zitten in verschillende fasen van het probleem. Doorgifte bepaalt of een host pakketten tussen interfaces mag verplaatsen; het heeft geen mening over of de bestemming die je typte een geldig netwerk is. Repareer eerst de prefix, want doorgifte redt een adres en masker die het oneens zijn niet.

Waar de parser echt over klaagt

Een bestemming geschreven als adres plus masker moet een netwerk beschrijven, en een netwerk begint met genulde hostbits. Wanneer het adres dat je opgeeft nog een waarde in het hostdeel draagt, is het paar intern inconsistent: 172.20.130.0 ziet er netjes uit omdat het op nul eindigt, maar de nul in het vierde octet is niet het enige dat ertoe doet. Het derde octet is degene die hier losse bits heeft.

Tools gaan verschillend met die inconsistentie om. Strikte parsers weigeren de regel en noemen hostbits. Soepele parsers maskeren het adres en installeren iets dat je niet hebt gevraagd, wat erger is, omdat de configuratie nu een bereik routeert dat je nooit bedoelde. Pythons ipaddress-module biedt de keuze direct: strikte netwerkparsing geeft een fout, en strict=False maskeert de hostbits weg. Je client kan strikt, soepel of tussen versies inconsistent zijn, dus lees het bericht in plaats van op een gewoonte te vertrouwen.

Werk het voorbeeld met de hand door

Neem een tunnel die 172.20.130.0 met een /20-masker moet bereiken. Een /20 leent vier bits van het derde octet, dus dat octet telt alleen in stappen van 16: 0, 16, 32 en zo verder tot 240. De waarde 130 valt tussen 128 en 143, wat betekent dat het omvattende netwerk bij 172.20.128.0 begint, niet bij 172.20.130.0 met het laatste octet op nul.

Uitgeschreven loopt het blok van 172.20.128.0 tot 172.20.143.255 en bevat het 4,096 adressen. Dezelfde waarden aan een niet-strikte parser geven, toont de vervanging die hij namens jou zou hebben gedaan:

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

Bepaal welke bestemming je echt bedoelde

De afgewezen regel verbergt meestal een van drie bedoelingen, en alleen jij kunt kiezen. Heeft de tunnel het hele blok nodig, schrijf 172.20.128.0/20, het canonieke netwerkadres. Heeft de tunnel alleen het 130-segment nodig, dan was het masker fout en is 172.20.130.0/24 de eerlijke vorm. Is één machine het doel, dan is een IPv4-hostroute /32 en komt er geen maskerrekenkunde aan te pas.

Elk ervan staat een andere hoeveelheid verkeer toe, en dat is de echte reden om het masker niet te verbreden tot de klacht stopt. Een /16 accepteert de regel bijna overal en stuurt verkeer naar bestemmingen die je nooit via de tunnel wilde routeren. Schrijf de smalste prefix die bij de bedoeling past, en bevestig die dan tegen de volgende hop die je verwacht, niet tegen de stilte van de parser.

Waarom doorgifte nooit de oplossing was

Een afgewezen route bereikt nooit het doorgiftepad, dus net.ipv4.ip_forward omzetten kan de uitkomst niet veranderen. Die instelling is later belangrijk, wanneer de host pakketten tussen interfaces moet doorgeven, en hem aanzetten voordat de tabel klopt verandert alleen welke fase hierna faalt.

Twee andere dingen krijgen vaak de schuld op hetzelfde punt. De route kan worden geaccepteerd en toch verliezen van een specifiekere route, en een firewallregel kan verkeer laten vallen na een correcte opzoeking. Houd de fasen gescheiden: syntaxis, installatie, selectie, filtering. Aan de verkeerde fase werken voelt productief omdat elke wijziging iets opnieuw start.

Controleer de geïnstalleerde route en het pad dat hij wint

Zodra de client de regel accepteert, kijk wat hij heeft geïnstalleerd en welke route de kernel kiest voor een representatief adres in het blok. Als de geïnstalleerde prefix afwijkt van wat je schreef, heeft een normalisator namens jou gehandeld.

Vraag een lidadres op en ook een buiten het blok, zodat de vergelijking zinvol is in plaats van één geruststellende regel:

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

De derde zoekopdracht hoort buiten de tunnel te vallen als je prefix klopt, en als dat niet gebeurt, is de route die je bouwde breder dan je denkt. Noteer wat de prefix moest dekken voordat je de volgende instelling aanraakt, want een route die parst en een pad dat werkt blijven aparte waarnemingen.