Захоўваць 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

Адключыце гэта для інстанцы, чыя дакументаваная задача — перасылка, і ні для чаго іншага. Кожная 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 і вы хочаце, каб ідэнтычнасць перастала быць адрасам зусім.