VPN-kliendi aadressi hoidmine kuni rakenduseni muudab iga logirea ja iga lubatud aadresside loendi kirje sama tähendusega. Selle ümberkirjutamine pilve servas teeb marsruutimistabeli lihtsamaks ja logid vähem kasulikuks. Kumbki valik ei ole iseenesest vale ja selle üle otsustav argument puudutab harva jõudlust. Kolm tingimust otsustavad: kas rakendus peab teadma, milline inimene ühendus, kas pilve struktuur võtab vastu allika, mille kavatsete saata, ja kes on hiljem nõus tagasitee eest vastutama.

Kolm tingimust otsustavad

Alustage rakenduse nõudest, mitte võrgudiagrammist. Kui autoriseerimine või audit sõltub üksiku kliendi aadressist, on selle säilitamine funktsionaalne nõue ja tõlkimine regressioon. Kui rakendus peab vaid teadma, et liiklus saabus kaugjuurdepääsu teed, piisab tõlgitud aadressist ja see on palju odavam käitada.

Teine tingimus on mehaaniline. Virtuaalvõrk ei usalda automaatselt paketti, mis väidab aadressi, mida saatevale liidesele ei määratud. Enamik pilvestruktuure rakendab seda erineval viisil ja erinevate nimede all ning disain, mis seda eirab, näeb diagrammil õige välja ja kaob tootmises vaikselt.

Kolmas on korralduslik. Allikate säilitamine tähendab, et rakenduse alamvõrgu marsruutimistabel peab kliendi prefiksi jaoks osutama tagasi lüüsile, ja iga meeskond, kes hiljem alamvõrgu lisab, peab selle marsruudi kooskõlas hoidma. See on ühekordne väike kulu ja korduv kulu kümnete kontode lõikes. Otsustage, kes selle maksab, enne kui käitumise lubate.

Marsruut ei ole luba võltsida

Tagasitee lisamine ütleb teie alamvõrgule, kuhu vastused peavad minema. See ei ütle struktuurile, et neid pakette edastav eksemplar tohib neid saata võõra allikaga. AWS-is on asjakohane kontroll allika ja sihtkoha kontroll ning see on nähtav iga eksemplari kohta:

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

Lülitage see välja ainult eksemplaril, mille dokumenteeritud töö on edastamine, ja mitte millelgi muul. Iga rakenduse VM, mis jätab kontrolli sisse, on üks masin vähem, mida saab kasutada liikluse saatmiseks laenatud allikaga. Kui teie platvorm ei ole AWS, otsige vastavat anti-spoofingi või lubatud aadresside seadet, selle asemel et eeldada, et käitumine kandub üle.

Kiire paketipüük lahendab küsimuse kiiremini kui konsooli lugemine. Kui vastused väljuvad ja klient ei näe neid kunagi, jätab struktuur võltsitud allika kõrvale, mitte rakendus ei ebaõnnestu.

Mida tõlkimine ostab ja mida see maksab

Allika ümberkirjutamine lüüsil kaotab tagasitee probleemi. Rakendus näeb ühte aadressi, milleni see juba oskab jõuda, ja kliendi prefiks ei pea kunagi pilve marsruutimistabelisse ilmuma. Linuxis on reegel üks rida ja tasub kirjutada kitsaim versioon, mille suudate:

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

Pange tähele, mida rakendus nüüd salvestab: 10.40.3.10 iga kasutaja kohta, igal ühendusel, igavesti. Iga sellel väärtusel põhinev aadresside lubatud loend annab nüüd juurdepääsu kogu kaugjuurdepääsu populatsioonile ja iga intsidendi ülevaade peab lüüsi juurde tagasi minema, et vastata, kes see oli.

Lahendus ei ole tõlkimisest loobuda, vaid lõpetada teesklemine, et aadress on identiteet. Kandke kliendi identiteeti autenditud väljas, logige see lüüsil koos tõlgitud korteežiga ja laske rakendusel selle järgi liituda. Ilma liitumisvõtmeta muudab tõlkimine võrguprobleemi püsivaks kriminalistlikuks probleemiks.

Relee on teine liides

Rakenduse ees olev pöördproksi möödub marsruuditud tee küsimusest täielikult. Proksi avab omaenda taustsüsteemi ühenduse, nii et kliendi prefiks ei pea kunagi virtuaalvõrgus marsruuditav olema, ja rakendus saab identiteedi proksi seatud päises.

See päis on usaldusväärne ainult siis, kui taustsüsteem võtab selle vastu proksilt ja mitte millestki muust. Nginx-i mõistes tähendab see usaldusväärse partneri selget nimetamist, selle asemel et uskuda kõike, mis saabub:

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

Iga klient, kes pääseb taustsüsteemile otse ligi, saab sama päise võltsida, seega peab taustsüsteem olema kättesaamatu väljaspool proksit. See on tulemüüri fakt, mitte konfiguratsiooni arvamus, ja just selle eelduse jätavad inimesed vahele, kui nad lõiku kopeerivad.

Relee muudab ka seda, mida ostate. Saate rakendustasandi identiteedi ja loomuliku koha selle logimiseks; loobute üldistusest, sest iga uus protokoll vajab oma proksitoe. HTTP-teenuste jaoks on see vahetus tavaliselt hea ja millelegi, mis ei ole HTTP, ei ole see tavaliselt üldse saadaval.

Kirjutage üles, mida iga piir näeb

Mida iganes te valite, disainiülevaade peaks lõppema ühe tabeliga, mis nimetab allika aadressi ja tõendatava identiteedi igal hüppel. Ilma selleta tekitab esimene intsident kolm meeskonda, kes igaüks kirjeldab erinevat klienti.

BoundarySource the next hop seesWhat is actually proven
Client to gateway172.20.8.14A certificate or credential was presented
Gateway to app subnet, preserved172.20.8.14The same session, if the return route exists
Gateway to app subnet, translated10.40.3.10Only that traffic came through the gateway
Proxy to backend10.40.3.10 plus a headerThe proxy asserted an identity it authenticated

Siis valige. Säilitage allikas, kui rakenduse autoriseerimine sõltub tõesti kliendi aadressist ja suudate marsruudi enda kanda võtta. Tõlkige, kui see nii ei ole ja suudate identiteeti riba väliselt kanda, ning kasutage AWSi edastavate eksemplaride juhist platvormipõhiste edastusseadete jaoks. Pöörduge relee poole, kui teenus räägib HTTP-d ja soovite, et identiteet lakkaks olemast aadress.

Seotud artiklid