Rută respinsă din cauza biților de gazdă? Găsiți prefixul dorit

Linia dvs. de rută revine respinsă, iar sfatul pe care îl găsiți spune să activați redirecționarea IP. Aceste două lucruri se află în etape diferite ale problemei. Redirecționarea decide dacă o gazdă poate muta pachete între interfețe; nu are o părere despre dacă destinația pe care ați tastat-o este o rețea validă. Corectați mai întâi prefixul, pentru că redirecționarea nu va salva o adresă și o mască ce nu se potrivesc.

De ce se plânge de fapt parserul

O destinație scrisă ca adresă plus mască trebuie să descrie o rețea, iar o rețea începe cu biți de gazdă zero. Când adresa furnizată mai poartă o valoare în partea de gazdă, perechea este intern incoerentă: 172.20.130.0 pare ordonat pentru că se termină cu zero, dar zero din al patrulea octet nu este singurul lucru important. Al treilea octet este cel care ține aici biți rătăciți.

Instrumentele tratează această incoerență diferit. Parserele stricte resping linia și numesc biții de gazdă. Parserele blânde maschează adresa și instalează ceva ce nu ați cerut, ceea ce este mai rău, pentru că configurația rutează acum un interval pe care nu l-ați intenționat niciodată. Modulul ipaddress din Python expune alegerea direct: analiza strictă a rețelei ridică o eroare, iar strict=False maschează biții de gazdă. Clientul dvs. poate fi strict, blând sau inconsecvent între versiuni, așa că citiți mesajul în loc să vă bazați pe un obicei.

Parcurgeți exemplul manual

Luați un tunel care trebuie să atingă 172.20.130.0 cu o mască /20. Un /20 împrumută patru biți din al treilea octet, deci acel octet se numără doar în pași de 16: 0, 16, 32 și mai departe până la 240. Valoarea 130 cade între 128 și 143, ceea ce înseamnă că rețeaua care îl cuprinde începe la 172.20.128.0, nu la 172.20.130.0 cu ultimul octet pus pe zero.

Scris, blocul merge de la 172.20.128.0 la 172.20.143.255 și conține 4,096 adrese. Trecerea acelorași valori la un parser nestrict arată substituția pe care ar fi făcut-o în numele dvs.:

$ 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

Decideți ce destinație ați intenționat de fapt

Linia respinsă ascunde de obicei una dintre trei intenții, iar alegerea o puteți face doar dvs. Dacă tunelul are nevoie de întregul bloc, scrieți 172.20.128.0/20, adresa de rețea canonică. Dacă tunelul are nevoie doar de segmentul 130, masca era greșită și 172.20.130.0/24 este forma onestă. Dacă ținta este o singură mașină, o rută de gazdă IPv4 este /32 și nu este implicată nicio aritmetică de măști.

Fiecare dintre ele autorizează o cantitate diferită de trafic, și acesta este motivul real pentru care nu ar trebui să lărgiți masca până când reclamația încetează. Un /16 acceptă linia aproape oriunde și trimite trafic către destinații pe care nu ați vrut niciodată să le rutați prin tunel. Scrieți cel mai îngust prefix care corespunde intenției, apoi confirmați-l față de următorul salt pe care îl așteptați, nu față de tăcerea parserului.

De ce redirecționarea nu a fost niciodată soluția

O rută respinsă nu ajunge niciodată pe calea de redirecționare, așa că schimbarea net.ipv4.ip_forward nu poate schimba rezultatul. Acea setare contează mai târziu, când gazda trebuie să transmită pachete între interfețe, iar activarea ei înainte ca tabelul să fie corect schimbă doar care etapă va eșua în continuare.

Alte două lucruri sunt adesea învinovățite în același punct. Ruta poate fi acceptată și totuși pierde în fața unei rute mai specifice, iar o regulă de firewall poate arunca traficul după o căutare corectă. Țineți etapele separate: sintaxă, instalare, selecție, filtrare. Munca la etapa greșită pare productivă pentru că fiecare schimbare repornește ceva.

Verificați ruta instalată și calea pe care o câștigă

Odată ce clientul acceptă linia, uitați-vă ce a instalat și ce rută alege nucleul pentru o adresă reprezentativă din bloc. Dacă prefixul instalat diferă de cel scris, un normalizator a acționat în numele dvs.

Interogați o adresă membru și una din afara blocului, pentru ca comparația să fie semnificativă și nu o singură linie liniștitoare:

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

A treia interogare ar trebui să cadă în afara tunelului dacă prefixul este corect, iar când nu se întâmplă, ruta construită este mai largă decât credeți. Notați ce trebuia să acopere prefixul înainte de a atinge următoarea setare, pentru că o rută care se parsează și o cale care funcționează rămân observații separate.