Rute avvist på grunn av vertsbits? Finn det tiltenkte prefikset

Ruteslinjen din kommer tilbake avvist, og rådet du finner sier at du skal aktivere IP-videresending. Disse to tingene ligger på forskjellige stadier av problemet. Videresending avgjør om en vert kan flytte pakker mellom grensesnitt; den har ingen mening om hvorvidt destinasjonen du skrev er et gyldig nettverk. Rett prefikset først, for videresending redder ikke en adresse og en maske som er uenige.

Hva parseren faktisk klager over

En destinasjon skrevet som adresse pluss maske må beskrive et nettverk, og et nettverk begynner med nullstilte vertsbits. Når adressen du oppgir fortsatt bærer en verdi i vertsdelen, er paret internt inkonsistent: 172.20.130.0 ser ryddig ut fordi det ender på null, men nullen i fjerde oktett er ikke det eneste som betyr noe. Den tredje oktetten er den som holder spredte bits her.

Verktøy håndterer denne inkonsistensen ulikt. Strenge parsere avviser linjen og navngir vertsbits. Milde parsere maskerer adressen og installerer noe du ikke ba om, noe som er verre, fordi konfigurasjonen nå ruter et område du aldri mente. Pythons ipaddress-modul viser valget direkte: streng nettverksparsing reiser en feil, og strict=False maskerer ut vertsbitene. Klienten din kan være streng, mild eller inkonsistent mellom versjoner, så les meldingen i stedet for å stole på en vane.

Regn gjennom eksempelet for hånd

Ta en tunnel som må nå 172.20.130.0 med en /20-maske. En /20 låner fire bits fra tredje oktett, så den oktetten telles bare i trinn på 16: 0, 16, 32 og videre opp til 240. Verdien 130 faller mellom 128 og 143, som betyr at nettverket rundt begynner på 172.20.128.0, ikke på 172.20.130.0 med siste oktett nullstilt.

Skrevet ut går blokken fra 172.20.128.0 til 172.20.143.255 og rommer 4,096 adresser. Å gi de samme verdiene til en ikke-streng parser viser erstatningen den ville ha gjort 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

Bestem hvilken destinasjon du egentlig mente

Den avviste linjen skjuler vanligvis en av tre hensikter, og bare du kan velge. Trenger tunnelen hele blokken, skriv 172.20.128.0/20, den kanoniske nettverksadressen. Trenger tunnelen bare 130-segmentet, var masken feil, og 172.20.130.0/24 er den ærlige formen. Hvis en enkelt maskin er målet, er en IPv4-vertsrute /32 og ingen maskearitmetikk er involvert.

Hver av dem tillater en annen mengde trafikk, og det er den egentlige grunnen til ikke å utvide masken før klagen stopper. En /16 godtar linjen nesten overalt og sender trafikk mot destinasjoner du aldri mente å rute gjennom tunnelen. Skriv det smaleste prefikset som passer hensikten, og bekreft det deretter mot neste hopp du forventer, ikke mot parserens stillhet.

Hvorfor videresending aldri var løsningen

En avvist rute når aldri fram til videresendingsbanen, så å slå net.ipv4.ip_forward av eller på kan ikke endre resultatet. Den innstillingen betyr noe senere, når verten må sende pakker mellom grensesnitt, og å slå den på før tabellen er riktig endrer bare hvilket stadium som feiler neste gang.

To andre ting får ofte skylden på samme punkt. Ruten kan godtas og likevel tape mot en mer spesifikk rute, og en brannmurregel kan droppe trafikk etter et korrekt oppslag. Hold stadiene atskilt: syntaks, installasjon, valg, filtrering. Å arbeide på feil stadium føles produktivt fordi hver endring starter noe på nytt.

Kontroller den installerte ruten og banen den vinner

Når klienten godtar linjen, se på hva den installerte, og hvilken rute kjernen velger for en representativ adresse i blokken. Hvis det installerte prefikset avviker fra det du skrev, har en normalisator handlet på dine vegne.

Spør om en medlemsadresse så vel som en utenfor blokken, slik at sammenligningen er meningsfull 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ørselen bør falle utenfor tunnelen hvis prefikset ditt er riktig, og når den ikke gjør det, er ruten du bygde bredere enn du tror. Noter hva prefikset skulle dekke før du rører neste innstilling, fordi en rute som parses og en bane som virker forblir separate observasjoner.