Защо net.ipv4.conf.default.forwarding не пипа tun0

Зададохте net.ipv4.conf.default.forwarding=1, рестартирахте VPN, а тунелът все още изхвърля пакети, които шлюзът би трябвало да маршрутизира. Настройката изглежда правилна във файла, а интерфейсът все още отчита, че препращането е изключено. Нищо не е счупено: променихте стойността, която наследяват бъдещите интерфейси, а не тази, която използва живият тунел.

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

Четете трите стойности заедно

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Често срещан резултат е ip_forward = 0, default.forwarding = 1 и tun0.forwarding = 0. Първите две не са съгласни относно ролята на хоста, а третата показва какво всъщност прави интерфейсът. Тази комбинация е съвместима с хост, който никога не е конфигуриран като рутер, а само е получил стойност от шаблон. Трите числа не си противоречат; те отговарят на три различни въпроса. Записването на стойността от шаблона също не решава ролята на хоста.

Защо глобалният превключвател е този, който се движи

net.ipv4.ip_forward е управлението на ниво шлюз. Промяната му обновява настройките за препращане по интерфейси като част от същата операция, затова един запис може да накара съществуващ тунел да започне да препраща. default.forwarding зарежда само интерфейси, които се инициализират след това, така че тунел, който вече е съществувал, запазва стойността, с която е роден.

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

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

Направете настройката постоянна на правилното място

Успешен еднократен sysctl -w доказва, че ядрото приема стойността. Той не оцелява след рестарт и не оцелява след мрежов мениджър, който при повторно свързване прилага отново своята представа за конфигурацията на интерфейса. Поставете ролята на шлюз в конфигурационния файл на sysctl или в мрежовия мениджър, който притежава хоста, след което рестартирайте услугата, която я прилага.

Редът има значение при тунелите. Ако мениджърът създава интерфейса при зареждане и прилага препращането след това, интерфейсът може да наследи стария default. Рестарт на услуга, който пресъздава тунела, също е събитие на създаване и лесно се пропуска, когато unit-ът изглежда здрав. Проверявайте последователността, не само крайното съдържание на файла.

Прочетете отново същите три стойности след повторното свързване на VPN и отново след рестарт. Новосъздаденият тунел е нов интерфейс, а новият интерфейс приема default, който е в сила към момента на създаването. Ако числата се променят между тези събития, конфигурацията се прилага от нещо, което още не сте идентифицирали.

Не поправяйте това с грешния инструмент

Когато препращането изглеждаше счупено, изкушението е да изчистите защитната стена или да добавите masquerading. Нито едно от двете не адресира превключвателя за препращане. Състоянието на препращане, разрешението за препращане, маршрут до дестинацията и обратен път са четири отделни изисквания и само първото е sysctl.

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

Дръжте случая IPv6 отделно

Тук всичко е IPv4. Препращането на IPv6, обявите на рутера и поведението на accept_ra имат свои собствени контроли и копирането на път ipv4 в настройка ipv6 създава файл, който изглежда правдоподобно и не прави нищо полезно. Шлюз с двоен стек се нуждае от съзнателно конфигуриране на двата набора.

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