Жария прокси VPN арқылы жеке дереккөзге қалай жетеді

Сайтты туннель арқылы жариялау және пайдаланушыларға VPN қатынасын беру — бір кабельді бөлісетін екі түрлі реттеу. Біріншісінде жария кері прокси келушінің сұрауын қабылдап, оны туннель арқылы ешкім тікелей жете алмайтын дереккөзге жібереді. Екіншісінде пайдаланушы қолданба мүлде қолжетімді болмай тұрып VPN-ге қосылуы керек. Осы екі сипаттаманы араластыру — жеке backend-тің ақырында жария түрде ашылып қалуының жолы.

Диаграммада бірдей көрінетін екі модель

Бірдеңе таңдамас бұрын көрсеткілерді сызыңыз. Жария жариялау моделі браузерден проксиге HTTPS арқылы, содан кейін проксиден дереккөзге туннель арқылы жүреді, ал дереккөз интернеттен қосылымды ешқашан қабылдамайды. Тек VPN моделі клиенттен шлюзге жүреді, ал қолданба тек сол жолдың ішінен қолжетімді. Пайдаланушының ноутбугі қолданбамен бір желіде отырады, және бұл сол модельдің бүкіл мәні.

Модельдер кімнің аутентификация жасайтынымен және қайда жасайтынымен ерекшеленеді. Біріншісінде прокси — жария кіреберіс және ол келген кез келген сұрауды, оның ішінде дұшпандық сұрауды да, онда конфигурацияланған саясатқа сай жібереді. Екіншісінде қолжетімділіктің өзі қақпа, бұл дөрекі бірақ нақты қабылдау.

TLS қайда тоқтайды және ол шын мәнінде нені дәлелдейді

Браузер мен прокси арасындағы TLS сол секірісті қорғайды және браузерге баруға ниеттенген сайтты тексеруге мүмкіндік береді. Егер прокси TLS-ті тоқтатса, сұрау жіберілмес бұрын сол процестің ішінде оқылатын түрде болады. Дереккөзге екінші TLS сессиясы келесі секірісті қорғап, қолданбаның шеткі нүктесін бөлек тексере алады. Екі сессияның ешқайсысы қандай адамның қолданбаны пайдалануға құқылы екенін шешпейді. Проксидегі wildcard сертификаты да сол екінші секіріске таралмайды.

Бұл — адамдар шифрланған деген сөзге жинақтайтын бөлік. Құпиялылық, тұтастық және сервер сәйкестігі — тасымалдау қасиеттері; авторизация — қолданбаның шешімі. Туннельдің артындағы жеке мекенжай кім сокетке жете алатынын өзгертеді, ал жеткеннен кейін кім кіре алатынын емес.

Бағытталған тақырыпшаларға тек проксиден сеніңіз

Клиент мекенжайы бойынша журнал жүргізетін немесе авторизация жасайтын қолданбалар әдетте прокси қосатын тақырыпшаны оқиды. Ол тақырыпша — жай мәтін, сондықтан дереккөзге тікелей жете алатын кез келген нәрсе кез келген мекенжайды талап ете алады. Дереккөзді тек проксидің туннель мекенжайы ғана қосыла алатындай шектеңіз, және қолданбаны тақырыпшаны тек сол мекенжайдан қабылдайтындай конфигурациялаңыз.

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-нің артында деген сөйлем олардың ешқайсысын айтпайды.