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 શેલમાં તેને માન આપતા કમાન્ડ-લાઇન સાધનોને ઠીક કરે છે, અને પોતાની સેટિંગ્સ ફાઇલ વાંચતા સાધન માટે કંઈ કરતું નથી. Gradle, Selenium અને gRPC દરેક પોતાની ગોઠવણી સલાહ લે છે, અને એક ટર્મિનલમાં નિકાસ કરેલી પ્રોક્સી IDE દ્વારા શરૂ કરાયેલા ડીમન માટે અદૃશ્ય છે.
કન્ટેનર સાધનો સામાન્ય રીતે એ જગ્યા છે જ્યાં આ દેખાય છે. કન્ટેનરનું loopback તેનું પોતાનું છે, તેથી 127.0.0.1 કન્ટેનરની અંદર ક્યારેય યજમાનની પ્રોક્સી નથી અર્થ ધરાવતું; યજમાનનું સરનામું કે યજમાન-નેટવર્ક સેટિંગ જરૂરી છે. જે ઉપાય શેલમાં કામ કરે અને બિલ્ડમાં નિષ્ફળ જાય તે સામાન્ય રીતે આ પંક્તિ છે, ટનલ નહીં.
ટ્રસ્ટ સ્તર: સાધન બીજો સ્ટોર વાંચે છે
ઇન્ટરસેપ્શન બીજો ફેરફાર છે, અને તે સૌથી ગેરમાર્ગે દોરતી ભૂલો ઉત્પન્ન કરે છે. ક્લાયન્ટ તપાસાયેલા કનેક્શન માટે પોતાનું પ્રમાણપત્ર રજૂ કરે છે, તેથી કોર્પોરેટ રૂટ પર ભરોસો કરતું બ્રાઉઝર સફળ થાય છે જ્યારે બંડલ કરેલા CA સ્ટોરવાળું સાધન નિષ્ફળ જાય છે. certifi દ્વારા Python requests એ ઉત્તમ ઉદાહરણ છે: ઓપરેટિંગ સિસ્ટમનો સ્ટોર સાચો હોઈ શકે અને વિનંતી તોય નિષ્ફળ જાય, કારણ કે તે રનટાઇમ તેને ક્યારેય વાંચતું નથી. ભૂલનું લખાણ ભાગ્યે જ ઇન્ટરસેપ્શનનો ઉલ્લેખ કરે છે, અને તેથી આ પંક્તિને તૂટેલા એન્ડપોઇન્ટ તરીકે ખોટું નિદાન કરવામાં આવે છે.
એન્ડપોઇન્ટ ખરેખર શું રજૂ કરે છે તેની સાથે સાધને શું માન્ય કર્યું તેની સરખામણી કરો. openssl s_client સર્વરે મોકલેલી શૃંખલા દર્શાવે છે; સાધનનું પોતાનું માન્યકરણ આઉટપુટ તેને શું નક્કી કર્યું તે દર્શાવે છે. જ્યારે તેઓ મેળ ખાતા નથી, REQUESTS_CA_BUNDLE અથવા SSL_CERT_FILE તે રનટાઇમ માટે લીવર છે, અને કોર્પોરેટ રૂટ તે સ્ટોરમાં હોવો જોઈએ જે તે રનટાઇમ વાંચે છે, એવા વૈશ્વિક સ્થાનમાં નહીં જેને ફક્ત કેટલાક સાધનો માને છે.
SSL ભૂલ સુધારતો આવૃત્તિ ફેરફાર ટ્રસ્ટ અને સાઇફર નીતિનો પુરાવો છે, VPNનો નહીં. SOAP ક્લાયન્ટ ચાલુ કરતું Python ડાઉનગ્રેડ બંડલ કરેલા CA સ્ટોર અને ડિફોલ્ટ TLS સેટિંગ્સ બદલ્યું; નેટવર્ક માર્ગ ખસ્યો નહીં.
ફિલ્ટર સ્તર: તે loopback પણ કાઢી શકે છે
ત્રીજો ફેરફાર પેકેટ ફિલ્ટર છે, અને કેટલાક ઉત્પાદનો એવા નિયમો સ્થાપિત કરે છે જે ટનલમાં ન આવતો ટ્રાફિક કાઢી નાખે છે. સ્થાનિક શ્રોતાઓનો સમાવેશ થઈ શકે છે. તે કામ કરતા સોકેટને નકારેલા કે સમયસીમા વીતેલા કનેક્શનમાં ફેરવે છે, અને પરિણામી ભૂલ મશીન પરની નીતિને બદલે એપ્લિકેશનમાં ખામી જેવી લાગે છે.
પોર્ટની માલિકી આ સ્તરનો બીજો અડધો ભાગ છે. BindException એટલે સોકેટ ખોલી શકાયું નહીં, જે કનેક્શન નકારાતા હોવા કરતાં અલગ નિષ્ફળતા છે. ફિલ્ટરને દોષ આપતા પહેલાં તપાસો કે બીજી પ્રક્રિયા પોર્ટ ધરાવે છે કે નહીં, પછી સ્થાનિક ટ્રાફિક કાઢી નાખતો નિયમ શોધો અને ઉત્પાદન જે સૌથી સાંકડી પરવાનગી ટેકો આપે તે ઉમેરો. એક જ ડિબગ પોર્ટ માટે સ્પર્ધા કરતાં બે સાધનો નીતિ અવરોધ જેવો જ સંદેશ આપે છે, અને તેમાંથી ફક્ત એક જ ફાયરવોલ ફેરફારથી સુધરે છે.
Chromeનો ડિબગ પોર્ટ એ જ કુટુંબમાં નિષ્ફળ જાય છે. બ્રાઉઝર શરૂ થાય છે, ડ્રાઇવર DevTools એન્ડપોઇન્ટ સુધી પહોંચી શકતું નથી, અને સંદેશ નેટવર્કને બદલે DevToolsનું નામ લે છે. વધારાના લોન્ચ ફ્લેગ અને બિનજરૂરી ડ્રાઇવર મેનેજર બદલે છે કે કઈ પ્રક્રિયા પોર્ટની માલિક છે, તેથી તેમને દૂર કરવાથી ક્યારેક VPN સુધરેલું લાગે છે.
જે સ્તર નિષ્ફળ ગયું તેનું સમારકામ કરો
ટનલનું નહીં, જે સ્તર નિષ્ફળ ગયું તેનું સમારકામ કરો. પહોંચી ન શકાય તેવા loopback શ્રોતાના શ્રોતા કે પોર્ટ સુધારવા પડે. અવિશ્વસનીય પ્રમાણપત્ર માટે કોર્પોરેટ રૂટ તે જ જગ્યાએ સ્થાપિત કરવો પડે જ્યાં તે ચોક્કસ રનટાઇમ જુએ છે, અપવાદ સાંકડો રાખીને. સ્થાનિક ટ્રાફિક કાઢી નાખતા ફિલ્ટર માટે બંધ ફિલ્ટરને બદલે ચોક્કસ પરવાનગી નિયમ જરૂરી છે, કારણ કે બંધ કરવાથી તે જે કંઈ સુરક્ષિત કરતું હતું તે પણ ફરી ખૂલી જાય છે.
VPN ફરી કનેક્ટ કરવું આમાંથી કોઈ પણ સ્તરની પરીક્ષા કરતું નથી. તે ફક્ત તે ફેરફાર ફરી ચલાવે છે જેણે તેમને તોડ્યા, તેથી એ જ ત્રણ નિષ્ફળતાઓ દરેક પુનઃકનેક્શન પછી પાછી આવે છે અને ક્લાયન્ટને નિષ્ક્રિય છોડતા દરેક રીબૂટ પછી અદૃશ્ય થાય છે.