Hogyan ér el egy nyilvános proxy egy privát origót VPN-en keresztül

Egy webhely alagúton keresztüli közzététele és a felhasználók VPN-hozzáférése két különböző elrendezés, amelyek ugyanazt a kábelt osztják. Az elsőben egy nyilvános fordított proxy fogadja a látogató kérését, és továbbítja az alagúton keresztül egy origóhoz, amelyet senki nem érhet el közvetlenül. A másodikban a felhasználónak csatlakoznia kell a VPN-hez, mielőtt az alkalmazás egyáltalán elérhetővé válik. A két leírás összekeverése az az út, amelyen egy privát backend végül nyilvánosan kitetté válik.

Két modell, amelyek ugyanúgy néznek ki egy diagramon

Rajzolja meg a nyilakat, mielőtt bármit választana. A nyilvános közzétételi modell a böngészőtől a proxyig megy HTTPS-en, majd a proxytól az origóig az alagúton keresztül, és az origó soha nem fogad kapcsolatot az internetről. A csak VPN-es modell a klienstől az átjáróig megy, és az alkalmazás csak ezen az útvonalon belülről érhető el. A felhasználó laptopja ugyanazon a hálózaton van, mint az alkalmazás, és ez a modell egész értelme.

A modellek abban különböznek, ki hitelesít és hol. Az elsőben a proxy a nyilvános belépés, és minden érkező kérést továbbít, akár ellenségeset is, a rajta beállított házirend szerint. A másodikban maga az elérhetőség a kapu, ami durva, de valódi beengedés.

Hol áll meg a TLS, és mit bizonyít valójában

A böngésző és a proxy közötti TLS védi azt az ugrást, és lehetővé teszi a böngészőnek, hogy ellenőrizze a webhelyet, amelyet meg akart látogatni. Ha a proxy lezárja a TLS-t, a kérés olvasható formában létezik azon folyamaton belül, mielőtt továbbítanák. Egy második TLS-munkamenet az origó felé védheti a következő ugrást, és külön ellenőrizheti az alkalmazás végpontját. Egyik munkamenet sem dönti el, melyik ember használhatja az alkalmazást. A proxyn lévő helyettesítő karakteres tanúsítvány sem terjed ki arra a második ugrásra.

Ez az a rész, amelyet az emberek a titkosított szóba sűrítenek. A bizalmasság, a sértetlenség és a kiszolgáló identitása átviteli tulajdonságok; az engedélyezés az alkalmazás döntése. Az alagút mögötti privát cím megváltoztatja, ki érheti el a socketet, nem azt, hogy ki jelentkezhet be, miután elérte.

Csak a proxytól érkező továbbított fejlécekben bízzon

Azok az alkalmazások, amelyek az ügyfél címe alapján naplóznak vagy engedélyeznek, általában azt a fejlécet olvassák, amelyet a proxy hozzáad. Az a fejléc csak szöveg, ezért bármi, ami közvetlenül eléri az origót, bármilyen címet állíthat. Korlátozza az origót, hogy csak a proxy alagútcíme csatlakozhasson, és állítsa be az alkalmazást, hogy a fejlécet csak erről a címről fogadja el.

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

Ha ez a kérés olyan gazdagépről sikerül, amely nem a proxy, az origó olyan fejlécben bízik, amelyet figyelmen kívül kellene hagynia. Javítsa meg a listenert, mielőtt hozzányúl az alkalmazáshoz. Az elutasítás sokkal jobb eredmény, mint egy hamisított címet hordozó naplósor.

Tartsa az origót pontosan egy helyről elérhetővé

Kösse az origó listenerét az alagútcímhez, vagy zárja le tűzfallal a proxy felé, majd erősítse meg, mi hallgat valójában. A helyettesítő karakteres kötéssel indított szolgáltatás minden olyan interfészen fogad kapcsolatot, amellyel a gazdagép rendelkezik, beleértve azt is, amelyről elfelejtette, hogy útvonalazható. A hallgató táblázat az alapigazság, nem az a konfigurációs fájl, amelyet alkalmazni akart. Ha a helyettesítő karakteres kötés szándékos, a tűzfalnak akkor is annak az összetevőnek kell lennie, amely szűkíti.

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

Ugyanezt a felülvizsgálatot végezze el a felügyeleti interfészeknél, amelyek a szokásos véletlen kitettség. Ezután írja le a két modellt külön: a nyilvános webhelyet a proxyn keresztül, és a felügyeleti interfészt, amely csak az alagúton keresztül érhető el. Az a mondat, hogy a kiszolgáló VPN mögött van, semmit sem mond ezekről.