VPN-шлюз на Raspberry Pi: одна сетевая карта или отдельный клиентский порт

У вас есть один Pi, один работающий исходящий профиль VPN и два устройства, которые должны выходить в интернет через него. Вопрос, определяющий всю сборку, не в том, какому руководству следовать, а в том, сколько изоляции вам нужно. Один порт позволяет Pi стоять рядом с этими устройствами в LAN роутера и работать как дополнительный шлюз; второй порт позволяет поместить их в сегмент, где Pi — единственный выход. Всё после этого выбора — DHCP, охват фаервола, DNS, случай сбоя — следует из него.

Чем две схемы действительно различаются

Обе схемы маршрутизируют. Разница в том, кто ещё стоит на кабеле и что происходит, когда ваша политика неверна.

Изоляция — настоящая ось. Схема A носит рекомендательный характер: устройство, которое игнорирует шлюз от DHCP и выбирает роутер, продолжает работать, но без шифрования. Схема B навязана топологией, потому что другого следующего перехода для выбора нет.

Схема A: Pi как дополнительный шлюз в существующей LAN

Предположим, роутер провайдера — 192.168.50.1, Pi — 192.168.50.2, а выбранные клиенты указывают на Pi. Важно то, что два разных потока пакетов делят один кабель. Внутренний пакет клиента приходит на Pi и должен уйти через туннель; собственный шифрованный пакет Pi к партнёру VPN должен уйти по тому же кабелю к роутеру. Они движутся в противоположных направлениях по одному интерфейсу и требуют разной обработки.

Выдайте Pi его адрес через установленный менеджер сети, а не через старый рецепт с файлом интерфейса, который борется с ним за устройство. Затем настройте клиентов: статический шлюз на одном устройстве или резервирование DHCP, которое выдаёт 192.168.50.2 как роутер. Не меняйте весь диапазон DHCP роутера ради двух устройств и не предполагайте, что клиент уважает эту опцию — проверьте.

Слабость структурная, а не исправимая. Любой клиент в этом сегменте может указать на 192.168.50.1 и выйти открытым текстом, а устройство со вторым интерфейсом или сотовым радио полностью покидает ваш путь принуждения. Если это предложение неприемлемо для соответствующего устройства, ответ у вас уже есть: используйте схему B.

Схема B: отдельный порт запирает устройства внутри

Здесь Pi сохраняет 192.168.50.2 на восходящем канале со шлюзом 192.168.50.1 и берёт 10.20.0.1/24 на втором интерфейсе для подключённых устройств. Теперь Pi — маршрутизатор с двумя сетями, и у подключённого сегмента ровно один выход.

Проверьте диапазон против всего остального, прежде чем связывать себя: собственная подсеть туннеля, другие межсайтовые префиксы и всё, что достижимо через VPN. 10.20.0.0/24, конфликтующая с удалённой LAN, даёт тот полурабочий результат, диагностика которого занимает вечер. Если второй порт — USB-адаптер, подтвердите, что он поддерживается, и закрепите его имя в менеджере сети, чтобы перестановка после перезагрузки не сдвинула ваш адрес LAN.

Запускайте слушатель DHCP только на этом интерфейсе. Сервер, отвечающий на восходящем канале, конкурирует с роутером провайдера и раздаёт адреса вашего сегмента остальному дому. Привяжите его к интерфейсу LAN, ограничьте объявленным диапазоном и держите собственный адрес Pi вне пула.

Пересылка, трансляция и правило закрытия при сбое

Четыре вещи часто описывают как одну, и это не так. Включение пересылки (net.ipv4.ip_forward=1) лишь говорит ядру, что оно может перемещать пакеты между интерфейсами; само по себе оно ничего не разрешает и не гарантирует никакого пути. Выбор выхода — решение маршрутизации. Разрешение пакета — решение политики в цепочке forward. Перезапись его источника — решение postrouting. Сборка, которая делает только первое, даёт Pi, который с радостью пересылает клиентский трафик наружу через восходящий канал.

Ограничьте разрешение теми источниками, которые вы имели в виду, и тем интерфейсом, который трафик должен использовать, и включите обратный путь и собственные нужные назначения Pi. Затем транслируйте на выходе туннеля, если провайдер не маршрутизирует ваш префикс LAN обратно к вам. руководство по nftables рассматривает пересылку, локальный вывод и трансляцию источника как отдельные операции, и это здесь правильная мысленная модель.

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

Затем разберитесь с отсутствием туннеля. Клиентский профиль, устанавливающий широкий маршрут по умолчанию, означает также, что при падении туннеля обычный маршрут по умолчанию может вернуться и клиентский трафик тихо возвращается на восходящий канал. Там, где откат к открытому тексту неприемлем, политика forward должна явно запретить трафик от клиента к восходящему каналу, в состоянии, когда маршрут VPN исчез. Напишите это как правило отклонения, а не как предположение. Собственный шифрованный транспорт Pi к партнёру VPN — это отдельный поток local-output, и он должен оставаться разрешённым, иначе туннель никогда не сможет вернуться.

DNS и IPv6 нуждаются в собственном ответе

Если клиенты используют Pi как резолвер, они попадают на локальный слушатель, и Pi инициирует новый запрос. Этот восходящий запрос следует собственному маршруту Pi, а не правилу forward, которое вы написали для клиентов, поэтому путь клиента только через туннель плюс резолвер, выходящий напрямую, — это утечка без какого-либо сообщения об ошибке. Решите осознанно: резолвер, доступный через туннель, или локальный, который вы принимаете как прямой, и приведите собственную выходную политику Pi в соответствие с этим решением.

IPv6 снова отдельный случай. Правило forward для IPv4 ничего не ограничивает в отношении IPv6, а объявления роутера на восходящем канале могут дать Pi, и через него подключённому сегменту, второй маршрут по умолчанию, который обходит вашу политику. Либо дайте IPv6 собственный защищённый путь по тому же принципу, либо явно ограничьте его в клиентском сегменте и скажите это.

Проверьте границу, прежде чем ей доверять

Принимайте схему только после четырёх отдельных проверок, потому что соблазнительный единственный тест — открыть браузер на одном клиенте — проходит в нескольких сломанных состояниях.

Подтвердите, что один реальный клиент достигает интернета через туннель, затем подтвердите, что тот же клиент не может достичь интернета при опущенном туннеле. Подтвердите, что разрешение DNS работает и запрос уходит туда, куда вы задумали. Подтвердите, что собственный транспорт Pi всё ещё работает после перезапуска туннеля и что восстановление не требует перезагрузки машины. Наконец, проверьте устройство, которое вы не выбирали: в схеме A оно должно продолжать работать нормально, а в схеме B его в этом сегменте вообще не должно быть.

• Два порта и правило отклонения дают принуждение; один порт и опция DHCP дают совет.
• Трансляция на неправильном интерфейсе выглядит как успех и им не является.
• Собственный трафик Pi, DNS и IPv6 каждый требует решения, а не вывода.