Bewarje as SNAT de IP's fan VPN-klanten by de wolkrâne

It adres fan de VPN-klant oant de applikaasje bewarje makket dat elke logrigel en elk item yn 'e tastienlist itselde betsjutte. It by de wolkrâne oerskriuwe makket de rûtetabel ienfâldiger en de logs minder nuttich. Gjin fan beide karren is op himsels ferkeard, en it argumint dat it beslist giet selden oer prestaasjes. Trije betingsten beslisse it: oft de applikaasje witte moat hokker minske ferbûn wie, oft de wolkstruktuer de boarne akseptearret dy't jo stjoere wolle, en wa't dernei de weromrûte op him nimme wol.

Trije betingsten beslisse it

Begjin by de eask fan de applikaasje, net by it netwurkdiagram. As autorisaasje of audit fan it yndividuele klantadres ôfhinget, dan is it bewarjen dêrfan in funksjonele eask en is oersetting in regresje. As de applikaasje allinnich witte moat dat ferkear fia it paad foar fêste tagong oankaam, is in oerset adres genôch en folle goedkeaper te betsjinjen.

De twadde betingst is meganysk. In firtueel netwurk fertrout net automatysk in pakket dat in adres beweart dat net oan 'e stjoerende ynterface tawiisd is. De measte wolkstruktueren twinge dat ôf, op ferskate manieren en ûnder ferskate nammen, en in ûntwerp dat it negearret sil der op in diagram goed út sjen en yn produksje stil ferdwine.

De tredde is organisatoarysk. Boarnen bewarje betsjut dat de rûtetabel fan 'e applikaasjesubnet foar it klantprefiks werom nei de gateway wize moat, en elk team dat letter in subnet tafoeget moat dy rûte konsekwint hâlde. Dat is ien kear in lytse kosten en in weromkommende kosten oer tsientallen akkounts. Beslis wa't it betellet foardat jo it gedrach taseine.

In rûte is gjin tastimming om te spoofjen

In weromrûte tafoegje fertelt jo subnet wêr't antwurden hinne moatte. It fertelt de struktuer net dat de ynstânsje dy't dy pakketten trochstjoert se mei in frjemde boarne útstjoere mei. By AWS is de relevante kontrôle boarne- en bestimmingkontrôle, en dy is per ynstânsje sichtber:

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

Skeakelje dat allinnich út foar de ynstânsje waans dokumintearre wurk trochstjoeren is, en foar neat oars. Eltse applikaasje-VM dy't de kontrôle oanlitten hâldt is ien masine minder dy't brûkt wurde kin om ferkear mei in liende boarne út te stjoeren. As jo platfoarm gjin AWS is, sykje dan de lykweardige ynstelling foar anty-spoofing of tastiene adressen ynstee fan oan te nimmen dat it gedrach oerdraacht.

In flugge pakketopname besliset de fraach flugger as it lêzen fan 'e konsole. As antwurden fuortgeane en de klant se nea sjocht, dan is it de struktuer dy't de ferfalske boarne fuortsmyt, en net de applikaasje dy't falt.

Wat oersetting keapet, en wat it kostet

De boarne by de gateway oerskriuwe lit it probleem fan 'e weromweis ferdwine. De applikaasje sjocht ien adres dat se al ken hoe't se it berikke moat, en it klantprefiks hoecht nea yn in wolkrûtetabel te ferskinen. Op Linux is de regel ien rigel, en it is de muoite wurdich de smelste ferzje te skriuwen dy't jo kinne:

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

Tink derom wat de applikaasje no fêstleit: 10.40.3.10 foar elke brûker, by elke ferbining, foar altyd. Eltse adres-tastienlist boud op dy wearde jout no tagong oan 'e hiele populaasje foar fêste tagong, en elke ynsidebarrens moat werom nei de gateway om te beantwurdzjen wa't dit wie.

De oplossing is net oersetting opjaan, it is ophâlde te dwaan as is it adres in identiteit. Drage de identiteit fan 'e klant yn in autentisearre fjild, log it by de gateway tegearre mei it oersette tuple, en lit de applikaasje dêrop joinje. Sûnder de joinskaai makket oersetting in netwurkprobleem ta in permanint forensysk probleem.

De relais is in oare ynterface

In omkearde proxy foar de applikaasje hinne giet de fraach fan it rûtearre paad hielendal foarby. De proxy iepenet syn eigen backendferbining, sadat it klantprefiks nea yn it firtuele netwurk rûteber wêze hoecht, en de applikaasje kin identiteit ûntfange yn in kop dy't de proxy set.

Dy kop is allinnich betrouber as de backend him fan 'e proxy akseptearret en fan neat oars. Yn nginx-termen betsjut dat it fertroude pear eksplisyt neame ynstee fan te leauwen wat der ek oankomt:

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

Elke klant dy't de backend direkt berikke kin, kin deselde kop ferfalskje, dus de backend moat ûnberikber wêze útsein fia de proxy. Dat is in feit oer de firewall, gjin miening oer konfiguraasje, en it is de oanname dy't minsken oerslaan as se it stikje kopiearje.

De relais feroaret ek wat jo keapje. Jo krije in identiteit op applikaasjenivo en in natuerlike plak om dy te loggen; jo jouwe algemienens op, want elk nij protokol hat syn eigen proxy-stipe nedich. Foar HTTP-tsjinsten is dy ruil meastentiids goed, en foar alles dat gjin HTTP is is it meastentiids hielendal net beskikber.

Skriuw op wat elke grins sjocht

Wat jo ek kieze, de ûntwerpreview moat einigje mei ien tabel dy't it boarneadres en de bewiisbere identiteit by elke hop neamt. Sûnder dy tabel produsearret it earste ynsidint trije teams dy't elk in oare klant beskriuwe.

Kies dan. Bewarje as de autorisaasje fan 'e applikaasje wier fan it klantadres ôfhinget en jo de rûte op jimme nimme kinne. Oerset as dat net sa is en jo identiteit bûten it bân drage kinne, en brûk de AWS-riglynen foar trochstjoerynstânsjes foar de platfoarmspecifike trochstjoerynstellingen. Griip nei in relais as de tsjinst HTTP praat en jo wolle dat identiteit hielendal ophâldt in adres te wêzen.