Откройте доступ к одному VPN-подключению для всех устройств в вашей локальной сети

Один ноутбук держит туннель, остальной дом хочет такой же доступ, и первая попытка — направить всё на подключённую машину. Это не работает по причинам, не имеющим к VPN никакого отношения: принимающий хост должен перенаправить пакет, переписать его источник и позаботиться о том, чтобы ответы нашли обратный путь. Пропустите хоть одно из трёх — и подключённый ноутбук продолжит работать, а все остальные устройства не получат ответа. Решение — это проект маршрутизации, а не настройка клиента.

Почему направление устройств на хост не работает

Хост, получивший пакет с адресом удалённой сети, на этот момент становится маршрутизатором — независимо от того, настраивал его кто-то так или нет. Пересылка в Linux и Windows по умолчанию выключена, если её не включит какая-нибудь функция. Трансляция адресов важна потому, что удалённая сторона должна знать, куда отправлять ответы, а частный адрес локальной сети для неё ничего не значит. Обратный маршрут — третья часть, и именно о ней забывают, когда первый ping кажется успешным.

Диагностируйте в этом порядке, а не включайте и выключайте настройки наугад. Каждая отсутствующая часть даёт немного другой симптом.

Включите пересылку и трансляцию адресов на хосте

Два изменения на подключённом хосте охватывают первые две части: включите пересылку IPv4 и транслируйте трафик локальной сети на интерфейс туннеля.

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

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

Дайте локальной сети путь, переживающий перезагрузки

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

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Если направить шлюз по умолчанию клиента на хост, весь его трафик пойдёт через хост, включая локальную печать и общий доступ к файлам, поэтому посторонние вещи перестанут работать, когда хост уснёт. Добавление конкретного маршрута на маршрутизаторе для удалённого префикса действует уже: к подключённой машине идут только назначения за туннелем, а остальная локальная сеть продолжает работать. Подсети выше — примеры, поэтому замените их своими диапазонами локальной сети и туннеля. В любом случае проверьте со второго устройства при включённом, а затем выключенном туннеле.

Проверяйте MTU, прежде чем винить туннель

Туннели уменьшают полезный размер пакета, а второе устройство об этом не догадывается. Большие передачи и рукопожатия TLS застревают, тогда как небольшие запросы проходят.

ping -M do -s 1400 10.8.0.5

Ответ доказывает, что этот размер проходит путь без фрагментации; тайм-аут означает, что накладные расходы инкапсуляции вытолкнули пакет за MTU туннеля. Уменьшите MTU на интерфейсе общего доступа или ограничьте максимальный размер сегмента на пересылающем устройстве, затем повторите ту же проверку. Сначала проверьте тот же размер со стороны локальной сети, потому что локальная ошибка указывает на неё, а не на туннель. Запишите рабочий размер, так как более позднее изменение провайдера или туннеля может его сдвинуть.

Для одного дополнительного устройства достаточно общего доступа с хоста. Для дома поставьте маршрут на маршрутизатор. Когда доступ должен пережить отъезд ноутбука вместе с вами, сам туннель должен быть на отдельном шлюзе.