Rute afvist på grund af værtsbits? Find det tilsigtede præfiks

Din rutepegepind kommer tilbage afvist, og det råd, du finder, siger, at du skal aktivere IP-videresendelse. De to ting ligger på forskellige stadier af problemet. Videresendelse afgør, om en vært må flytte pakker mellem grænseflader; den har ingen mening om, hvorvidt den destination, du skrev, er et gyldigt netværk. Ret præfikset først, for videresendelse redder ikke en adresse og maske, der er uenige.

Hvad parseren faktisk klager over

En destination skrevet som adresse plus maske skal beskrive et netværk, og et netværk begynder med nulstillede værtsbits. Når den adresse, du angiver, stadig bærer en værdi i værtsdelen, er parret internt inkonsistent: 172.20.130.0 ser pænt ud, fordi det ender på nul, men nul i den fjerde oktet er ikke det eneste, der betyder noget. Den tredje oktet er den, der holder løse bits her.

Værktøjer håndterer den inkonsistens forskelligt. Strenge parsere afviser linjen og navngiver værtsbits. Milde parsere maskerer adressen ned og installerer noget, du ikke bad om, hvilket er værre, fordi konfigurationen nu ruter et område, du aldrig havde tænkt på. Pythons ipaddress-modul eksponerer valget direkte: streng netværksparsing rejser en fejl, og strict=False maskerer værtsbits ud. Din klient kan være streng, mild eller inkonsistent mellem versioner, så læs meddelelsen i stedet for at stole på en vane.

Gennemfør eksemplet i hånden

Tag en tunnel, der skal nå 172.20.130.0 med en /20-maske. En /20 låner fire bits fra den tredje oktet, så den oktet tæller kun i trin på 16: 0, 16, 32 og videre op til 240. Værdien 130 falder mellem 128 og 143, hvilket betyder, at det omgivende netværk begynder ved 172.20.128.0, ikke ved 172.20.130.0 med den sidste oktet ryddet.

Skrevet ud løber blokken fra 172.20.128.0 til 172.20.143.255 og rummer 4,096 adresser. At fodre de samme værdier til en ikke-streng parser viser den substitution, den ville have foretaget på dine vegne:

$ 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

Beslut, hvilken destination du faktisk mente

Den afviste linje skjuler normalt en af tre hensigter, og kun du kan vælge. Hvis tunnelen har brug for hele blokken, skriv 172.20.128.0/20, den kanoniske netværksadresse. Hvis tunnelen kun har brug for 130-segmentet, var masken forkert, og 172.20.130.0/24 er den ærlige form. Hvis en enkelt maskine er målet, er en IPv4-værtsrute /32 og ingen maskearitmetik er involveret.

Hver af dem tillader en forskellig mængde trafik, og det er den egentlige grund til ikke at udvide masken, indtil klagen stopper. En /16 accepterer linjen næsten overalt og sender trafik mod destinationer, du aldrig havde tænkt dig at rute gennem tunnelen. Skriv det snævreste præfiks, der matcher hensigten, og bekræft det derefter mod det næste hop, du forventer, ikke mod parserens tavshed.

Hvorfor videresendelse aldrig var løsningen

En afvist rute når aldrig videresendelsesstien, så det at slå net.ipv4.ip_forward til eller fra kan ikke ændre resultatet. Den indstilling betyder noget senere, når værten skal sende pakker mellem grænseflader, og at slå den til, før tabellen er korrekt, ændrer kun, hvilket stadie der fejler næste gang.

To andre ting får ofte skylden på samme punkt. Ruten kan blive accepteret og alligevel tabe til en mere specifik rute, og en firewallregel kan droppe trafik efter et korrekt opslag. Hold stadierne adskilt: syntaks, installation, valg, filtrering. At arbejde på det forkerte stadie føles produktivt, fordi enhver ændring genstarter noget.

Kontroller den installerede rute og den sti, den vinder

Når klienten accepterer linjen, se på, hvad den installerede, og hvilken rute kernen vælger for en repræsentativ adresse inde i blokken. Hvis det installerede præfiks afviger fra det, du skrev, har en normalisator handlet på dine vegne.

Forespørg på en medlemsadresse såvel som en uden for blokken, så sammenligningen er meningsfuld i stedet for en enkelt beroligende linje:

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

Den tredje forespørgsel bør falde uden for tunnelen, hvis dit præfiks er rigtigt, og når den ikke gør, er den rute, du byggede, bredere, end du tror. Notér, hvad præfikset skulle dække, før du rører den næste indstilling, fordi en rute, der parses, og en sti, der virker, forbliver separate observationer.