Маршрут адхілены з-за бітаў хоста? Знайдзіце патрэбны прэфікс
Адхілены радок маршруту — гэта звычайна біты хоста, а не праблема перасылкі. Вызначце прэфікс, які вы мелі на ўвазе, замест таго каб пашыраць маску, пакуль ён не пройдзе разбор.
Ваш радок маршруту вяртаецца адхіленым, а парада, якую вы знаходзіце, кажа ўключыць перасылку 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Трэці запыт павінен апынуцца па-за тунелем, калі ваш прэфікс правільны, а калі не, маршрут, які вы пабудавалі, шырэйшы, чым вы думаеце. Запішыце, што прэфікс павінен быў пакрываць, перш чым кранаць наступную наладу, бо маршрут, які разбіраецца, і шлях, які працуе, застаюцца асобнымі назіраннямі.