Elutasított útvonal gazdagépbitek miatt? Keresse meg a szándékolt előtagot

Az útvonalsora elutasítva jön vissza, és a talált tanács azt mondja, kapcsolja be az IP-továbbítást. Ez a két dolog a probléma különböző szakaszaiban van. A továbbítás eldönti, hogy egy gazdagép mozgathat-e csomagokat az interfészek között; nincs véleménye arról, hogy a beírt cél érvényes hálózat-e. Először az előtagot javítsa, mert a továbbítás nem ment meg egy egymásnak ellentmondó címet és maszkot.

Miről panaszkodik valójában az elemző

A cím plusz maszk formában írt célnak hálózatot kell leírnia, és a hálózat nullázott gazdagépbitekkel kezdődik. Ha a megadott cím még mindig értéket hordoz a gazdagép részben, a pár belsőleg ellentmondásos: a 172.20.130.0 rendezettnek tűnik, mert nullára végződik, de a negyedik oktettben lévő nulla nem az egyetlen dolog, ami számít. Itt a harmadik oktett tartja a kóbor biteket.

Az eszközök különbözőképpen kezelik ezt az ellentmondást. A szigorú elemzők elutasítják a sort, és megnevezik a gazdagépbiteket. Az engedékeny elemzők maszkolják a címet, és valami olyasmit telepítenek, amit nem kért, ami rosszabb, mert a konfiguráció most olyan tartományt irányít, amelyet soha nem szándékozott. A Python ipaddress modulja közvetlenül kínálja a választást: a szigorú hálózatelemzés hibát dob, a strict=False pedig kimaszkolja a gazdagépbiteket. Az ügyfél lehet szigorú, engedékeny vagy verziók között következetlen, ezért olvassa el az üzenetet a szokásra hagyatkozás helyett.

Dolgozza ki a példát kézzel

Vegyen egy alagutat, amelynek /20-as maszkkal el kell érnie a 172.20.130.0-t. A /20 négy bitet kölcsönöz a harmadik oktettből, ezért az az oktett csak 16-os lépésekben számít: 0, 16, 32 és tovább 240-ig. A 130-as érték 128 és 143 közé esik, ami azt jelenti, hogy a körülvevő hálózat a 172.20.128.0-nál kezdődik, nem a 172.20.130.0-nál az utolsó oktett nullázásával.

Kiírva a blokk 172.20.128.0-tól 172.20.143.255-ig tart, és 4,096 címet tartalmaz. Ugyanezeket az értékeket egy nem szigorú elemzőnek adva látszik a helyettesítés, amelyet az ön nevében végzett volna:

$ 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

Döntse el, melyik célt szándékozta valójában

Az elutasított sor általában három szándék egyikét rejti, és csak ön választhat. Ha az alagútnak az egész blokk kell, írja be a 172.20.128.0/20-at, a kanonikus hálózati címet. Ha az alagútnak csak a 130-as szegmens kell, a maszk hibás volt, és a 172.20.130.0/24 az őszinte forma. Ha egyetlen gép a cél, az IPv4 gazdagép-útvonal /32 és semmilyen maszkaritmetika nem játszik szerepet.

Mindegyikük más mennyiségű forgalmat engedélyez, és ez az igazi ok, amiért ne szélesítse a maszkot, amíg a panasz meg nem szűnik. A /16 szinte bárhol elfogadja a sort, és olyan célok felé küldi a forgalmat, amelyeket soha nem akart az alagúton át irányítani. Írja le a szándéknak megfelelő legszűkebb előtagot, majd ellenőrizze a várt következő ugrással szemben, ne az elemző csendjével szemben.

Miért nem volt soha megoldás a továbbítás

Az elutasított útvonal soha nem éri el a továbbítási útvonalat, ezért a net.ipv4.ip_forward átkapcsolása nem változtathatja meg az eredményt. Ez a beállítás később számít, amikor a gazdagépnek továbbítania kell a csomagokat az interfészek között, és a táblázat helyessége előtti bekapcsolása csak azt változtatja meg, melyik szakasz bukik el legközelebb.

Két másik dolgot gyakran szoktak ugyanazon a ponton hibáztatni. Az útvonal elfogadható, és mégis veszíthet egy konkrétabb útvonallal szemben, illetve egy tűzfal-szabály eldobhatja a forgalmat egy helyes keresés után. Tartsa külön a szakaszokat: szintaxis, telepítés, kiválasztás, szűrés. A rossz szakaszon dolgozni produktívnak tűnik, mert minden változtatás újraindít valamit.

Ellenőrizze a telepített útvonalat és az általa megnyert utat

Amint az ügyfél elfogadja a sort, nézze meg, mit telepített, és melyik útvonalat választja a kernel a blokkon belüli reprezentatív címhez. Ha a telepített előtag eltér az írottól, egy normalizáló járt el az ön nevében.

Kérdezzen le egy tagcímet és egy blokkon kívülit is, hogy az összehasonlítás értelmes legyen, ne csak egyetlen megnyugtató sor:

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 harmadik lekérdezésnek az alagúton kívülre kell esnie, ha az előtag helyes, és ha nem így van, az épített útvonal szélesebb, mint gondolja. Jegyezze fel, mit kellett volna lefednie az előtagnak, mielőtt a következő beállításhoz nyúl, mert az elemezhető útvonal és a működő út külön megfigyelés marad.