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 ಅನ್ನು ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವುದು ಈ ಪದರಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಪರೀಕ್ಷಿಸುವುದಿಲ್ಲ. ಅದು ಅವುಗಳನ್ನು ಮುರಿದ ಬದಲಾವಣೆಯನ್ನು ಮಾತ್ರ ಮತ್ತೆ ಚಲಾಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದೇ ಮೂರು ವೈಫಲ್ಯಗಳು ಪ್ರತಿ ಮರುಸಂಪರ್ಕದ ನಂತರ ಹಿಂತಿರುಗುತ್ತವೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯವಾಗಿ ಬಿಡುವ ಪ್ರತಿ ಮರುಬೂಟ್ ನಂತರ ಮಾಯವಾಗುತ್ತವೆ.