Два VPN-клиента, два публичных адреса: согласуйте SNAT

Два VPN-клиента могут выходить через два разных публичных IPv4-адреса, и правило, которое это делает, короче, чем ждут большинство. Работает оно не благодаря синтаксису iptables, а благодаря состоянию пакета, когда он достигает цепочки выхода: адрес источника там всё ещё должен различать клиентов. Если более ранний masquerade уже свёл обоих к одному адресу, никакое правило на клиента не восстановит различие. Сначала решите этот вопрос, потом пишите перевод.

Какая идентичность доживает до шлюза

Правило сопоставляется с адресом источника пакета, а не с именем пользователя VPN и не с именем, которое показывает клиентское приложение. Всё, что переводит пакет раньше на пути, определяет, что ваше правило ещё может увидеть. Запустите таблицу nat по порядку и найдите точку, где источник всё ещё отдельный для каждого клиента.

iptables -t nat -S POSTROUTING

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

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

Трансляция не может выдумать адрес

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

На практике это значит проверить маршрутизированный префикс в консоли провайдера, прежде чем трогать межсетевой экран, и использовать адрес частного интерфейса как источник трансляции, когда сопоставление один к одному. Адреса в примерах ниже взяты из диапазонов документации, поэтому первое, что нужно заменить, — сам текст адреса.

Вставьте перед общим masquerade

Подтвердите выходной интерфейс и текущую цепочку, прежде чем что-либо добавлять. Первое определяет, какие пакеты может сопоставить правило, а второе показывает, что уже стоит перед ним.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

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

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

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

Докажите источник новым потоком

Stateful NAT привязывает трансляцию, когда поток начинается, и использует её для последующих пакетов, поэтому сеанс, открытый до изменения, сохраняет старый источник после изменения. Правило доказывает только новое инициированное соединение.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

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

Трансляция по-прежнему не выбирает маршрут, не пропускает поток через фильтр и не публикует входящую службу. Неверный маршрут и отсутствующее правило разрешения продолжают давать сбой и после идеального правила SNAT. Проверьте также IPv6 и любой вторичный путь выхода, затем запишите пары внутренний-к-публичному в документацию межсетевого экрана, чтобы следующее изменение начиналось с сопоставления, а не с текста правила.