Pi VPN с несколькими роутерами: разместите каждый маршрут на устройстве, которое решает

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

Размещение Wi-Fi-коробки за Pi превращает одно решение о маршрутизации в четыре, и план ломается, когда все четыре принимаются на одном устройстве. Первый вопрос не в том, какой маршрут добавить. А в том, объединяет ли новая коробка сети или маршрутизирует, потому что этот ответ определяет, сколько подсетей существует и какие устройства должны о них узнать. Сначала выберите модель подключения; каждый маршрут следует из неё.

Мост или маршрутизация: выбор, задающий количество

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

Остальная часть плана сохраняет нижестоящий роутер и защищает исходные адреса клиентов. Цель — одна частная сеть VPN, а не полный выход в интернет. Запишите модель до адресов, потому что список ниже — лишь пример маршрутизированного подключения.

client subnet       10.41.0.0/24
client gateway      10.41.0.1
router-to-Pi link   192.168.71.2
Pi on that link     192.168.71.1
private target      10.72.9.0/24

Кто что решает

Decision ownerEntry that encodes the decisionFailure when the entry is missing
Pi VPN hostReturn route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24Replies to downstream clients die at the Pi
Owner of the remote networkA path for 10.41.0.0/24 over the permitted tunnelReplies stop at the first unaware hop
LAN router behind the PiSpecific route for 10.72.9.0/24 via 192.168.71.1, or a suitable defaultClients never send private traffic to the Pi
Client machineDefault via 10.41.0.1, or a specific entry for 10.72.9.0/24The private network is unreachable from the client

Каждое устройство принимает одно решение, и ни одно не может принять чужое вместо него. Pi нужны две записи, а не одна, и обратный путь — это то, что люди забывают. Пересылаемый трафик корректно достигает частной сети и затем умирает на обратном пути, потому что Pi понятия не имеет, где живёт 10.41.0.0/24. Это выглядит как проблема межсетевого экрана, а на деле это недостающий маршрут.

Удалённой стороне тоже нужен свой маршрут. Если служба на дальнем конце не знает, что 10.41.0.0/24 достижима через ваш туннель, ответы останавливаются на первом переходе без ответа. Добавьте оба направления, прежде чем читать фильтры пакетов.

Следующие переходы берутся из подключения

Следующий переход должен быть адресом в сети, до которой устройство действительно может добраться. Публичный адрес VPN-партнёра не является следующим переходом для частной подсети, а дальняя сеть службы вообще не является следующим переходом. Маршрут к недостижимому шлюзу выглядит правильным в списке и отбрасывает каждый пакет. Проверьте, отвечает ли шлюз, прежде чем винить назначение.

Держите внешнего VPN-партнёра Pi достижимым через его собственный маршрут нижнего уровня. Эта запись отделена от маршрутов полезной нагрузки, и их смешение даёт туннель, который не может восстановиться после смены пути.

Документация по статическим маршрутам ясно показывает разницу между назначением и шлюзом, хотя каждая платформа называет свои меню по-разному. Читайте документацию для устройства перед вами, а не копируйте экран другого производителя. Команды ниже показывают форму записей в Linux.

# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1

Что трансляция делает с источником

Если нижестоящий роутер уже транслирует своих клиентов в транзитный адрес, Pi видит один транслированный источник вместо собственного адреса каждого клиента. Это другой дизайн, нежели сохраняющий источник выше. Он меняет политику на основе источника, журналирование и то, какая сторона может инициировать соединения. Оба дизайна работают; они отвечают на разные вопросы.

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

Выбор маршрута, разрешение на пересылку и трансляция источника остаются тремя отдельными задачами. Очистка общей цепочки NAT или разрешение каждому интерфейсу из-за того, что один проводной клиент работает, — это способ превратить работающий тест в открытый пересыльщик.

Докажите это с клиентской машины

Отправьте запрос с машины в нижестоящей LAN, затем проследите его источник наружу и обратно. Ping, отправленный с Pi, никогда не задействует нижестоящий обратный маршрут, поэтому успешный ping доказывает меньше, чем кажется. Добавьте второй тест с проводного клиента в собственной LAN Pi, чтобы оба пути можно было сравнить. Повторите оба после перезагрузки любого из устройств.

Маршруты, добавленные вручную, и трансляции, которые никогда не сохранялись, исчезают вместе. Тогда пара выглядит как новая неисправность, а не как незавершённая работа.

Сохраните модель подключения вместе с маршрутами, разрешённой частной службой и любой трансляцией в одной заметке. Именно эта заметка мешает следующему человеку считать беспроводное размещение вопросом маршрутной политики.

Похожие статьи