Запыты праграм не праходзяць за карпаратыўным VPN, а браўзер працуе
Адзін дадатак ламаецца, а браўзер адкрывае сайт. Праверце па парадку праксі, якое ён атрымаў у спадчыну, палітыку портаў, скід сырога TCP і абмежаванні памеру карыснай нагрузкі.
Вы адкрываеце ўнутраны партал у браўзеры, і ён загружаецца. Вы запускаеце дадатак, які звяртаецца да таго ж хоста, і ён падае з паведамленнем, якое не называе ніводнага ўзроўню. Тунель нясе браўзер, таму тунель не першы падазроны. Паміж вашым запытам і сэрвісам стаяць чатыры рэчы, і кожнае пакідае розны след. Вось парадак, які я праходжу, пачынаючы з запыту, які дадатак сапраўды адпраўляе, а не са старонкі налад кліента VPN.
Паглядзіце на запыт, які дадатак сапраўды адпраўляе
Перш чым чапаць канфігурацыю, прымусьце дадатак расказаць, што ён робіць. Перахоп аднаго запыту з яўна адключаным праксі і просты тэст порта даюць дзве базавыя лініі, з якімі параўноўваюць наступныя крокі. Калі запыт праходзіць з адключаным праксі, тры ўзроўні з чатырох ужо зняты.
env | grep -i proxy # Linux/macOS
netsh winhttp show proxy # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080Выканайце два апошнія з той жа мэтай і паглядзіце, дзе яны разыходзяцца. Браўзер, які працуе, плюс curl, які працуе, плюс дадатак, які не працуе, звужваюць праблему да таго, што дадае сам дадатак: праксі, транспарт або памер паведамлення.
Дадатак атрымаў у спадчыну праксі, якое ніхто не наладжваў
Большасць стэкаў HTTP па змаўчанні чытаюць налады праксі з аперацыйнай сістэмы. Карпаратыўны кліент VPN часта ўсталёўвае яго ў складзе свайго профілю доступу, таму запыты выходзяць праз праксі, пра якое распрацоўшчык ніколі не згадваў у кодзе. У .NET стандартны апрацоўшчык бярэ налады IE/WinHTTP; Java чытае -Dhttp.proxyHost; Node не мае ўбудаванай падтрымкі праксі, пакуль бібліятэка яе не дадасць. Збой рэдка бывае чыстай адмовай, таму людзі пачынаюць глядзець на сервер.
Тэст каштуе аднаго запыту: адключыце праксі яўна ў адным апрацоўшчыку і параўнайце.
var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);Калі гэта праходзіць, выпраўленне належыць канфігурацыі дадатка, а не тунелю. Паўтарыце аўдыт для кожнага рантайма ў праекце, бо кожны чытае сваю крыніцу і зламаным можа быць толькі адзін.
Порт, які вы выбралі, не той, што дазваляе палітыка
Маршрутызаваны хост — гэта не дазволены сэрвіс. Карпаратыўная палітыка звычайна дазваляе знешнія вэб-парты і скідае астатнія, таму сэрвіс на 8080 або 1883 недасяжны, пакуль 443 працуе нармальна. Браўзер тут нічога не даказвае: ён выкарыстоўвае 443 па вызначэнні.
Апублікуйце той жа сэрвіс за 443 і дабярыцеся да яго па імені, перш чым прасіць выключэнне. Калі выключэнне сапраўды патрэбна, абмяжуйце яго адным дыяпазонам крыніцы і адной мэтай і разглядайце як частку апісання сэрвісу, а не як чыёсьці асабістае рашэнне.
Сыры TCP, які скідае шлях
Доўгажывучыя злучэнні сырога TCP — гэта ўзровень, які падае найбольш заблытана. Шлях, які дазваляе вэб-трафік, усё яшчэ можа скідаць або перапісваць незвычайны знешні TCP, і кліент паведамляе пра памылку сокета, якая чытаецца як збой. Сэрвісы паведамленняў і падзей звычайна пастаўляюць транспарт WebSocket менавіта для такіх сетак, і пераключэнне — гэта опцыя кліента, а не змена тунелю.
Пераключыце транспарт, ператэстуйце і не змяняйце нічога іншага ў тым жа праходзе. Гэты тэст з адной зменнай скажа, адкуль прыйшоў скід — са шляху ці з сэрвісу.
Злучэнні, якія зачыняюцца толькі на вялікіх нагрузках
Запыт, які праходзіць, а затым памірае прыкладна праз секунду, але толькі калі цела вялікае, паказвае на абмежаванне памеру дзесьці ў сярэдзіне. Пасрэднік, які лічыць байты паведамленняў, можа скінуць злучэнне пасярэдзіне перадачы, і кліент паведамляе пра анамальнае зачыненне замест тайм-аўту.
Драбіце нагрузку на ўзроўні дадатка. Трымайце гэта асобна ад працы з MTU: зніжэнне памеру пакета тунелю дапамагае, калі звычайныя сесіі TCP спыняюцца на нязменнай колькасці байтаў, і нічога не робіць для паведамлення, якое пасрэднік лічыць занадта вялікім.
Як адрозніць чатыры ў адзін праход
Тры назіранні вырашаюць большасць выпадкаў. Збой адбываецца адразу ці толькі з вялікім целам? Ці праходзіць той жа запыт з адключаным праксі? Ці змяняецца вынік, калі пераключыць порт або транспарт? Запішыце адказы да наступнай змены, бо карпаратыўны VPN плюс атрыманае ў спадчыну праксі плюс стандартная налада дадатка даюць адразу тры праўдападобныя прычыны.
Трымайце адну зменную на тэст і запісвайце хост прызначэння, які вы выкарысталі. Без гэтай базавай лініі наступны чалавек паўторыць усе чатыры крокі з пачатку.