VPN на роутері працює, але клієнти LAN залишаються без інтернету

Роутер виходить в інтернет через свій тунель, а пристрої за ним — ні. Пересилання, трансляція та зворотні маршрути — це різні дозволи.

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

Читайте збій із хоста LAN

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

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

Локальний і пересланий трафік різні

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

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

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

Зворотний шлях теж має існувати

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

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

DNS клієнта належить до того самого огляду. Резолвер роутера може відповідати, а клієнт, скерований на інший сервер, не отримує взагалі нічого.

Перевірте один дозволений і один заборонений потік

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

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

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

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

Схожі статті