Поділіться одним VPN-з'єднанням з усіма пристроями у вашій LAN

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

Чому спрямування пристроїв на хост не працює

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

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

Увімкніть пересилання й трансляцію адрес на хості

Дві зміни на під'єднаному хості охоплюють перші дві частини: увімкніть пересилання IPv4 і транслюйте трафік LAN на інтерфейс тунелю.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Збережіть значення sysctl у файлі під /etc/sysctl.d і після перезавантаження ще раз перевірте правило masquerade, бо інтерфейси фронтенду брандмауера можуть очищати власні ланцюжки. У Windows функція спільного доступу виконує обидва кроки, але також переназначає адаптер LAN на фіксовану підмережу й очищає його шлюз, що ламає статичну адресацію та переадресацію портів. Відновіть шлях маршрутизатора до хоста на його новій адресі, перш ніж робити висновок, що спільний доступ не вдався. Потім спостерігайте, як лічильники правила зростають, поки другий пристрій надсилає трафік.

Дайте LAN шлях, який переживає перезавантаження

Іншим пристроям потрібен маршрут до віддаленого префікса, і два способи його надати різняться масштабом впливу.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

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

Стежте за MTU, перш ніж звинувачувати тунель

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

ping -M do -s 1400 10.8.0.5

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

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