Rute avvist på grunn av vertsbitar? Finn det tiltenkte prefikset
Ei avvist rutesline er vanlegvis vertsbitar, ikkje eit videresendingsproblem. Finn ut kva prefiks du meinte i staden for å utvide maska til det blir godteke.
Ruteslina di kjem attende avvist, og rådet du finn seier at du skal slå på IP-videresending. Desse to tinga ligg på ulike steg av problemet. Videresending avgjer om ein vert kan flytte pakkar mellom grensesnitt; ho har inga meining om kvidvidt destinasjonen du skreiv er eit gyldig nettverk. Rett prefikset fyrst, for videresending bergar ikkje ei adresse og ei maske som er usamde.
Kva parsaren faktisk klagar over
Ein destinasjon skriven som adresse pluss maske må skildre eit nettverk, og eit nettverk byrjar med nullstilte vertsbitar. Når adressa du oppgir framleis ber ein verdi i vertsdelen, er paret internt inkonsistent: 172.20.130.0 ser ryddig ut fordi det endar på null, men nullen i fjerde oktett er ikkje det einaste som tel. Den tredje oktetten er den som held spreidde bitar her.
Verktøy handterer denne inkonsistensen ulikt. Strenge parsarar avviser lina og namngjev vertsbitar. Milde parsarar maskerer adressa og installerer noko du ikkje bad om, noko som er verre, fordi konfigurasjonen no rutar eit område du aldri meinte. Pythons ipaddress-modul viser valet direkte: streng nettverksparsing reiser ein feil, og strict=False maskerer ut vertsbitane. Klienten din kan vere streng, mild eller inkonsistent mellom versjonar, så les meldinga i staden for å stole på ein vane.
Rekn gjennom dømet for hand
Ta ein tunnel som må nå 172.20.130.0 med ei /20-maske. Ei /20 låner fire bitar frå tredje oktett, så den oktetten blir berre tald i steg på 16: 0, 16, 32 og vidare opp til 240. Verdien 130 fell mellom 128 og 143, som tyder at nettverket rundt byrjar på 172.20.128.0, ikkje på 172.20.130.0 med siste oktett nullstilt.
Skrive ut går blokka frå 172.20.128.0 til 172.20.143.255 og rommar 4,096 adresser. Å gje dei same verdiane til ein ikkje-streng parsar viser erstatninga han ville ha gjort på dine vegner:
$ 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 4096Avgjer kva destinasjon du eigentleg meinte
Den avviste lina skjuler vanlegvis ein av tre hensikter, og berre du kan velje. Treng tunnelen heile blokka, skriv 172.20.128.0/20, den kanoniske nettverksadressa. Treng tunnelen berre 130-segmentet, var maska feil, og 172.20.130.0/24 er den ærlege forma. Om ein einaste maskin er målet, er ei IPv4-vertsrute /32 og inga maskearitmetikk er involvert.
Kvar av dei tillèt ei anna mengd trafikk, og det er den eigentlege grunnen til ikkje å utvide maska før klaga stoppar. Ei /16 godtek lina nesten overalt og sender trafikk mot destinasjonar du aldri meinte å rute gjennom tunnelen. Skriv det smalaste prefikset som passar hensikta, og stadfest det deretter mot neste hopp du ventar, ikkje mot stilla til parsaren.
Kvifor videresending aldri var løysinga
Ei avvist rute når aldri fram til videresendingsbanen, så å slå net.ipv4.ip_forward av eller på kan ikkje endre resultatet. Den innstillinga betyr noko seinare, når verten må sende pakkar mellom grensesnitt, og å slå ho på før tabellen er rett endrar berre kva steg som feilar neste gong.
To andre ting får ofte skulda på same punkt. Ruta kan bli godteken og likevel tape mot ei meir spesifikk rute, og ein brannmurregel kan droppe trafikk etter eit korrekt oppslag. Hald stega åtskilde: syntaks, installasjon, val, filtrering. Å arbeide på feil steg kjennest produktivt fordi kvar endring startar noko på nytt.
Kontroller den installerte ruta og banen ho vinn
Når klienten godtek lina, sjå på kva han installerte, og kva rute kjernen vel for ei representativ adresse i blokka. Om det installerte prefikset avvik frå det du skreiv, har ein normalisator handla på dine vegner.
Spør om ei medlemsadresse så vel som ei utanfor blokka, slik at samanlikninga er meiningsfull i staden for ei enkel beroligande line:
ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10Den tredje førespurnaden bør falle utanfor tunnelen om prefikset ditt er rett, og når han ikkje gjer det, er ruta du bygde breiare enn du trur. Noter kva prefikset skulle dekkje før du rører neste innstilling, fordi ei rute som blir parsa og ein bane som verkar blir verande separate observasjonar.