Váš řádek trasy se vrací odmítnutý a rada, kterou najdete, říká zapnout IP přesměrování. Tyto dvě věci jsou v různých fázích problému. Přesměrování rozhoduje, zda hostitel může přenášet pakety mezi rozhraními; nemá názor na to, zda cíl, který jste napsali, je platná síť. Opravte nejdřív prefix, protože přesměrování nezachrání adresu a masku, které si odporují.

Na co si parser vlastně stěžuje

Cíl zapsaný jako adresa plus maska musí popisovat síť a síť začíná vynulovanými bity hostitele. Když adresa, kterou zadáváte, stále nese hodnotu v části hostitele, je dvojice vnitřně nekonzistentní: 172.20.130.0 vypadá uhlazeně, protože končí nulou, ale nula ve čtvrtém oktetu není jediná věc, na které záleží. Právě třetí oktet zde drží zbylé bity.

Nástroje tuto nekonzistenci řeší různě. Přísné parsery řádek odmítnou a pojmenují bity hostitele. Mírné parsery adresu zamaskují a nainstalují něco, co jste nežádali, což je horší, protože konfigurace nyní směruje rozsah, který jste nikdy nezamýšleli. Modul ipaddress v Pythonu nabízí volbu přímo: přísné parsování sítě vyvolá chybu a strict=False bity hostitele vymaže. Váš klient může být přísný, mírný nebo nekonzistentní mezi verzemi, takže čtěte zprávu, místo abyste věřili zvyku.

Projděte příklad ručně

Vezměte tunel, který potřebuje dosáhnout 172.20.130.0 s maskou /20. /20 si půjčuje čtyři bity ze třetího oktetu, takže tento oktet se počítá jen v krocích po 16: 0, 16, 32 a dál až do 240. Hodnota 130 leží mezi 128 a 143, což znamená, že obklopující síť začíná na 172.20.128.0, ne na 172.20.130.0 s vynulovaným posledním oktetem.

Zapsáno, blok jde od 172.20.128.0 do 172.20.143.255 a obsahuje 4,096 adres. Předání stejných hodnot nepřísnému parseru ukáže záměnu, kterou by provedl vaším jménem:

$ 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

Rozhodněte, který cíl jste vlastně mysleli

Odmítnutý řádek obvykle skrývá jeden ze tří záměrů a vybrat můžete jen vy. Pokud tunel potřebuje celý blok, napište 172.20.128.0/20, kanonickou síťovou adresu. Pokud tunel potřebuje jen segment 130, maska byla špatná a 172.20.130.0/24 je poctivá forma. Pokud je cílem jediný stroj, trasa k hostiteli IPv4 je /32 a žádná aritmetika masek do toho nevstupuje.

Každá z nich povoluje jiné množství provozu, a to je skutečný důvod, proč nerozšiřovat masku, dokud stížnost neustane. /16 přijme řádek téměř kdekoli a posílá provoz k cílům, které jste nikdy nechtěli směrovat tunelem. Napište nejužší prefix, který odpovídá záměru, a pak jej potvrďte proti dalšímu hopu, který očekáváte, ne proti mlčení parseru.

Proč přesměrování nikdy nebylo řešením

Odmítnutá trasa se nikdy nedostane do cesty přesměrování, takže přepnutí net.ipv4.ip_forward nemůže změnit výsledek. Toto nastavení je důležité později, když hostitel musí předávat pakety mezi rozhraními, a zapnutí předtím, než je tabulka správná, mění jen to, která fáze selže příště.

Na stejném místě se často obviňují dvě další věci. Trasa může být přijata a přesto prohrát se konkrétnější trasou a pravidlo firewallu může zahodit provoz po správném vyhledání. Držte fáze oddělené: syntaxe, instalace, výběr, filtrování. Práce ve špatné fázi působí produktivně, protože každá změna něco restartuje.

Zkontrolujte nainstalovanou trasu a cestu, kterou vyhraje

Jakmile klient řádek přijme, podívejte se, co nainstaloval a kterou trasu jádro vybere pro reprezentativní adresu uvnitř bloku. Pokud se nainstalovaný prefix liší od napsaného, jednal za vás normalizér.

Dotážete se na adresu člena i na jednu mimo blok, aby srovnání bylo smysluplné, a ne jen jeden uklidňující řádek:

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

Třetí dotaz by měl spadnout mimo tunel, pokud je váš prefix správný, a když ne, trasa, kterou jste postavili, je širší, než si myslíte. Zaznamenejte, co měl prefix pokrývat, než se dotknete dalšího nastavení, protože trasa, která se parsuje, a cesta, která funguje, zůstávají oddělená pozorování.

Související články