Hoe't in iepenbiere proxy fia in VPN by in privee oarsprong komt

In webside fia in tunnel publisearje en brûkers VPN-toegong jaan binne twa ferskillende regelingen dy't ien kabel diele. Yn 'e earste akseptearret in iepenbiere omkearde proxy it fersyk fan 'e besiker en stjoert it fia de tunnel nei in oarsprong dy't nimmen direkt berikke kin. Yn 'e twadde moat de brûker by de VPN komme foardat de applikaasje hielendal berikber is. It mingen fan de twa beskriuwings is hoe't in privee backend úteinlik iepenbier bleatsteld wurdt.

Twa modellen dy't op in diagram itselde lykje

Tekenje de pylken foardat jo eat kieze. In iepenbier publikaasjemodel giet fan browser nei proxy oer HTTPS, dan fan proxy nei oarsprong fia de tunnel, en de oarsprong akseptearret nea in ferbining fan it ynternet. In allinne-VPN-model giet fan klant nei poarte, en de applikaasje is allinne fan binnen dat paad berikber. De laptop fan 'e brûker sit op itselde netwurk as de applikaasje, en dat is it hiele punt fan dat model.

De modellen ferskille yn wa't autentisearret en wêr. Yn 'e earste is de proxy de iepenbiere yngong en it stjoert elk fersyk troch dat oankomt, ek in fijannich, ûnder it belied dat dêrop konfigurearre is. Yn 'e twadde is berikberens sels de poarte, wat grof mar wier tagong is.

Wêr't TLS ophâldt, en wat it eins bewiist

TLS tusken browser en proxy beskermet dy sprong en lit de browser de side ferifiearje dy't er fan doel wie te besykjen. As de proxy TLS beëiniget, bestiet it fersyk yn lêsbere foarm yn dat proses foardat it trochstjoerd wurdt. In twadde TLS-sesje nei de oarsprong kin de folgjende sprong beskermje en it einpunt fan 'e applikaasje apart ferifiearje. Gjin fan beide sesjes beslút hokker minske de applikaasje brûke mei. In wildcard-sertifikaat op 'e proxy rikt ek net nei dy twadde sprong.

Dit is it diel dat minsken yn it wurd fersifere gearfetsje. Fertroulikheid, yntegriteit en serveridentiteit binne transporteigenskippen; autorisaasje is in applikaasjebeslút. In privee adres efter in tunnel feroaret wa't de sok berikke kin, net wa't oanmelde mei as se it dogge.

Fertrou op trochstjoerde kopteksten allinne fan de proxy

Applikaasjes dy't logge of autorisearje op it klantadres lêze meastentiids in koptekst dy't de proxy taheakket. Dy koptekst is gewoan tekst, dus alles wat de oarsprong direkt berikke kin, kin elk adres beweare dat it wol. Behein de oarsprong sa dat allinne it tunneladres fan 'e proxy ferbine mei, en konfigurearje de applikaasje om de koptekst allinne fan dat adres te akseptearjen.

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

As dat fersyk slagget fan in host dat net de proxy is, fertrout de oarsprong in koptekst dy't er negearje moatte soe. Reparearje de listener foardat jo de applikaasje oanreitsje. In wegering is in folle better resultaat as in logrigel mei in ferfalske adres.

Hâld de oarsprong berikber fan krekt ien plak

Byn de listener fan 'e oarsprong oan it tunneladres of skerm it ôf mei in firewall nei de proxy, en befêstigje dan wat eins harket. In tsjinst dy't mei in wildcard-binding start is, akseptearret ferbiningen op elk ynterface dat de host hat, ek ien dy't jo fergetten binne dat it routber is. De harketabel is de grûnwiere, net it konfiguraasjebestân dat jo fan doel wiene te brûken. As de wildcard-binding opsetlik is, moat de firewall noch hieltyd it ûnderdiel wêze dat it ferneaut.

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

Doch deselde beoardieling foar behearynterfaces, dat binne de gewoane tafallige bleatstelling. Skriuw dan de twa modellen apart op: de iepenbiere side fia de proxy, en it behearynterface dat allinne fia de tunnel berikber is. De sin dat de server efter in VPN sit, seit dêr neat fan.