Сохранять IP-адреса клиентов VPN или применять SNAT на границе облака

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

Решают три условия

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

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

Третье условие организационное. Сохранение источников означает, что таблица маршрутизации подсети приложения должна указывать обратно на шлюз для префикса клиента, и каждая команда, которая позже добавит подсеть, должна поддерживать этот маршрут согласованным. Это небольшие затраты один раз и повторяющиеся затраты на десятки аккаунтов. Решите, кто платит, прежде чем обещать такое поведение.

Маршрут не является разрешением на подмену

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

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Отключите её только для экземпляра, чья документированная работа пересылка, и ни для чего другого. Каждая виртуальная машина приложения, оставляющая проверку включённой, это на одну машину меньше, которую можно использовать для отправки трафика с чужим источником. Если ваша платформа не AWS, ищите эквивалентную настройку анти-спуфинга или разрешённых адресов, а не предполагайте, что поведение перенесётся.

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

Что покупает трансляция и сколько она стоит

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

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

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

Ретранслятор это другой интерфейс

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

Этот заголовок заслуживает доверия только тогда, когда бэкенд принимает его от прокси и ни от чего другого. В терминах nginx это означает явно назвать доверенного партнёра вместо того, чтобы верить всему, что приходит:

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

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

Ретранслятор также меняет то, что вы покупаете. Вы получаете личность на уровне приложения и естественное место, где её записывать; вы отказываетесь от универсальности, потому что каждому новому протоколу нужна собственная поддержка прокси. Для служб HTTP этот обмен обычно хорош, а для всего, что не является HTTP, обычно вовсе недоступен.

Запишите, что видит каждая граница

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

Затем выберите. Сохраняйте, когда авторизация приложения действительно зависит от адреса клиента и вы можете взять маршрут на себя. Транслируйте, когда это не так и вы можете нести личность вне полосы, и используйте руководство AWS по экземплярам пересылки для специфичных для платформы настроек пересылки. Прибегайте к ретранслятору, когда служба говорит по HTTP и вы хотите, чтобы личность вообще перестала быть адресом.