Ruaj ose apliko SNAT në IP-të e klientëve VPN në kufirin e cloud-it

Ruajtja e adresës së klientit VPN deri në aplikacion bën që çdo rresht log dhe çdo hyrje në listën e lejuar të nënkuptojnë të njëjtën gjë. Rishkrimi i saj në kufirin e cloud-it e bën tabelën e rrugëtimit më të thjeshtë dhe log-et më pak të dobishme. Asnjëra nga dy zgjedhjet nuk është e gabuar në vetvete, dhe argumenti që e vendos rrallë ka të bëjë me performancën. Tre kushte e vendosin: nëse aplikacioni duhet të dijë se cili njeri u lidh, nëse pëlhura e cloud-it do të pranojë burimin që synoni të dërgoni, dhe kush do të marrë përsipër përgjegjësinë për rrugën e kthimit më pas.

Tre kushte e vendosin

Filloni me kërkesën e aplikacionit, jo me diagramin e rrjetit. Nëse autorizimi ose auditimi varen nga adresa individuale e klientit, ruajtja e saj është kërkesë funksionale dhe përkthimi është regres. Nëse aplikacioni duhet të dijë vetëm se trafiku erdhi përmes rrugës së aksesit në distancë, një adresë e përkthyer mjafton dhe është shumë më e lirë për t'u operuar.

Kushti i dytë është mekanik. Një rrjet virtual nuk i beson automatikisht një pakete që pretendon një adresë që nuk i është caktuar ndërfaqes dërguese. Shumica e pëlhurave të cloud-it e imponojnë këtë, në mënyra dhe emra të ndryshëm, dhe një dizajn që e injoron do të duket i saktë në diagram dhe do të bjerë në heshtje në prodhim.

I treti është organizativ. Ruajtja e burimeve do të thotë që tabela e rrugëtimit e nënrrjetit të aplikacionit duhet të tregojë prapa drejt portës për prefiksin e klientit, dhe çdo ekip që shton më vonë një nënrrjet duhet ta mbajë atë rrugë konsistente. Ky është një kosto e vogël një herë, dhe një kosto e përsëritur në dhjetëra llogari. Vendosni kush e paguan para se të premtoni sjelljen.

Rruga nuk është leje për falsifikim

Shtimi i një rruge kthimi i tregon nënrrjetit tuaj ku duhet të shkojnë përgjigjet. Nuk i tregon pëlhurës se instanca që i përcjell ato paketa lejohet t'i emetojë me një burim të huaj. Në AWS kontrolli përkatës është verifikimi i burimit dhe destinacionit, dhe është i dukshëm për çdo instancë:

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

Çaktivizojeni vetëm për instancën, puna e dokumentuar e së cilës është përcjellja, dhe për asgjë tjetër. Çdo VM aplikacioni që e mban verifikimin të ndezur është një makinë më pak që mund të përdoret për të emetuar trafik me një burim të huazuar. Nëse platforma juaj nuk është AWS, kërkoni cilësimin ekuivalent të kundër-falsifikimit ose të adresave të lejuara në vend që të supozoni se sjellja transferohet.

Një kapje e shpejtë paketash e zgjidh çështjen më shpejt sesa leximi i konsolës. Nëse përgjigjet dalin dhe klienti nuk i sheh kurrë, pëlhura është ajo që hedh burimin e falsifikuar, dhe jo aplikacioni që dështon.

Çfarë blen përkthimi dhe sa kushton

Rishkrimi i burimit në portë eliminon problemin e rrugës së kthimit. Aplikacioni sheh një adresë që tashmë di si ta arrijë, dhe prefiksi i klientit nuk duhet të shfaqet kurrë në një tabelë rrugëtimi të cloud-it. Në Linux rregulli është një rresht, dhe ia vlen të shkruani versionin më të ngushtë që mundeni:

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

Vini re çfarë regjistron tani aplikacioni: 10.40.3.10 për çdo përdorues, në çdo lidhje, përgjithmonë. Çdo listë e adresave të lejuara e ndërtuar mbi atë vlerë tani i jep akses të gjithë popullatës së aksesit në distancë, dhe çdo rishikim incidenti duhet të kthehet te porta për t'u përgjigjur kush ishte ky.

Zgjidhja nuk është të heqim dorë nga përkthimi, por të ndalojmë së pretendojmë se adresa është identitet. Mbajeni identitetin e klientit në një fushë të vërtetuar, regjistrojani në portë bashkë me tuple-in e përkthyer, dhe lëreni aplikacionin të bashkohet mbi të. Pa çelësin e bashkimit, përkthimi e kthen një problem rrjeti në një problem të përhershëm forensik.

Releu është një ndërfaqe tjetër

Një proxy i kundërt përpara aplikacionit e shmang plotësisht çështjen e rrugës së rrugëtuar. Proxy ha lidhjen e vet me backend-in, kështu që prefiksi i klientit nuk duhet të jetë kurrë i rrugëtueshëm brenda rrjetit virtual, dhe aplikacioni mund të marrë identitetin në një header që proxy vendos.

Ai header është i besueshëm vetëm kur backend-i e pranon nga proxy dhe nga asgjë tjetër. Në termat e nginx kjo do të thotë të emërtosh në mënyrë eksplicite palën e besuar në vend që të besosh çdo gjë që vjen:

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

Çdo klient që mund të arrijë drejtpërdrejt backend-in mund të falsifikojë të njëjtin header, prandaj backend-i duhet të jetë i paarritshëm përveç përmes proxy. Ky është fakt muri zjarri, jo mendim konfigurimi, dhe pikërisht ky supozim anashkalohet kur njerëzit kopjojnë fragmentin.

Releu ndryshon gjithashtu atë që blini. Merrni një identitet në nivel aplikacioni dhe një vend të natyrshëm për ta regjistruar; hiqni dorë nga përgjithshmëria, sepse çdo protokoll i ri ka nevojë për mbështetjen e vet të proxy. Për shërbimet HTTP ky shkëmbim zakonisht është i mirë, dhe për çdo gjë që nuk është HTTP zakonisht nuk është fare i disponueshëm.

Shkruani çfarë sheh çdo kufi

Çfarëdo që të zgjidhni, rishikimi i dizajnit duhet të përfundojë me një tabelë që emërton adresën e burimit dhe identitetin e provueshëm në çdo hap. Pa të, incidenti i parë prodhon tre ekipe që secili përshkruan një klient tjetër.

Pastaj zgjidhni. Ruani burimin kur autorizimi i aplikacionit varet vërtet nga adresa e klientit dhe mund ta merrni përsipër rrugën. Përktheni kur nuk është kështu dhe mund ta mbani identitetin jashtë brezit, dhe përdorni udhëzimet e AWS për instancat e përcjelljes për cilësimet e përcjelljes specifike për platformën. Kthejuni një releu kur shërbimi flet HTTP dhe dëshironi që identiteti të mos jetë më adresë.