Зачувајте или 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 за секој корисник, на секое поврзување, засекогаш. Секој список на дозволени адреси изграден врз таа вредност сега дава пристап до целата популација на далечински пристап, и секоја ревизија на инцидент мора да се врати кај портата за да одговори кој беше тоа.

Решението не е да се откажеме од преведувањето, туку да престанеме да се преправаме дека адресата е идентитет. Носете го идентитетот на клиентот во автентицирано поле, запишете го кај портата заедно со преведената торка и оставете апликацијата да се поврзе на неа. Без клучот за поврзување, преведувањето претвора мрежен проблем во постојан форензички.

Релето е друг интерфејс

Обратниот прокси пред апликацијата целосно го заобиколува прашањето за рутираниот пат. Проксито отвора своја сопствена backend врска, така што префиксот на клиентот никогаш не мора да биде рутирачки внатре во виртуелната мрежа, и апликацијата може да прими идентитет во заглавие што го поставува проксито.

Тоа заглавие е доверливо само кога backend-от го прифаќа од проксито и од ништо друго. Во термини на nginx тоа значи експлицитно да се именува доверливиот партнер наместо да се верува на се што ќе пристигне:

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

Секој клиент што може директно да го достигне backend-от може да го фалсификува истото заглавие, затоа backend-от мора да биде недостапен освен преку проксито. Тоа е факт за огнениот ѕид, не мислење за конфигурацијата, и токму таа претпоставка луѓето ја прескокнуваат кога го копираат фрагментот.

Релето исто така го менува она што го купувате. Добивате идентитет на ниво на апликација и природно место да го запишете; се откажувате од општоста, бидејќи секој нов протокол бара своја поддршка за прокси. За HTTP услуги таа размена обично е добра, а за се што не е HTTP обично воопшто не е достапна.

Запишете што гледа секоја граница

Што и да изберете, прегледот на дизајнот треба да заврши со една табела што ја именува изворната адреса и докажливиот идентитет на секој скок. Без неа првиот инцидент произведува три тима, од кои секој опишува различен клиент.

Потоа изберете. Зачувајте го изворот кога авторизацијата на апликацијата навистина зависи од клиентската адреса и можете да ја преземете рутата. Преведувајте кога тоа не е случај и можете да го носите идентитетот надвор од опсегот, и користете упатството на AWS за препраќачки инстанци за поставките за препраќање специфични за платформата. Посегнете по реле кога услугата зборува HTTP и сакате идентитетот воопшто да не биде адреса.