IP-Adresse vu VPN-Clienten um Cloudrand behalen oder mat SNAT iwwersetzen

D'Adress vum VPN-Client bis an d'Applikatioun ze behalen mécht, datt all Logzeil an all Andrag an der Erlaabneslëscht datselwecht bedeiten. Se um Cloudrand nei ze schreiwen mécht d'Routingtabell méi einfach an d'Loge manner nëtzlech. Keng vun den zwou Wielméiglechkeeten ass fir sech eleng falsch, an d'Argument dat se entscheet geet selten ëm Leeschtung. Dräi Konditioune maachen et aus: ob d'Applikatioun muss wëssen, wéi Mënsch sech verbonnen huet, ob de Cloudstoff d'Quell akzeptéiert, déi Dir wëllt schécken, a wien duerno d'Réckwee-Verantwortung wëllt iwwerhuelen.

Dräi Konditioune maachen et aus

Fänkt mat der Fuerderung vun der Applikatioun un, net mam Netzwierkdiagramm. Wann d'Autorisatioun oder d'Audit vun der individueller Clientadress ofhänkt, dann ass hire Behale eng funktional Fuerderung an d'Iwwersetze ass e Rückschrëtt. Wann d'Applikatioun just muss wëssen, datt den Trafik iwwer de Fernzougangswee ukomm ass, da genüügt eng iwwersat Adress a si ass vill méi bëlleg ze bedreiwen.

Déi zweet Konditioun ass mechanesch. En virtuelle Netzwierk vertraut net automatesch engem Pak, deen eng Adress behaapt, déi net un d'sendend Interface zougewisen ass. Déi meescht Cloudstoffer forcéieren dat, op verschidde Manéieren an ënner verschidden Nimm, an en Design, deen et ignoréiert, wäert am Diagramm richteg ausgesinn an a Produktioun stille verluer goen.

Déi drëtt ass organisatoresch. Quell behalen heescht, datt d'Routingtabell vum Applikatiounssubnetz fir de Clientprefix op de Gateway zréck weise muss, an all Team, deen duerno e Subnetz bäisetzt, muss déi Route konsequent halen. Dat ass eng kleng Kéier e klengen Opwand an en erëmkommenen Opwand iwwer Dosen vu Konten. Entscheet, wien en dréit, ier Dir d'Verhalen versprécht.

Eng Route ass keng Erlaabnes ze spoofen

Eng Réckroute bäisetzen seet Ärem Subnetz, wou d'Äntwerten hige sollte. Et seet dem Stoff net, datt d'Instanz, déi déi Päck weiderleet, se mat enger friemer Quell däerf ausgaben. Op AWS ass déi relevant Kontroll d'Quell- an Destinatiounspréifung, an si ass pro Instanz siichtbar:

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

Schalt se just fir d'Instanz aus, där hir dokumentéiert Aarbecht d'Weiderleeden ass, an fir näischt anescht. All Applikatiouns-VM, déi d'Préifung ugedréckt léisst, ass eng Maschinn manner, déi ka benotzt ginn, fir Trafik mat enger geléinter Quell auszeginn. Wann Är Plattform net AWS ass, sicht d'entspriechend Anti-Spoofing- oder Erlaabnesadress-Astellungen, amplaz unzehuelen, datt d'Verhalen sech iwwerdréit.

Eng séier Pakopnam entscheet d'Fro méi séier wéi d'Konsole liesen. Wann d'Äntwerten erausgoen an de Client se ni gesäit, dann ass et de Stoff, deen déi gefälscht Quell verwerft, an net d'Applikatioun, déi feelt.

Wat d'Iwwersetzung keeft, a wat se kascht

D'Quell um Gateway nei schreiwen eliminéiert de Problem vum Réckwee. D'Applikatioun gesäit eng Adress, déi se schonn erräiche kann, an de Clientprefix muss ni an enger Cloud-Routingtabell erschéngen. Op Linux ass d'Reegel eng Zeil, an et ass derwäert déi schmuelst Versioun ze schreiwen, déi Dir kënnt:

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

Passt op wat d'Applikatioun elo ophëlt: 10.40.3.10 fir all Benotzer, op all Verbindung, fir ëmmer. All Adress-Erlaabneslëscht, déi op deem Wäert opgebaut ass, gëtt elo Zougang fir déi ganz Fernzougangspopulatioun, an all Incident-Révisionn muss op de Gateway zréckgoen, fir ze äntweren, wien dat war.

D'Léisung ass net d'Iwwersetzung opzeginn, si ass ophéieren ze maachen, wéi wann d'Adress eng Identitéit wier. Droen d'Clientidentitéit an engem authentifizéierte Feld, loggt se um Gateway zesumme mam iwwersaten Tuple, a loosst d'Applikatioun drop joinen. Ouni de Join-Schlëssel verwandelt d'Iwwersetzung e Netzwierkproblem an e permanente forensesche Problem.

De Relais ass eng aner Interface

En ëmgekehrte Proxy virun der Applikatioun ëmgeet d'Fro vum gerouteten Wee komplett. De Proxy mécht seng eege Backendverbindung op, sou datt de Clientprefix ni bannent dem virtuelle Netzwierk muss routbar sinn, an d'Applikatioun kann d'Identitéit an engem Header empfänken, deen de Proxy setzt.

Dee Header ass just dann vertrauenswierdeg, wann de Backend en vum Proxy an aus näischt anescht akzeptéiert. An nginx-Termen heescht dat, de vertrauenswierdege Peer explizit ze nennen, amplaz ze gleewen, wat och ëmmer ukommt:

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

All Client, deen de Backend direkt erräiche kann, kann deen selwechten Header fälschen, also muss de Backend onerräichbar sinn ausser iwwer de Proxy. Dat ass eng Firewall-Tatsaach, keng Konfiguratiounsmeinung, an et ass déi Unhuel, déi d'Leit iwwersprangen, wann se de Schnipsel kopéieren.

De Relais ännert och, wat Dir kaaft. Dir kritt eng Identitéit op Applikatiounsniveau an eng natierlech Plaz, se ze loggen; Dir gitt d'Allgemengheet op, well all neit Protokoll seng eege Proxy-Ënnerstëtzung brauch. Fir HTTP-Servicer ass deen Tausch meeschtens gutt, an fir alles, wat net HTTP ass, ass en meeschtens guer net verfügbar.

Schreift op, wat all Grenz gesäit

Wat Dir och wielt, d'Design-Révisionn soll mat enger Tabell ophalen, déi d'Quelladress an d'beweisbar Identitéit op all Sprong nennt. Ouni si produzéiert den éischten Incident dräi Teamen, déi all en anere Client beschreiwen.

Dann wielt. Behale wann d'Autorisatioun vun der Applikatioun wierklech vun der Clientadress ofhänkt an Dir d'Route kënnt droen. Iwwersetzt wann dat net de Fall ass an Dir d'Identitéit baussent Band kënnt droen, a benotzt d'AWS-Uleedung fir Weiderlee-Instanzen fir déi platfomsspezifesch Weiderlee-Astellungen. Gräift zu engem Relais, wann de Service HTTP schwätzt an Dir wëllt, datt d'Identitéit guer keng Adress méi ass.