Հավելվածի հարցումները ձախողվում են կորպորատիվ VPN-ի հետևում, բայց զննարկիչն աշխատում է

Բացում եք ներքին պորտալը զննարկիչում, և այն բեռնվում է։ Գործարկում եք հավելվածը, որը կանչում է նույն հոսթը, և այն ձախողվում է մի հաղորդագրությամբ, որը ոչ մի շերտ չի նշում։ Թունելը կրում է զննարկիչը, ուստի թունելը առաջին կասկածյալը չէ։ Ձեր հարցման և ծառայության միջև չորս բան կա, և յուրաքանչյուրը տարբեր հետք է թողնում։ Սա այն հերթականությունն է, որին հետևում եմ՝ սկսելով հարցումից, որն իրականում ուղարկում է հավելվածը, և ոչ թե 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-ը գումարած ժառանգված պրոքսին գումարած հավելվածի լռելյայն արժեքը ձեզ տալիս են միանգամից երեք հավանական պատճառ։

Յուրաքանչյուր թեստի համար պահեք մեկ փոփոխական և գրանցեք օգտագործված նպատակակետ հոսթը։ Առանց այդ հիմնագծի հաջորդ մարդը նորից կրկնում է բոլոր չորս քայլերը սկզբից։