mitmproxy, DevTools, Gradle՝ VPN-ի հետևում երեք շերտ
Loopback-ը երբեք չի մտնում թունել։ Դասակարգեք ախտանիշը լսողի, վստահության պահոցի կամ փաթեթների զտիչի, և վերանորոգեք այն շերտը, որն իսկապես ձախողվել է։
VPN-ը միանում է, և երեք անկապ գործիքներ ձախողվում են երեք տարբեր ձևերով նույն կեսօրին։ mitmproxy-ը դադարում է տեսնել հարցումները, Chrome-ը մերժում է վրիպազերծիչը, իսկ Gradle-ը նետում է BindException տեղական սոքեթը կապելիս։ Ընդհանուր կասկածն այն է, որ թունելը արգելափակում է localhost-ը։ Այն չի կարող՝ 127.0.0.1 մշակվում է միջուկի ներսում և երբեք չի հասնում ադապտերին, ուր մնաց դարպասին։
Երեք շերտ, երեք տարբեր խափանում
Այն, ինչ փոխվել է հաճախորդի հետ, loopback-ի ճանապարհը չէ։ Դրանք տեղական պրոքսին, մեքենայի վստահության պահոցը և փաթեթների զտիչն են, և յուրաքանչյուրը կոտրում է մշակողի աշխատահոսքի տարբեր մաս։ Ախտանիշը ճիշտ շարքում դասավորելը ախտորոշման մեծ մասն է՝
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
Այս տեսակի գրեթե բոլոր հաշվետվությունները սկսվում են վերջին շարքից և բարձրանում վերև, ինչը հակառակ է։ Թունելը միակ շերտն է, որ ապացուցելիորեն չի կարող տեսնել loopback-ի երթևեկությունը, ուստի այն արժանի է ամենաքիչ կասկածին։ Սկսեք նրանից, ինչ գործընթացը կապել է, ապա հարցրեք, թե որ սերտիֆիկատներին է այն վստահում, և միայն դրանից հետո նայեք մեքենայի քաղաքականությանը։
Սկսեք լսողից, ոչ թե թունելից
Երբ պրոքսին 127.0.0.1:8080 դադարում է երթևեկություն ստանալ, տեղի է ունեցել երեքից մեկը՝ այն երբեք չի սկսվել, այլ պորտ է կապել, կամ զտիչը գցել է loopback-ի միացումը։ Լսող սոքեթների թվարկումը դրան պատասխանում է մեկ հրամանով, և ցույց է տալիս նաև, թե որ գործընթացն է տիրում պորտին, երբ երկու գործիք չեն համաձայնում, թե ով էր առաջինը։
Երթուղու որոնման մեջ տեղական հասցեն հաստատում է նույնը մյուս կողմից։ ip route get loopback-ի ուղղությամբ հայտնում է loopback-ի սարքի մասին, երբեք՝ թունելի, ինչը օգտակար նախադասություն է պատրաստ պահել, երբ ինչ-որ մեկը որպես լուծում առաջարկում է երթուղային փոփոխություն։
Պրոքսիի շերտը՝ միջավայրը կոնֆիգուրացիա չէ
Շատ կորպորատիվ հաճախորդներ աշխատեցնում են HTTP պրոքսի և ակնկալում, որ հավելվածները կօգտվեն դրանից։ Սահմանելը HTTPS_PROXY shell-ում ուղղում է այն հրամանատող գործիքները, որոնք հարգում են այն, և ոչինչ չի անում մի գործիքի համար, որ կարդում է իր սեփական կարգավորումների ֆայլը։ Gradle-ը, Selenium-ը և gRPC-ն յուրաքանչյուրը խորհրդակցում է իր կոնֆիգուրացիայի հետ, և մեկ տերմինալում արտահանված պրոքսին անտեսանելի է IDE-ի կողմից գործարկված դեմոնի համար։
Կոնտեյներային գործիքները սովորական տեղն են, որտեղ սա տեսանելի է դառնում։ Կոնտեյների loopback-ը իրենն է, ուստի 127.0.0.1 կոնտեյների ներսում երբեք չի նշանակում հյուրընկալողի պրոքսին․ անհրաժեշտ է հյուրընկալողի հասցեն կամ հյուրընկալող-ցանցի կարգավորում։ Ուղղումը, որն աշխատում է shell-ում և ձախողվում build-ում, սովորաբար այս շարքն է, ոչ թե թունելը։
Վստահության շերտը՝ գործիքն այլ պահոց է կարդում
Ընդհատումը երկրորդ փոփոխությունն է, և այն արտադրում է ամենամոլորիչ սխալները։ Հաճախորդը ներկայացնում է իր սեփական սերտիֆիկատը ստուգվող միացումների համար, ուստի կորպորատիվ արմատին վստահող դիտարկիչը հաջողում է, մինչդեռ ներկառուցված CA պահոցով գործիքը ձախողվում է։ Python-ի requests-ը certifi-ի միջոցով դասական դեպքն է․ օպերացիոն համակարգի պահոցը կարող է ճիշտ լինել, և հարցումը դեռ ձախողվում է, որովհետև այդ գործարկման միջավայրը երբեք չի կարդում այն։ Սխալի տեքստը հազվադեպ է հիշատակում ընդհատումը, դրա համար էլ այս շարքը սխալ ախտորոշվում է որպես կոտրված վերջնակետ։
Համեմատեք, թե վերջնակետն ինչ է իրականում ներկայացնում, այն բանի հետ, ինչ գործիքը վավերացրել է։ openssl s_client ցույց է տալիս սերվերի ուղարկած շղթան․ գործիքի սեփական վավերացման ելքը ցույց է տալիս, թե ինչ որոշեց։ Երբ դրանք չեն համապատասխանում, REQUESTS_CA_BUNDLE կամ SSL_CERT_FILE այդ գործարկման միջավայրի լծակն է, և կորպորատիվ արմատը պատկանում է այն պահոցին, որը կարդում է այդ միջավայրը, ոչ թե գլոբալ տեղի, որը հարգում են միայն որոշ գործիքներ։
SSL սխալը շտկող տարբերակի փոփոխությունը վկայում է վստահության և գաղտնագրման քաղաքականության, ոչ թե VPN-ի մասին։ Python-ի իջեցումը, որով SOAP հաճախորդը սկսեց աշխատել, փոխեց ներկառուցված CA պահոցը և լռելյայն TLS կարգավորումները․ ցանցային ուղին չշարժվեց։
Զտիչի շերտը՝ այն կարող է գցել նաև loopback-ը
Երրորդ փոփոխությունը փաթեթների զտիչն է, և որոշ ապրանքներ տեղադրում են կանոններ, որոնք գցում են թունել չմտնող երթևեկությունը։ Տեղական լսողները կարող են ներառվել։ Դա աշխատող սոքեթը դարձնում է մերժված կամ ժամկետանց միացում, և առաջացած սխալը թվում է հավելվածի սխալ, ոչ թե մեքենայի քաղաքականություն։
Պորտի սեփականությունը այս շերտի մյուս կեսն է։ BindException նշանակում է, որ սոքեթը հնարավոր չեղավ բացել, ինչը տարբերվում է մերժված միացումից։ Ստուգեք՝ արդյոք այլ գործընթաց արդեն պահում է պորտը, նախքան զտիչին մեղադրելը, ապա փնտրեք կանոն, որ գցում է տեղական երթևեկությունը, և ավելացրեք ամենանեղ թույլտվությունը, որն աջակցում է ապրանքը։ Նույն վրիպազերծման պորտի համար մրցող երկու գործիք արտադրում են ճիշտ նույն հաղորդագրությունը, ինչ քաղաքականության արգելափակումը, և նրանցից միայն մեկն է շտկվում firewall-ի փոփոխությամբ։
Chrome-ի վրիպազերծման պորտը ձախողվում է նույն ընտանիքում։ Դիտարկիչը սկսվում է, վարորդը չի կարողանում հասնել DevTools-ի վերջնակետին, և հաղորդագրությունը նշում է DevTools-ը, ոչ թե ցանցը։ Լրացուցիչ գործարկման դրոշները և ավելորդ վարորդների կառավարիչը փոխում են, թե որ գործընթացն է տիրում պորտին, դրա համար էլ դրանց հեռացումը երբեմն թվում է, թե շտկում է VPN-ը։
Վերանորոգեք ձախողված շերտը
Վերանորոգեք ձախողված շերտը, ոչ թե թունելը։ Անհասանելի loopback լսողին պետք է ուղղել նրա լսողը կամ պորտը։ Ոչ վստահելի սերտիֆիկատին պետք է կորպորատիվ արմատը տեղադրված այնտեղ, որտեղ նայում է այդ կոնկրետ գործարկման միջավայրը, բացառությունը նեղ պահելով։ Տեղական երթևեկությունը գցող զտիչին պետք է կոնկրետ թույլտվության կանոն, ոչ թե անջատված զտիչ, որովհետև անջատելը նորից բացում է նաև այն ամենը, ինչ այն պաշտպանում էր։
VPN-ի վերամիացումը չի ստուգում այս շերտերից ոչ մեկը։ Այն պարզապես նորից գործարկում է այն փոփոխությունը, որ կոտրել էր դրանք, դրա համար էլ նույն երեք խափանումները վերադառնում են յուրաքանչյուր վերամիացումից հետո և անհետանում յուրաքանչյուր վերագործարկումից հետո, որը հաճախորդին թողնում է անգործուն։