Клієнти VPN підключаються, але інтернету немає: три відсутні частини

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

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

Чому робочий тунель досі не має виходу

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

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

Тому перевіряйте три рівні, а не клієнт, і змінюйте по одному, щоб результат щось означав.

Пересилання — це перемикач ядра, який треба зробити постійним

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

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

Зробіть його постійним у файлі в /etc/sysctl.d/, а потім застосуйте цей файл замість перезавантаження, щоб дізнатися. У FreeBSD еквівалент — net.inet.ip.forwarding, а для сталості — gateway_enable=YES у rc.conf. Пристрій, що повідомляє про вимкнене пересилання, пояснює цілий клас звітів «пакети приходять, а нічого не повертається». Перевіряйте налаштування й після кожного оновлення, бо перезібране ядро або замінений образ пристрою можуть скинути його, нікому не сказавши.

Виберіть masquerade або одну фіксовану адресу трансляції

Із динамічною зовнішньою адресою masquerading — найпростіша правильна форма. Назвіть підмережу тунелю джерелом, а зовнішній інтерфейс — виходом.

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

Із статичною публічною адресою трансляція джерела саме в цю адресу передбачуваніша і легша для перевірки.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

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

Таблиця фільтрів — треті ворота

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

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

Мостовий тунель потребує іншої відповіді. Адреса належить мосту, а не фізичному порту, тож підпорядкування інтерфейсу прибирає адресу, яку він мав раніше, і хост виглядає недосяжним, доки сам міст не отримає адресу, що може забезпечити dhclient br0. Ця несправність виглядає як проблема VPN, а насправді це проблема другого рівня. Перевірте власну адресу моста, перш ніж торкатися брандмауера, бо зміна фільтра не виправить хост, який більше не має адреси для надсилання.

Куди дивитися, коли сторінка так і не завантажується

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

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

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

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

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

Схожі статті