Hoe 'n publieke instaanbediener deur 'n VPN by 'n private oorsprong uitkom

Om 'n webwerf deur 'n tonnel te publiseer en om gebruikers VPN-toegang te gee, is twee verskillende reëlings wat dieselfde kabel deel. In die eerste aanvaar 'n openbare omgekeerde instaanbediener die besoeker se versoek en stuur dit deur die tonnel na 'n oorsprong wat niemand direk kan bereik nie. In die tweede moet die gebruiker by die VPN aansluit voordat die toepassing hoegenaamd bereikbaar is. Om die twee beskrywings te vermeng, is hoe 'n private agterkant uiteindelik openbaar blootgestel word.

Twee modelle wat op 'n diagram dieselfde lyk

Teken die pyle voordat jy enigiets kies. 'n Openbare publikasiemodel loop van blaaier na instaanbediener oor HTTPS, dan van instaanbediener na oorsprong deur die tonnel, en die oorsprong aanvaar nooit 'n verbinding van die internet nie. 'n Slegs-VPN-model loop van kliënt na poort, en die toepassing is slegs van binne daardie pad bereikbaar. Die gebruiker se skootrekenaar sit op dieselfde netwerk as die toepassing, wat die hele punt van daardie model is.

Die modelle verskil in wie verifieer en waar. In die eerste is die instaanbediener die openbare ingang en dit stuur enige versoek wat aankom deur, ook 'n vyandige een, onderhewig aan die beleid wat daarop ingestel is. In die tweede is bereikbaarheid self die hek, wat grof maar werklike toelating is.

Waar TLS stop, en wat dit werklik bewys

TLS tussen blaaier en instaanbediener beskerm daardie sprong en laat die blaaier die werf verifieer wat hy bedoel het om te besoek. As die instaanbediener TLS beëindig, bestaan die versoek in leesbare vorm binne daardie proses voordat dit deurgestuur word. 'n Tweede TLS-sessie na die oorsprong kan die volgende sprong beskerm en die toepassing se eindpunt afsonderlik verifieer. Nie een van die sessies besluit watter mens die toepassing mag gebruik nie. 'n Wildcard-sertifikaat op die instaanbediener strek ook nie na daardie tweede sprong nie.

Dit is die deel wat mense in die woord geënkripteer saamvat. Vertroulikheid, integriteit en bedieneridentiteit is vervoereienskappe; magtiging is 'n toepassingsbesluit. 'n Private adres agter 'n tonnel verander wie die sok kan bereik, nie wie mag aanmeld sodra hulle dit doen nie.

Vertrou doorgestuurde koptekste net van die instaanbediener

Toepassings wat op die kliëntadres log of magtig, lees gewoonlik 'n koptekst wat die instaanbediener byvoeg. Daardie koptekst is net teks, so enigiets wat die oorsprong direk kan bereik, kan enige adres eis wat hy wil. Beperk die oorsprong sodat net die instaanbediener se tonneladres kan koppel, en stel die toepassing in om die koptekst net van daardie adres te aanvaar.

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

As daardie versoek slaag vanaf 'n gasheer wat nie die instaanbediener is nie, vertrou die oorsprong 'n koptekst wat hy behoort te ignoreer. Maak die luisteraar reg voordat jy aan die toepassing raak. 'n Weiering is 'n veel beter uitkoms as 'n logreël met 'n vervalste adres.

Hou die oorsprong vanaf presies een plek bereikbaar

Bind die oorsprong se luisteraar aan die tonneladres of firewall dit na die instaanbediener, en bevestig dan wat werklik luister. 'n Diens wat met 'n wildcard-binding begin is, aanvaar verbindings op elke koppelvlak wat die gasheer het, ook een wat jy vergeet het roetebaar is. Die luistertabel is die grondwaarheid, nie die konfigurasielêer wat jy bedoel het om toe te pas nie. As die wildcard-binding opsetlik is, moet die firewall steeds die komponent wees wat dit vernou.

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

Doen dieselfde oorsig vir bestuurskoppelvlakke, wat die gewone toevallige blootstelling is. Skryf dan die twee modelle afsonderlik neer: die openbare werf deur die instaanbediener, en die administrasiekoppelvlak wat net deur die tonnel bereikbaar is. Die sin dat die bediener agter 'n VPN is, sê niks daarvan nie.