Сачувајте 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 и када желите да идентитет престане да буде адреса.