Rutten avvisad på grund av värdbits? Hitta det avsedda prefixet

Din routelinje kommer tillbaka avvisad, och rådet du hittar säger att du ska aktivera IP-vidarebefordran. Dessa två saker ligger i olika faser av problemet. Vidarebefordran avgör om en värd får flytta paket mellan gränssnitt; den har ingen åsikt om huruvida destinationen du skrev är ett giltigt nätverk. Rätta prefixet först, eftersom vidarebefordran inte räddar en adress och mask som inte stämmer.

Vad parsern egentligen klagar på

En destination skriven som adress plus mask måste beskriva ett nätverk, och ett nätverk börjar med nollställda värdbits. När adressen du anger fortfarande bär ett värde i värddelen är paret internt inkonsekvent: 172.20.130.0 ser prydligt ut eftersom det slutar på noll, men nollan i fjärde oktetten är inte det enda som spelar roll. Den tredje oktetten är den som håller spridda bitar här.

Verktyg hanterar den inkonsekvensen olika. Strikta parsers avvisar raden och namnger värdbits. Mildare parsers maskerar adressen och installerar något du inte bad om, vilket är värre, eftersom konfigurationen nu routar ett område du aldrig avsåg. Pythons ipaddress-modul visar valet direkt: strikt nätverksparsning ger ett fel, och strict=False maskerar bort värdbitarna. Din klient kan vara strikt, mild eller inkonsekvent mellan versioner, så läs meddelandet i stället för att lita på en vana.

Räkna igenom exemplet för hand

Ta en tunnel som måste nå 172.20.130.0 med en /20-mask. En /20 lånar fyra bitar från tredje oktetten, så den oktetten räknas bara i steg om 16: 0, 16, 32 och vidare upp till 240. Värdet 130 faller mellan 128 och 143, vilket betyder att nätverket runt omkring börjar på 172.20.128.0, inte på 172.20.130.0 med sista oktetten nollställd.

Utskrivet går blocket från 172.20.128.0 till 172.20.143.255 och rymmer 4,096 adresser. Att ge samma värden till en icke-strikt parser visar den ersättning den skulle ha gjort på dina vägnar:

$ 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

Bestäm vilken destination du egentligen menade

Den avvisade raden döljer oftast en av tre avsikter, och bara du kan välja. Behöver tunneln hela blocket, skriv 172.20.128.0/20, den kanoniska nätverksadressen. Behöver tunneln bara 130-segmentet var masken fel, och 172.20.130.0/24 är den ärliga formen. Om en enda maskin är målet, är en IPv4-värdrutt /32 och ingen maskaritmetik är inblandad.

Var och en av dem tillåter en annan mängd trafik, och det är det egentliga skälet att inte bredda masken förrän klagomålet upphör. En /16 accepterar raden nästan överallt och skickar trafik mot destinationer du aldrig ville routa genom tunneln. Skriv det smalaste prefix som matchar avsikten och bekräfta det sedan mot nästa hopp du förväntar dig, inte mot parserns tystnad.

Varför vidarebefordran aldrig var lösningen

En avvisad rutt når aldrig vidarebefordringsvägen, så att slå net.ipv4.ip_forward av eller på kan inte ändra resultatet. Den inställningen spelar roll senare, när värden måste skicka paket mellan gränssnitt, och att slå på den innan tabellen är korrekt ändrar bara vilken fas som misslyckas härnäst.

Två andra saker får ofta skulden på samma punkt. Rutten kan accepteras och ändå förlora mot en mer specifik rutt, och en brandväggsregel kan släppa trafik efter en korrekt sökning. Håll faserna åtskilda: syntax, installation, urval, filtrering. Att arbeta på fel fas känns produktivt eftersom varje ändring startar om något.

Kontrollera den installerade rutten och den väg den vinner

När klienten har accepterat raden, titta på vad den installerade och vilken rutt kärnan väljer för en representativ adress i blocket. Om det installerade prefixet skiljer sig från det du skrev har en normaliserare handlat på dina vägnar.

Fråga efter en medlemsadress såväl som en utanför blocket, så att jämförelsen blir meningsfull i stället för en enda lugnande rad:

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 frågan bör falla utanför tunneln om ditt prefix är korrekt, och när den inte gör det är rutten du byggde bredare än du tror. Anteckna vad prefixet skulle täcka innan du rör nästa inställning, för en rutt som parsas och en väg som fungerar förblir separata observationer.