OpenVPN із повним тунелем: додайте інтернет-вихід на боці сервера

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

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

Проштовхніть маршрут за замовчуванням і перевірте, що встановив клієнт

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

push "redirect-gateway def1"

Після повторного підключення прочитайте таблицю маршрутизації клієнта, а не покладайтеся на профіль. У Linux два записи /1 з'являються поруч із початковим маршрутом за замовчуванням, а Windows показує ту саму пару як 0.0.0.0/1 і 128.0.0.0/1. Клієнт, який ігнорує проштовхнуті параметри або налаштований їх відхиляти, зберігає старий маршрут за замовчуванням і ніколи не надсилає інтернет-трафік у тунель. Вирішіть це питання до того, як щось змінювати на сервері, бо жодне правило на боці сервера цього не компенсує.

Пересилання — це налаштування сервера, а не налаштування VPN

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

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

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

Дозвольте саме той транзит, який маєте на увазі, і нічого більше

Переслані пакети проходять шляхом forward; трафік, адресований самому хосту VPN, проходить шляхом input. Це різні рішення, і відкриття шляху input не дозволяє транзит через машину. Їхнє змішування — найпоширеніша причина, чому міжмережевий екран ніби все дозволяє, а клієнти все одно отримують тайм-аут.

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

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

Дайте відповідям місце, куди йти

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

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

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

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

Доведіть це з клієнта, а не з оболонки сервера

Почніть із числового запиту IPv4, потім із запиту імені, потім із застосунку. ping доводить пересилання й трансляцію;він нічого не доводить про розв'язання імен, бо параметри DNS набувають чинності лише коли інтеграція клієнта їх встановить.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

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

Схожі статті