Маршрутът е отхвърлен заради битове на хоста? Намерете желания префикс

Вашият маршрутен ред се връща отхвърлен, а съветът, който намирате, казва да включите IP препращане. Тези две неща са на различни етапи от проблема. Препращането решава дали хостът може да премества пакети между интерфейси; то няма мнение дали дестинацията, която сте въвели, е валидна мрежа. Първо поправете префикса, защото препращането няма да спаси адрес и маска, които си противоречат.

За какво всъщност се оплаква анализаторът

Дестинация, записана като адрес плюс маска, трябва да описва мрежа, а мрежата започва с нулирани битове на хоста. Когато адресът, който подавате, все още носи стойност в частта за хоста, двойката е вътрешно противоречива: 172.20.130.0 изглежда подредено, защото завършва с нула, но нулата в четвъртия октет не е единственото, което има значение. Третият октет е този, който тук държи излишни битове.

Инструментите се справят с това противоречие по различен начин. Строгите анализатори отхвърлят реда и назовават битовете на хоста. Меките анализатори маскират адреса и инсталират нещо, което не сте поискали, което е по-лошо, защото конфигурацията сега маршрутизира диапазон, който никога не сте имали предвид. Модулът ipaddress на Python показва избора директно: строгият разбор на мрежа вдига грешка, а strict=False маскира битовете на хоста. Вашият клиент може да е строг, мек или непоследователен между версиите, затова четете съобщението, вместо да вярвате на навик.

Пресметнете примера на ръка

Вземете тунел, който трябва да достигне 172.20.130.0 с маска /20. /20 заема четири бита от третия октет, така че този октет се брои само на стъпки от 16: 0, 16, 32 и нататък до 240. Стойността 130 попада между 128 и 143, което означава, че обхващащата мрежа започва от 172.20.128.0, а не от 172.20.130.0 с нулиран последен октет.

Изписан, блокът върви от 172.20.128.0 до 172.20.143.255 и съдържа 4,096 адреса. Подаването на същите стойности на нестрог анализатор показва замяната, която той би направил от ваше име:

$ 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

Решете коя дестинация всъщност сте имали предвид

Отхвърленият ред обикновено крие едно от три намерения и само вие можете да изберете. Ако тунелът се нуждае от целия блок, напишете 172.20.128.0/20, каноничния мрежов адрес. Ако тунелът се нуждае само от сегмента 130, маската е била грешна и 172.20.130.0/24 е честната форма. Ако целта е една машина, маршрутът към хост IPv4 е /32 и не участва никаква аритметика с маски.

Всяко от тях разрешава различно количество трафик и това е истинската причина да не разширявате маската, докато оплакването спре. /16 приема реда почти навсякъде и изпраща трафик към дестинации, които никога не сте възнамерявали да маршрутизирате през тунела. Напишете най-тесния префикс, който отговаря на намерението, след което го потвърдете спрямо следващия хоп, който очаквате, а не спрямо мълчанието на анализатора.

Защо препращането никога не беше решението

Отхвърленият маршрут никога не достига пътя на препращането, така че превключването на net.ipv4.ip_forward не може да промени резултата. Тази настройка има значение по-късно, когато хостът трябва да пропуска пакети между интерфейси, а включването ѝ преди таблицата да е вярна променя само кой етап ще се провали след това.

Две други неща често биват обвинявани в същата точка. Маршрутът може да бъде приет и пак да загуби от по-конкретен маршрут, а правило на защитна стена може да изпусне трафик след правилно търсене. Дръжте етапите разделени: синтаксис, инсталиране, избор, филтриране. Работата по грешния етап изглежда продуктивна, защото всяка промяна рестартира нещо.

Проверете инсталирания маршрут и пътя, който той печели

Щом клиентът приеме реда, вижте какво е инсталирал и кой маршрут избира ядрото за представителен адрес в блока. Ако инсталираният префикс се различава от написаното, нормализатор е действал от ваше име.

Заявете адрес от блока, както и един извън него, за да е сравнението смислено, а не един успокояващ ред:

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

Третата заявка трябва да попадне извън тунела, ако префиксът ви е верен, а когато не е така, маршрутът, който сте изградили, е по-широк, отколкото мислите. Запишете какво е трябвало да покрива префиксът, преди да докоснете следващата настройка, защото маршрут, който се разбира, и път, който работи, остават отделни наблюдения.