Како јавни прокси преко VPN-а стиже до приватног извора

Објављивање сајта кроз тунел и давање корисницима приступа VPN-у две су различите поставке које деле исти кабл. У првој јавни обрнути прокси прихвата захтев посетиоца и прослеђује га кроз тунел до извора до ког нико не може да дође директно. У другој корисник мора да се придружи VPN-у пре него што апликација уопште постане доступна. Мешање ова два описа је начин на који приватни backend на крају заврши јавно изложен.

Два модела која на дијаграму изгледају исто

Нацртајте стрелице пре него што било шта изаберете. Модел јавног објављивања иде од прегледача до проксија преко HTTPS-а, затим од проксија до извора кроз тунел, а извор никада не прихвата везу из интернета. Модел само са VPN-ом иде од клијента до мрежног пролаза, а апликација је доступна само изнутра, са те путање. Преносни рачунар корисника налази се на истој мрежи као апликација, и то је цела поента тог модела.

Модели се разликују по томе ко проверава идентитет и где. У првом је прокси јавни улаз и прослеђује сваки захтев који стигне, укључујући непријатељски, у складу са политиком постављеном на њему. У другом је сама доступност капија, што је грубо али стварно примање.

Где се TLS зауставља и шта заправо доказује

TLS између прегледача и проксија штити тај скок и омогућава прегледачу да провери сајт који је намеравао да посети. Ако прокси прекине TLS, захтев постоји у читљивом облику унутар тог процеса пре него што се проследи. Друга TLS сесија према извору може да заштити следећи скок и одвојено провери крајњу тачку апликације. Ниједна сесија не одлучује који човек сме да користи апликацију. Ни сертификат са џокер знаком на проксију не протеже се на тај други скок.

То је део који људи сажимају у реч шифровано. Поверљивост, интегритет и идентитет сервера су својства транспорта; ауторизација је одлука апликације. Приватна адреса иза тунела мења ко може да дође до сокета, а не ко сме да се пријави кад до њега дође.

Верујте прослеђеним заглављима само од проксија

Апликације које бележе или ауторизују по адреси клијента обично читају заглавље које прокси додаје. То заглавље је само текст, па све што може да дође до извора директно може да тврди било коју адресу. Ограничите извор тако да се само тунелска адреса проксија може повезати, и конфигуришите апликацију да прихвата заглавље само са те адресе.

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

Ако тај захтев успе са хоста који није прокси, извор верује заглављу које би требало да игнорише. Поправите слушаоца пре него што дирнете апликацију. Одбијање је много бољи исход од линије у дневнику која носи кривотворену адресу.

Држите извор доступним са тачно једног места

Повежите слушаоца извора са тунелском адресом или га оградите заштитним зидом према проксију, па потврдите шта заправо слуша. Услуга покренута са wildcard везом прихвата везе на сваком интерфејсу који хост има, укључујући онај за који сте заборавили да је рутабилан. Табела слушања је основна истина, а не конфигурациона датотека коју сте намеравали да примените. Ако је wildcard веза намерна, заштитни зид и даље мора бити компонента која је сужава.

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

Урадите исти преглед за административне интерфејсе, који су уобичајена случајна изложеност. Затим запишите два модела одвојено: јавни сајт кроз прокси и административни интерфејс доступан само кроз тунел. Реченица да је сервер иза VPN-а не говори ништа од тога.