Како јавниот прокси преку 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/

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

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

Врзете го слушателот на изворот за тунелската адреса или оградете го со огнен ѕид кон проксито, потоа потврдете што навистина слуша. Услуга стартувана со врзување со џокер прифаќа врски на секој интерфејс што го има домаќинот, вклучително и оној за кој заборавивте дека е рутирачки. Табелата на слушање е основната вистина, а не конфигурациската датотека што имавте намера да ја примените. Ако врзувањето со џокер е намерно, огнениот ѕид сепак мора да биде компонентата што го стеснува.

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

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