Запазване или SNAT на IP адресите на VPN клиентите на границата на облака

Запазването на адреса на 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

Изключете я само за инстанцията, чиято документирана работа е препращане, и за нищо друго. Всяка VM за приложения, която оставя проверката включена, е с една машина по-малко, която може да се използва за изпращане на трафик с взет назаем източник. Ако платформата ви не е 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 и искате идентичността да престане да бъде адрес.