Аўтэнтыфікацыя проксі ў бязгаловым браўзеры — не маршрут VPN

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

Дзве размовы, два ўліковыя даныя

Адбываюцца дзве размовы, і яны належаць розным бакам. Браўзер спачатку злучаецца з праслухоўвальнікам проксі, які можа запатрабаваць ад яго ўліковыя даныя; затым проксі ўстанаўлівае або дазваляе далейшае злучэнне з пунктам прызначэння. VPN можа несці першую частку, не з'яўляючыся канчатковым пунктам, які запытвае ў браўзера ўліковыя даныя, і ён нічога не можа сказаць пра другую частку.

HTTP 407 — гэта сігнал, што кліент павінен аўтэнтыфікавацца для запыту да проксі; ён перадаецца ў Proxy-Authenticate, а адказ чакаецца ў Proxy-Authorization. Гэта не ўваход на сайт прызначэння, і змешванне двух — самая частая крыніца блытаніны тут.

Такім чынам, чатыры праверкі: які проксі браўзер фактычна выбраў, хто адказвае на 407, у якой сетцы знаходзіцца працэс браўзера і як уліковыя даныя перадаюцца без чалавека. Кожная можа збаіць незалежна, і кожны збой знешне выглядае падобна. Выконвайце іх па парадку, бо наступная праверка не кампенсуе папярэднюю. Проксі, які ніколі не быў выбраны, немагчыма аўтэнтыфікаваць, а ўліковыя даныя, што існуюць толькі на вашым ноўтбуку, не дасягнуць кантэйнера.

Праверка 1: які проксі фактычна выбраны

Пачніце з выбару, бо браўзер, які ігнаруе наладу проксі, наогул не дасягае запыту. У Chrome сцяг — --proxy-server=proxy.example:3128, для выключэнняў ёсць --proxy-bypass-list, а Selenium прапануе тое ж праз опцыі браўзера. PAC-файл — гэта іншы механізм са сваімі рэжымамі збою.

Затым пацвердзіце з асяроддзя запушчанага браўзера, а не са сваёй абалонкі. Незалежная праверка з тым жа проксі — curl -x http://proxy.example:3128 -v https://example.com, і яе падрабязны вывад паказвае, ці ўдаўся CONNECT, што вярнуў Proxy-Authenticate і ці прыйшоў адказ 407. Калі curl атрымлівае 407, а браўзер завісае, праблема ў шляху ўліковых даных, а не ў сетцы. Калі curl атрымлівае поспех, а браўзер не, браўзер не выкарыстоўвае той проксі, пра які вы думаеце.

Праверка 2: хто адказвае на 407

У 407 ёсць уладальнік, і яго назва вызначае, куды ідзе выпраўленне. Калі запыт ідзе ад карпаратыўнага проксі, выпраўленне — гэта ўліковыя даныя, якія браўзер можа прад'явіць без нагляду. Калі ён ідзе ад вышэйшага проксі, куды перасылае першы, уліковыя даныя належаць гэтаму другому кроку, і першы проксі можа перадаваць запыт без змен. Чытайце вобласць аўтэнтыфікацыі і хост у загалоўку Proxy-Authenticate, бо яны называюць менавіта той вузел, які запытвае.

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

Праверка 3: шлях уліковых даных

Найчасцей беспілотныя ўстаноўкі ламаюцца менавіта на ўліковых даных. Selenium можа задаць хост і порт проксі, але аўтэнтыфікацыя HTTP-проксі не з'яўляецца пераноснай часткай гэтай канфігурацыі, а ўліковыя даныя ў URL проксі — не механізм, на які можна спадзявацца ў розных браўзерах і версіях драйвера. Падтрыманыя варыянты — тыя, што дакументуе ваш фактычны стэк: пашырэнне браўзера, якое адказвае на запыт, лакальны праксі перасылкі, які дадае загаловак і дасягальны толькі з задачы, або проксі, які аўтэнтыфікуе працоўнае навантажэнне іншымі сродкамі. Выберайце адзін свядома і праверце яго на дакладных версіях браўзера, драйвера і Selenium, якія будзеце выкарыстоўваць.

Трымайце ўліковыя даныя па-за месцамі, якія іх выдаюць. Камандныя радкі бачныя ў спісах працэсаў, здымкі экрана трапляюць у справаздачы аб тэстах, трасіроўкі браўзера і файлы HAR збіраюць загалоўкі, а зафіксаваная ў рэпазіторыі тэставая канфігурацыя застаецца назаўсёды. Выкарыстоўвайце механізм дастаўкі сакрэтаў задачы і яго правілы рэдагавання, а ўліковы запіс проксі абмяжуйце патрэбнымі пунктамі прызначэння або роляй.

Калі арганізацыя прапануе дазволены прамы маршрут VPN замест абавязковага проксі, параўнайце два праекты відавочна. Не адключайце проксі ціха і не імітуйце аўтэнтыфікацыю іншага кліента, каб абысці палітыку.

Праверка 4: уласны сеткавы кантэкст працэсу браўзера

Гэта праверка, якую людзі прапускаюць. Браўзер, запушчаны працоўным, кантэйнерам або вузлом аддаленага Selenium Grid, выкарыстоўвае сетку гэтага асяроддзя, таму VPN-злучэнне вашага ноўтбука і зменныя проксі вашай абалонкі апісваюць шлях, якога браўзер можа ніколі не крануць.

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

Гатовы працоўны працэс мае тры ўласцівасці, якія варта правяраць разам. Ёсць падтрыманы маршрут ад хоста браўзера да проксі, відавочная палітыка пасярэдніка, якая называе проксі і пункты прызначэння, і жыццёвы цыкл уліковых даных, які не залежыць ад аператара, што адказвае на нябачны запыт. Калі хоць адна з трох залежыць ад чалавека, задача яшчэ не беспілотная, што б ні казаў код выхаду. Запішыце пяць фактаў, перш чым наступны чалавек атрымае канвеер у спадчыну.