Защо маршрут до хост /32 поддържа крайната точка на VPN достъпна

Маршрутът до хост избира един адрес, а не подмрежа. Той може да поддържа крайна точка на тунел достъпна или да закрепи един ресурс, но остарява, когато адресите се променят.

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

Един адрес, един запис в таблицата

Маршрутът до хост IPv4 носи префикс /32, а маршрутът до хост IPv6 носи /128, което означава, че записът може да съвпадне точно с един адрес на местоназначение. Нищо друго в таблицата не се мести: покриващата подмрежа и маршрутът по подразбиране остават където са били. Тесният запис печели за този адрес, защото префиксът му е по-дълъг, а не защото е добавен по-късно.

Това свойство прави маршрута до хост добро изключение и лош навик. Два записа /32, които назовават входната врата на услуга, не покриват втория ѝ адрес, адреса ѝ IPv6 или адреса, към който тя се мести следващия месец. Таблица, пълна с необяснени записи за един адрес, обикновено означава, че някой постоянно закърпва около решение за подмрежа, вместо да вземе такова. Прочетете първо дължината на префикса, после попитайте какво трябва да защитава записът.

Прочетете записа от клиента навън

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

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

Повторете заявката за семейството адреси, което приложението действително избира, тъй като клиентът може да предпочете IPv6 и тихо да заобиколи изключение за IPv4. Сравнете резултата преди и след вдигането на тунела и запазете двата изхода. Това сравнение показва дали клиентът е добавил записа при свързване, или той вече е бил там.

Постоянният запис и записът по време на изпълнение се провалят различно. Записът по време на изпълнение изчезва със сесията, докато постоянният преживява рестартиране и продължава да изпраща трафик към шлюз, който вече не съществува.

Изключението за крайна точка и капанът на рекурсията

VPN клиентите обикновено инсталират маршрут до хост към външния адрес на сървъра през оригиналния шлюз, преди да пренасочат маршрута по подразбиране. Без този запис криптираните пакети ще бъдат изпратени в тунела, който се опитват да изградят, и връзката ще се завърти, докато изтече времето ѝ.

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

Проверете пътя, който приложението наистина използва

Успешният ping към името на хоста е слабо доказателство, когато приложението се свързва с различен адрес или различно семейство. Проверете точната комбинация от адрес, семейство, порт и интерфейс от машината, която изпълнява клиента.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

Ако пътят е грешен, решете дали изискването е мрежа или един адрес, преди да редактирате каквото и да е. Изискване за един адрес оправдава маршрут до хост с коментар и собственик; услуга с променящи се адреси се нуждае от маршрутизация по домейн или честно решение за подмрежа.

Премахвайте записи, които вече не съответстват на реално местоназначение, и отбелязвайте тези, които запазвате. Необяснен /32 е неразличим от бъг след три месеца и следващият човек ще го изтрие, без да знае какво е зависело от него.

Подобни статии