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 ను తిరిగి కనెక్ట్ చేయడం ఈ పొరల్లో ఏదీ పరీక్షించదు. అది వాటిని విరిచిన మార్పును మాత్రమే తిరిగి అమలు చేస్తుంది, అందుకే అవే మూడు వైఫల్యాలు ప్రతి పునఃకనెక్షన్ తర్వాత తిరిగి వస్తాయి మరియు క్లయింట్ను నిష్క్రియంగా వదిలే ప్రతి రీబూట్ తర్వాత అదృశ్యమవుతాయి.