Відкриття порту VPN не дає клієнтам доступу до LAN

Правило входу пропускає пакети, адресовані самому шлюзу. Трафіку клієнта до іншого хоста потрібні пересилання, маршрутизація та зворотний шлях, які перевіряються окремо.

Тунель піднімається, клієнт проходить автентифікацію, але LAN за шлюзом залишається невидимою. Правило, яке мало це виправити, дозволяє порт VPN і працює точно так, як записано, бо воно стосується пакетів, адресованих самому шлюзу. Трафік клієнта до хоста за шлюзом має інший пункт призначення й інший ланцюг. Успішний вхід не змінює того, який із двох ланцюгів перевіряє ядро.

Два ланцюги, два різні пункти призначення

Долю пакета вирішує те, куди він іде, а не те, як він прийшов. Трафік на адресу шлюзу доставляється локально й оцінюється правилами входу. Трафік, який шлюз пересилає далі, оцінюється правилами пересилання. Той самий інтерфейс тунелю може створювати обидва види пакетів, тому одне правило не може закрити обидві задачі.

Увесь міф в одному реченні: дозвіл слухача нічого не каже про дозвіл мережі за ним. Це два окремі рішення з окремими доказами, і імʼя інтерфейсу на обох їх не обʼєднує.

Що насправді дозволяє правило слухача

Пакети слухача завершуються в процесі VPN, і саме це дає змогу взагалі підняти тунель. Сторінка керування шлюзом і локальна діагностична відповідь теж використовують власний шлях входу хоста, тому перевірка до шлюзу проходить, а все за ним відмовляє. Обидва результати правильні, і жоден не про LAN.

Коли процес декапсулює трафік клієнта для іншого пункту призначення, пакет потрапляє на шлях пересилання і потребує дозволу там. Успішна автентифікація вирішує, хто такий клієнт; вона не вирішує, куди йому можна йти. Два питання мають різних власників, різні журнали й різні повідомлення про помилку.

Перевіряйте з клієнта, ніколи зі шлюзу

Перевірка, створена на шлюзі, іде власним шляхом виходу хоста й може пройти, поки шлях пересилання закритий. Почніть перевірку з клієнта і дивіться на обидва кінці потоку.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Якщо запит зʼявляється на tun0, а до пункту призначення нічого не доходить, пакет відкидається після прибуття, що вказує на правила пересилання або на власну фільтрацію пункту призначення. Якщо на tun0 не зʼявляється взагалі нічого, клієнт навіть не надсилає його в тунель, і проблема в маршрутизації на клієнті, а не в політиці на шлюзі. Порівняйте це із запитом, який правильно виходить і нічого не повертає, це і є випадок зворотного шляху.

Пересиланню потрібні три речі, а не одна

Пересилання в ядрі має бути ввімкнене, правило фільтра має приймати потік, а пункт призначення має бути доступним із шляхом для повернення відповіді. Якщо бракує одного з трьох, тиша з погляду клієнта однакова.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Читайте три виводи разом. Нуль у першому робить інші два неважливими, а політика відкидання за замовчуванням у другому відкидає пакети клієнта, поки власний трафік шлюзу далі працює. Третій вивід показує, чому правило слухача ніколи не було проблемою.

Тримайте два набори правил окремо в документації

Запишіть правило слухача і правило служби, що пересилається, окремими рядками, з окремими власниками й причинами. Коли порт VPN змінюється або публікується нова служба, це розділення не дає одній зміні тихо розширити іншу.

Замість того щоб вважати кожного автентифікованого партнера довіреним членом LAN, використовуйте вузькі правила для тих діапазонів клієнтів і служб, яким вони потрібні. Нотатки про пересилання StrongSwan описують бік зворотного маршруту й трансляції тієї самої межі, що знову є третім рішенням.

Нарешті, тримайте шари прямими, коли користувачеві відмовляють. Якщо запит доходить до хоста, а застосунок відхиляє обліковий запис, виправте дозвіл застосунку на цьому шарі; розширення пересилання не може видати дані для спільного доступу до файлів і розширить доступ усім іншим, хто успішно підключається.

Схожі статті