Si një proxy publik arrin një origjinë private përmes një VPN

Publikimi i një sajti përmes një tuneli dhe dhënia e aksesit VPN përdoruesve janë dy rregullime të ndryshme që ndajnë të njëjtin kabllo. Në të parin, një proxy i kundërt publik pranon kërkesën e vizitorit dhe e përcjell përmes tunelit drejt një origjine që askush nuk mund ta arrijë drejtpërdrejt. Në të dytin, përdoruesi duhet t'i bashkohet VPN-së përpara se aplikacioni të jetë fare i arritshëm. Përzierja e dy përshkrimeve është mënyra se si një backend privat përfundon i ekspozuar publikisht.

Dy modele që duken njësoj në një diagram

Vizatoni shigjetat përpara se të zgjidhni ndonjë gjë. Një model publikimi publik shkon nga shfletuesi te proxyja përmes HTTPS, pastaj nga proxyja te origjina përmes tunelit, dhe origjina nuk pranon kurrë një lidhje nga interneti. Një model vetëm VPN shkon nga klienti te porta, dhe aplikacioni është i arritshëm vetëm nga brenda asaj rruge. Laptopi i përdoruesit ndodhet në të njëjtin rrjet me aplikacionin, dhe ky është i gjithë qëllimi i atij modeli.

Modelet ndryshojnë në atë se kush vërteton dhe ku. Në të parin, proxyja është hyrja publike dhe përcjell çdo kërkesë që mbërrin, përfshirë një armiqësore, sipas politikës së konfiguruar mbi të. Në të dytin, vetë arritshmëria është porta, e cila është një pranim i trashë por i vërtetë.

Ku ndalon TLS, dhe çfarë vërteton në të vërtetë

TLS midis shfletuesit dhe proxyes mbron atë kërcim dhe i lejon shfletuesit të verifikojë sajtin që synonte të vizitonte. Nëse proxyja e përfundon TLS-në, kërkesa ekziston në formë të lexueshme brenda atij procesi përpara se të përcillet. Një sesion i dytë TLS drejt origjinës mund të mbrojë kërcimin tjetër dhe të verifikojë veçmas pikën fundore të aplikacionit. Asnjëri sesion nuk vendos se cili njeri mund të përdorë aplikacionin. Një certifikatë wildcard mbi proxyen gjithashtu nuk shtrihet në atë kërcim të dytë.

Kjo është pjesa që njerëzit e përmbledhin në fjalën e kriptuar. Konfidencialiteti, integriteti dhe identiteti i serverit janë veti transporti; autorizimi është një vendim i aplikacionit. Një adresë private pas një tuneli ndryshon kush mund të arrijë socket-in, jo kush mund të identifikohet pasi e arrin.

Besoni vetëm header-ave të përcjella nga proxyja

Aplikacionet që regjistrojnë ose autorizojnë sipas adresës së klientit zakonisht lexojnë një header që shton proxyja. Ai header është thjesht tekst, kështu që çdo gjë që mund të arrijë drejtpërdrejt origjinën mund të pretendojë çdo adresë që dëshiron. Kufizoni origjinën në mënyrë që vetëm adresa e tunelit të proxyes të mund të lidhet, dhe konfiguroni aplikacionin të pranojë header-in vetëm nga ajo adresë.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Nëse ajo kërkesë ka sukses nga një host që nuk është proxyja, origjina po i beson një header që do të duhej ta shpërfillte. Rregulloni dëgjuesin përpara se të prekni aplikacionin. Një refuzim është një rezultat shumë më i mirë sesa një rresht log që mban një adresë të falsifikuar.

Mbani origjinën të arritshme nga saktësisht një vend

Lidhni dëgjuesin e origjinës me adresën e tunelit ose rrethojeni me një firewall drejt proxyes, pastaj konfirmoni se çfarë po dëgjon vërtet. Një shërbim i nisur me një lidhje wildcard pranon lidhje në çdo ndërfaqe që ka hosti, përfshirë një që keni harruar se është e rrugëtueshme. Tabela e dëgjimit është e vërteta bazë, jo skedari i konfigurimit që kishit ndërmend të aplikoni. Nëse lidhja wildcard është e qëllimshme, firewalli prapë duhet të jetë komponenti që e ngushton atë.

ss -ltnp | grep -E ':(80|443)'

Bëni të njëjtën rishikim për ndërfaqet e menaxhimit, të cilat janë ekspozimi aksidental i zakonshëm. Pastaj shkruani dy modelet veçmas: sajtin publik përmes proxyes, dhe ndërfaqen e administrimit të arritshme vetëm përmes tunelit. Fjala se serveri është pas një VPN nuk thotë asgjë nga këto.