Айқын проксидің артындағы филиал браузері екі қосылым ашады және олар әртүрлі себептермен сәтсіз болады. Біріншісі браузерден прокси тыңдаушысына дейін, филиал VPN-і арқылы өтеді. Екіншісі проксиден веб-сайтқа дейін, проксидің өз resolver-ін, маршрутын және шығыс саясатын пайдаланады. Оларды бір ағын ретінде қарастыратын қолдау билеттері адамдарды сағаттар бойы дұрыс емес құрылғыға жібереді. Әрқайсысын әдейі орнатып, сол ретпен тексеріңіз.

1-қадам: екі ағынды жазып алыңыз

Браузердің тікелей межелі жері — прокси тыңдаушысы, пайдаланушы ақыр соңында кіретін әр сайт емес. Осы бір сөйлем бұл дизайндағы шатасудың көбін шешеді.

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

Әртүрлі көздер, әртүрлі маршруттар, әртүрлі рұқсаттар. Эскизді өзгеріс жазбасында сақтаңыз, өйткені әрбір кейінгі тексеру оның екі жартысының біріне сілтеме жасайды.

2-қадам: браузерге тыңдаушыға жол беріңіз

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

Интернетке шектеусіз прокси жариялаудың орнына мақсатты қызмет үшін тар желілік ереже қолданыңыз. Прокси ішкі желіде қалуы мүмкін, егер оның мақсатты клиенттеріне оған қолдау көрсетілген жол болса.

3-қадам: тек маршруттар кестесін емес, браузерді конфигурациялаңыз

Браузердің прокси параметрін, PAC файлын немесе ұйымның басқарылатын анықтау механизмін пайдаланыңыз. Қарапайым сайт пакеттерін маршрутпен прокси мекенжайына жіберу браузерді прокси протоколында сөйлеуге мәжбүрлемейді; бұл ашық кедергі және басқа шлюз дизайнына жатады.

Қай қосымшалар параметрді құрметтейтінін жазыңыз. Пошта клиенттері, жаңартқыштар және ойындар көбінесе олай жасамайды және қарапайым жолды пайдалануды жалғастырады.

4-қадам: проксидің шығыс қосылымын дәлелдеңіз

Проксиге өзінің resolver-і және сайтқа рұқсат етілген маршрут, сондай-ақ оның интернет шекарасы талап ететін кез келген firewall немесе аударма саясаты қажет. Тыңдаушыға жеткен браузер мұның ешқайсысын дәлелдемейді. Екінші ағынды проксидің өзінен, пайдаланушы хабарлаған сол межелі жермен және портпен тексеріңіз.

HTTPS үшін CONNECT сұралған межелі жерге туннель ашады. Қарапайым жіберу проксиге шифры шешілген бетті бермейді, ал тексеруді импровизациялау үшін сертификатты валидациялауды өшіру шешім емес.

5-қадам: төрт ақауды ажыратыңыз

Прокси аутентификация шақыруы — тыңдаушыдан келген 407. Қабылданбаған CONNECT — проксидегі саясат шешімі, әдетте өз мәртебесімен және журнал жолымен. Сәтсіз шығыс қосылымы прокси межелі жерге қатысты тіркейтін уақыт бітуі немесе қайта орнату сияқты көрінеді. Сайттың жауабы екі қосылым да жұмыс істегенін және мәселе бастау көзінде екенін білдіреді.

Байқаған шекараңызды хабарлаңыз, VPN істен шықты деген қорытындыны емес.

6-қадам: ауқымды анықтап, қосалқы жолды жоспарлаңыз

Прокси немесе туннель қолжетімсіз болғанда не болатынын шешіп, бұл дизайн қандай трафикті қамтитынын анық айтыңыз. Ол прокси параметрін құрметтейтін клиенттерден веб-қатынасты тасымалдайды; ол поштаны, еркін құрылғы протоколдарын немесе конфигурацияны елемейтін бағдарламалық жасақтаманы тасымалдамайды.

Дизайнды көбірек клиенттерге кеңейтпес бұрын бекітілген жоспар бойынша қажетті браузер операциясын және бір қажетті бас тартуды растаңыз.

Қатысты мақалалар