VPN шлюз се нуждае от IP препращане: какво да проверите

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

Двете роли са независими, както и двете семейства адреси.

Отговорът на собствения адрес не доказва нищо

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

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

Същото изречение важи за защитната стена пред решението за препращане, която има собствена политика какво може да се препраща.

Проверявайте всяко семейство адреси отделно

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

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

В много дистрибуции стойността, която четете по време на работа, е поставена там от услуга или конфигурационен файл, така че промяна, направена с еднократна команда, може да изчезне при рестартиране. Намерете файла, който притежава настройката, преди да редактирате стойността по време на работа.

Препращането е едно от четири изисквания

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

Облачните платформи добавят пето съображение. Някои налагат проверки на източника и дестинацията върху инстанциите, което отхвърля препратените пакети независимо какво е конфигурирано да прави ядрото на госта. Собствената мрежова документация на платформата е авторитетът там, а не изходът на sysctl във VM.

Тествайте от клиента, а не от шлюза

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

Пазете правилата на слушателя и правилата за препращане отделни в главата си и в записа за промени. Отварянето на VPN порта допуска клиенти до услугата; то не им дава нищо в мрежата зад нея, а двете изглеждат еднакво в списък на защитна стена, който расте години.

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