Як публічны проксі дасягае прыватнай крыніцы праз VPN

Публікацыя сайта праз тунель і прадастаўленне карыстальнікам доступу да VPN — гэта два розныя ўладкаванні, якія дзеляць адзін кабель. У першым публічны зваротны проксі прымае запыт наведвальніка і перадае яго праз тунель да крыніцы, да якой ніхто не можа дабрацца напрамую. У другім карыстальнік павінен далучыцца да VPN, перш чым праграма стане дасягальнай наогул. Змешванне двух апісанняў — гэта шлях, якім прыватны бэкэнд у рэшце рэшт аказваецца публічна адкрытым.

Дзве мадэлі, якія выглядаюць аднолькава на схеме

Намалюйце стрэлкі, перш чым нешта выбіраць. Мадэль публічнай публікацыі ідзе ад браўзера да проксі па 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, не кажа нічога з гэтага.