Направете препращането на IPv4 постоянно след рестарт на VPN шлюза

Пингът към шлюза работи, а достъпът до каквото и да е зад него — не, и това е формата на проблем с препращането, а не с тунела. Локалната доставка до шлюза доказва, че тунелът се е вдигнал и задаването на адрес е проработило; тя не казва нищо за това дали ядрото ще предаде пакет от един интерфейс към друг. Преди да пипате какъвто и да е sysctl, потвърдете, че машината е предназначена да маршрутизира този трафик и намерете мрежовия контекст, който държи интерфейса към клиента. След това прочетете стойността там, а не където последното прочетено ръководство случайно е погледнало.

Достигането на шлюза не е същото като препращане

В ядрото се случват две отделни решения. Доставката до локален адрес завършва пътуването на пакета; препращането го изпраща отново през друг интерфейс и това второ решение се управлява за всяко мрежово пространство от имена. Шлюзът може да е напълно достъпен, докато препращането е изключено, и от команден ред ping двете повреди изглеждат еднакво.

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

Прочетете стойността там, където пакетите наистина са

На шлюз, който маршрутизира в пространството от имена на хоста, една команда отговаря на въпроса: sysctl net.ipv4.ip_forward. Когато входният и следващият път живеят в именувано пространство от имена, питайте него: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Стойността на хоста не замества стойността на пространството от имена и единица на хоста не е доказателство за нищо.

Не всеки контекст на маршрутизация има етикет, който да подадете на ip netns. Средите за контейнери и услугите създават пространства от имена, които никога не се регистрират под приятелско име, и за тях използвате инструментите за инспекция на средата. Заменете vpn-gw с истинското име или с механизма на средата, който достига същия контекст, и спрете да гадаете на ниво хост.

Дайте на настройката един собственик

На конвенционален хост шлюз със systemd трайната форма е drop-in файл с избрано от администратора име, например /etc/sysctl.d/60-vpn-forwarding.conf, съдържащ net.ipv4.ip_forward = 1. Напишете файла, след което заредете точно този файл, за да се промени и живото състояние: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, последвано от прочитане. Името на файла е пример, а не запазен VPN път, и водещото число има значение, защото по-късно сортираните файлове печелят.

Приоритетът е мястото, където трайността тихо се чупи. Проверете както зареждача на дистрибуцията, така и вашия drop-in, защото procps sysctl --system накрая също чете /etc/sysctl.conf, докато подредбата sysctl.d на systemd е съвсем друга последователност. По-късно присвояване може веднага да върне същия ключ, оставяйки файла ви правилен, а ефективната стойност — грешна. Не презаписвайте съществуващ администраторски файл, за да спечелите този спор; намерете собственика и променете там.

Пространство от имена, създадено след зареждането, изобщо не се управлява от drop-in файл на хоста. Неговата настройка принадлежи на това, което го създава — средата за контейнери или модула за осигуряване на пространството. Даването на контейнер на широки права на хоста, за да се избегне въпросът, е по-лоша сделка от десет минути за намиране на правилния собственик.

Разберете какво струва превключвателят, преди да го обърнете

ip_forward не е безвреден boolean. Документацията на ядрото отбелязва, че промяната му нулира няколко други параметъра на IPv4 до стойностите им по подразбиране за хост или рутер, така че диагностично обръщане може да изхвърли настройки, направени другаде, и дори да не го спомене. Отнасяйте се към него като към промяна на конфигурацията с странични ефекти, а не като към проба, която можете да пуснете небрежно.

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

Докажете трайност, след което тествайте останалата част от пътя

Прочетете стойността отново в четири момента: веднага след промяната, след появата на VPN интерфейса, след повторно свързване и след планиран рестарт. Стойност, която се връща назад в който и да е от тези моменти, има втори собственик и още едно еднократно записване само я скрива до следващото рестартиране.

Включеното препращане все още оставя три неща за проверка. Клиентът се нуждае от маршрут до дестинацията, шлюзът — от следващ маршрут плюс разрешение да го използва, а дестинацията — от обратен път до адреса на клиентския тунел. Частна маршрутизирана LAN не се нуждае автоматично от NAT, затова не добавяйте masquerading, преди да знаете кое от трите липсва, и тествайте от предвидения клиент, а не от самия шлюз, защото заявка, започнала на шлюза, никога не докосва пътя на препращане, който току-що включихте. IPv6 носи собствена политика за препращане и маршрутизация, така че работещ тест на IPv4 не казва нищо за нея.

Дръжте пътя на drop-in, собственика на пространството от имена и командата за прочитане заедно в runbook. Следващият, който поеме това, трябва да може да прочете стойността, да види кой я притежава и да реши в рамките на минута дали проблемът е в трайността, или в останалата част от пътя.