Маскарадинг или маршрутизация по политике: трафик LAN через VPN-шлюз
Linux-шлюз может скрыть источники LAN за адресом туннеля или маршрутизировать их без изменений. Выбор следует из того, кому принадлежит дальняя сторона и каков её обратный маршрут.
Поместить всю локальную сеть за VPN-туннель — простая часть; решить, как удалённая сторона видит этих клиентов, — нет. Маскарадинг переписывает каждый источник LAN в адрес туннеля шлюза, поэтому удалённый конец отвечает одному партнёру. Маршрутизация по политике сохраняет исходные адреса и требует, чтобы удалённая сторона знала, как к ним добраться. Ни то ни другое не является вариантом по умолчанию; выбор следует из того, кому принадлежит дальняя сторона и важна ли идентичность каждого устройства.
Два решения обещают разное
Маскарадинг сводит LAN к одному видимому узлу — шлюзу. Удалённая сеть отвечает на этот единственный адрес, а шлюз переводит ответы обратно клиенту, начавшему поток. На дальней стороне маршрут к вашим частным префиксам не нужен, поэтому это решение выживает у провайдера, который отказывается их передавать. Шлюз становится и источником каждого соединения, так что удалённая сторона не может отличить двух клиентов.
Маршрутизация по политике сохраняет адрес каждого клиента нетронутым. Удалённая сеть видит настоящий источник и может его зарегистрировать, применить правило для каждого узла или отправить ответ прямо на этот адрес. Эта видимость и есть весь смысл, и она несёт обязательство: на дальней стороне должен быть маршрут для префикса LAN, ведущий обратно через туннель. Спланируйте этот маршрут до включения правила, потому что туннель поднимется в любом случае, а не хватит только ответов.
Режимы отказа различаются так же сильно, как обещания. Отсутствующее правило маскарадинга даёт пакеты, которые уходят с частными источниками и никогда не возвращаются. Отсутствующий обратный маршрут даёт тот же симптом при маршрутизации по политике, но исправление относится к удалённому маршрутизатору, а не к шлюзу.
Маскарадинг: один партнёр на дальней стороне
У пути маскарадинга есть порядок, который важен. Пересылка должна быть включена, прежде чем любое правило NAT принесёт пользу, таблица фильтрации должна разрешать проход в обе стороны, и только тогда трансляция применяется на интерфейсе туннеля.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
Клиентам по-прежнему нужен путь к шлюзу. Либо шлюз является их маршрутизатором по умолчанию, либо они несут конкретный маршрут к дальнему префиксу; если отдельный маршрутизатор остаётся по умолчанию, ему нужен статический маршрут к адресам назначения туннеля, иначе пакет уйдёт не на тот хоп, прежде чем шлюз его увидит.
DNS — отдельное решение. Резолвер на дальней стороне отвечает только в том случае, если его ответ может вернуться к клиенту. При маскарадинге запрос выглядит пришедшим от шлюза, поэтому обратный путь резолвера уже обеспечен; при маршрутизации по политике резолверу нужен тот же обратный маршрут, что и любой другой удалённой службе.
Маршрутизация по политике: сохраните источник, добавьте обратный путь
Маршрутизация по политике начинается с таблицы и правила, которое её выбирает. Трафик, входящий с интерфейса LAN, отправляется в отдельную таблицу, и эта таблица несёт маршрут по умолчанию через туннель. Основная таблица остаётся нетронутой, поэтому трафик, созданный самим шлюзом, может идти другим путём.
ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn
Затем дальняя сторона должна направить префикс LAN обратно через туннель. Это настройка на удалённом маршрутизаторе, а не на этом шлюзе. Шлюз также должен принимать ответы, приходящие на другой интерфейс, чем предполагала бы основная таблица; ослабленная фильтрация обратного пути (rp_filter установлен в 2) — обычная правка, когда строгий режим отбрасывает эти пакеты.
Когда активны два туннеля, помечайте каждый поток на входе и позвольте метке выбрать таблицу. Правило, которое смотрит только на входной интерфейс, отправляет трафик обоих туннелей в одну таблицу, поэтому второй туннель крадёт потоки у первого. Проверьте эту метку соединением, которое переживает переподключение, потому что именно тогда проявляется смешанная политика.
Решайте по принадлежности и по тому, что записывает дальняя сторона
Если туннель заканчивается у провайдера, используйте маскарадинг. Этот оператор не будет маршрутизировать ваши частные диапазоны LAN, и у него нет причин различать отдельных клиентов за вашим шлюзом. Один видимый партнёр — единственная модель, которую поддерживает его политика, поэтому дайте ему это и держите трансляцию на своей стороне. Провайдер видит одного партнёра, что именно и ожидает его политика, а ваши клиенты наследуют эту единственную идентичность.
Если оба конца ваши и удалённые службы действуют по адресам источника, маршрутизация по политике заслуживает своего дополнительного маршрута. Тогда правила межсетевого экрана, доступ по пользователям и журналы аудита могут различать клиентов. Если дальней стороне нужна только достижимость, маскарадинг проще и убирает целый класс ошибок обратного маршрута.
Гибридные решения нормальны: маршрутизация по политике внутри вашей сети, маскарадинг на краю у провайдера. Важно записать, какой хоп переводит, а какой маршрутизирует, потому что случайное правило NAT, добавленное для одного клиента, скрывает источник для каждого клиента в той же цепочке.
Проверьте с одного клиента, затем со второго клиента
Запустите тест там, где начинается трафик. Проверьте маршрут, который использует узел, посмотрите, как пакет появляется на интерфейсе туннеля, и загляните в conntrack ради трансляции. Эта последовательность доказывает, что пакет пошёл по нужному пути, а не просто куда-то прибыл.
Повторите тест после переподключения. Правило маскарадинга, называющее интерфейс, переживает новый адрес туннеля; правило, называющее старый адрес, не переживает. Затем проверьте второй узел LAN, потому что решение, работающее на одной машине, часто зависит от собственного маршрута этой машины, а не от политики шлюза.
Запишите выбранную модель, переведённый или сохранённый источник и владельца обратного маршрута в заметки шлюза. Иначе следующий человек, добавляющий клиента или туннель, будет гадать, а догадка — это путь, которым работающая схема LAN-в-VPN становится частичной.