Tinyproxy ನಲ್ಲಿ Listen, Bind ಮತ್ತು BindSame: ಯಾವ ವಿಳಾಸ ಗೆಲ್ಲುತ್ತದೆ
Listen ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ, Bind ಹೊರಹೋಗುವ ಸಂಪರ್ಕಗಳ ಮೂಲವನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ. ಎರಡೂ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ.
ಪ್ರಾಕ್ಸಿ ಉತ್ತರಿಸುತ್ತದೆ, ವಿನಂತಿ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ, ಆದರೂ ಗಮ್ಯಸ್ಥಾನವು ಇನ್ನೂ ಲ್ಯಾನ್ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಪ್ರಾಕ್ಸಿ ಲಾಗ್‌ನಲ್ಲಿ ಏನೂ ತಪ್ಪಾಗಿ ಕಾಣುವುದಿಲ್ಲ, ಮತ್ತು ನೀವು ಬದಲಾಯಿಸಿದ ಸಾಲು ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಬದಲಾಯಿಸಲು ಹೇಳಿದ ಸಾಲೇ ಆಗಿದೆ. ಲ್ಯಾನ್ ವಿಳಾಸ ಮತ್ತು ಟನೆಲ್ ವಿಳಾಸ ಎರಡೂ ಇರುವ ಹೋಸ್ಟ್‌ನಲ್ಲಿ, ಯಾವ ವಿಳಾಸ ಎಲ್ಲಿ ಕಾಣುತ್ತದೆ ಎಂಬುದನ್ನು ಮೂರು ಸೂಚನೆಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಮಾತ್ರ ಹೊರಹೋಗುವ ಬದಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ತಪ್ಪು ಕ್ರಮದಲ್ಲಿ ಓದಿದರೆ ಕಾರಣವಿಲ್ಲದೆ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕಕ್ಕೆ ಪ್ರವೇಶಿಸುತ್ತೀರಿ.
ಲಕ್ಷಣ: ಗಮ್ಯಸ್ಥಾನವು ಲ್ಯಾನ್ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ
ಕ್ಲೈಂಟ್ ಲ್ಯಾನ್ ವಿಳಾಸದಲ್ಲಿ ಪ್ರಾಕ್ಸಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ತನ್ನದೇ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುತ್ತದೆ. ಆ ಎರಡನೇ ಸಂಪರ್ಕವು ಕರ್ನೆಲ್ ನಿಯಮಗಳ ಪ್ರಕಾರ ಮೂಲ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆಮಾಡುತ್ತದೆ, ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಅದು ಮಾರ್ಗ ಹುಡುಕಾಟ ಆಯ್ಕೆಮಾಡುವ ವಿಳಾಸವೇ ಆಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ ಪ್ರತಿ ಬೈಟ್ ಪ್ರಾಕ್ಸಿಯ ಮೂಲಕ ಹೋದರೂ ಗಮ್ಯಸ್ಥಾನವು ಹೋಸ್ಟ್‌ನ ಪ್ರಾಥಮಿಕ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ದೃಷ್ಟಿಯಿಂದ ಏನೂ ಮುರಿದಿಲ್ಲ, ಮತ್ತು ಅದಕ್ಕೇ ಪ್ರಾಕ್ಸಿ ಲಾಗ್‌ಗೆ ಇದರ ಬಗ್ಗೆ ಹೇಳಲು ಏನೂ ಇಲ್ಲ.
ಆ ದೋಷದ ಕನ್ನಡಿ ಚಿತ್ರವನ್ನು ಗುರುತಿಸುವುದು ಸುಲಭ: ಹೊರಹೋಗುವ ಮೂಲವನ್ನು ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಪಿನ್ ಮಾಡಿ, ಲ್ಯಾನ್ ಕ್ಲೈಂಟ್‌ಗಳು ಆಲಿಸುವವರನ್ನು ಸಂಪರ್ಕಿಸುವುದನ್ನೇ ನಿಲ್ಲಿಸುತ್ತವೆ. ಆ ಆವೃತ್ತಿ ತಾನೇ ಘೋಷಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮೊದಲನೆಯದು ಕೆಲಸ ಮಾಡುವ ವಿನಂತಿಯ ಹಿಂದೆ ಅಡಗುತ್ತದೆ. ಎರಡೂ ಒಂದು ಸೂಚನೆಯನ್ನು ಎರಡೂ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಪರಿಗಣಿಸುವುದರಿಂದ ಬರುತ್ತವೆ.
ಮೂರು ಸೂಚನೆಗಳು, ಮೂರು ವಿಭಿನ್ನ ವಿಳಾಸಗಳು
Listen ಪ್ರಾಕ್ಸಿ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಸ್ಥಳೀಯ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. Bind ಪ್ರಾಕ್ಸಿ ಹೊರಕ್ಕೆ ಮಾಡುವ ಸಂಪರ್ಕಗಳಿಗೆ ಮೂಲ ವಿಳಾಸವನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು BindSame ಈಗಷ್ಟೇ ಸ್ವೀಕರಿಸಿದ ಸಂಪರ್ಕದ ಸ್ಥಳೀಯ ವಿಳಾಸವನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು ಅದಕ್ಕೆ ಹೇಳುತ್ತದೆ. ಇವು ಮೂರು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳು, ಮತ್ತು ಒಂದು ಸಾಲು ಅವುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಮಾತ್ರ ಉತ್ತರಿಸುತ್ತದೆ. ಅವನ್ನು ಬೆರೆಸುವುದೇ ಬದಲಾವಣೆ ಏನೂ ಮಾಡದಂತೆ ಕಾಣುವ ಸಾಮಾನ್ಯ ಕಾರಣ.
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
ಸ್ಥಾಪಿತ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಬರುವ ಟೀಕೆ ಸಹಿತ ಸಂರಚನೆಯನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳು ಮತ್ತು ಸ್ವೀಕೃತ ವಾಕ್ಯರಚನೆ ಬಿಡುಗಡೆಗಳ ನಡುವೆ ಬದಲಾಗುತ್ತವೆ. ಯೋಜನೆಯ ಮಾದರಿ ಸಂರಚನೆ ಪ್ರತಿ ಸೂಚನೆಯನ್ನು ಇತರವುಗಳ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸುತ್ತದೆ. ಆ ಫೈಲ್ ಅನ್ನು ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಫೈಲ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿ, ಬೇರೆ ವಿತರಣೆಗಾಗಿ ಬರೆದ ಮಾರ್ಗದರ್ಶಿಯೊಂದಿಗೆ ಅಲ್ಲ.
ಆಲಿಸುವವರು ಮತ್ತು ಹೊರಹೋಗುವ ಮೂಲವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಹೊಂದಿಸಿ
ಲ್ಯಾನ್ ವಿಳಾಸ 192.168.50.10 ಮತ್ತು ಟನೆಲ್ ವಿಳಾಸ 10.90.0.3 ಇರುವ ಹೋಸ್ಟ್ ತೆಗೆದುಕೊಳ್ಳಿ. ಲ್ಯಾನ್ ಕ್ಲೈಂಟ್‌ಗಳು ಪ್ರಾಕ್ಸಿಯನ್ನು ತಲುಪಬೇಕು ಮತ್ತು ಅವರ ವಿನಂತಿಗಳು ಟನೆಲ್‌ನಿಂದ ಹೊರಬರಬೇಕು ಎಂದಾದರೆ, ಇವು ಎರಡು ಸ್ವತಂತ್ರ ನಿರ್ಧಾರಗಳು ಮತ್ತು ಎರಡನ್ನೂ ಬರೆಯಬೇಕು. ಕೆಳಗಿನ ತುಣುಕು ನಿಖರವಾಗಿ ಅದನ್ನೇ ಹೇಳುತ್ತದೆ, ಹೆಚ್ಚೇನೂ ಅಲ್ಲ.
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noಇದು ಪೂರ್ಣ ಸಂರಚನೆ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಅನುಮೋದಿತ ಪೋರ್ಟ್, ದೃಢೀಕರಣ, ಕ್ಲೈಂಟ್ ಪ್ರವೇಶ ನಿಯಂತ್ರಣಗಳು ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಮಿತಿಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ. ಎರಡೂ ವಿಳಾಸಗಳು Tinyproxy ನ ನೆಟ್‌ವರ್ಕ್ ಹೆಸರಿನ ಜಾಗದ ಒಳಗೆ ಈ ಹೋಸ್ಟ್‌ಗೆ ಸೇರಿರಬೇಕು, ಏಕೆಂದರೆ ಪ್ರಕ್ರಿಯೆ ಹೊಂದಲಾಗದ Bind ಮೌಲ್ಯವು ಪ್ರಾರಂಭದಲ್ಲಿ ಅಲ್ಲ, ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. BindSame yes ಬೇರೆ ನೀತಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಸ್ವೀಕೃತ ಸಂಪರ್ಕದ ಸ್ಥಳೀಯ ವಿಳಾಸವೇ ಹೊರಹೋಗುವ ಮೂಲವಾಗುತ್ತದೆ. ಪ್ರಸ್ತುತ ಬಿಡುಗಡೆಗಳಲ್ಲಿ ಆ ಶಾಖೆಗೆ Bind ಪಟ್ಟಿಗಿಂತ ಆದ್ಯತೆ ಇದೆ, ಮತ್ತು ಹೀಗೇ ಸಂರಚಿತ ಮೂಲವು ಯಾವ ದೋಷವೂ ಇಲ್ಲದೆ ಮಾಯವಾಗುತ್ತದೆ.
ಮೂಲವು ಸೂಚಿಸುವ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ
ಮೂಲ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆಮಾಡುವುದರಿಂದ ಮಾರ್ಗ ಉಂಟಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಆ ಮೂಲ ಮತ್ತು ಆ ಗಮ್ಯಸ್ಥಾನದೊಂದಿಗೆ ಕರ್ನೆಲ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಕೇಳಿ. ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್ ಹೆಸರಿಸುವ ಹುಡುಕಾಟ ಕನಿಷ್ಠ ಸಾಕ್ಷ್ಯ, ಮತ್ತು ಲ್ಯಾನ್ ಇಂಟರ್‌ಫೇಸ್ ಹೆಸರಿಸುವುದು ಎಂದರೆ ಮೂಲವು ಬರೆದಂತೆ ಕೆಲಸ ಮಾಡಲಾಗದು. ಹುಡುಕಾಟ ಸಂದರ್ಭಾಧಾರಿತ: ಅದು ಆ ಹೆಸರಿನ ಜಾಗಕ್ಕೆ ಅನ್ವಯವಾಗುವ ನೀತಿ ನಿಯಮಗಳು ಮತ್ತು ಕೋಷ್ಟಕವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ. ಅದು ಸಂಪರ್ಕವಲ್ಲ, ಮತ್ತು ಕೆಳಗಿನ NAT ಸೇವೆಗೆ ಏನನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ.
ip -4 route get 203.0.113.25 from 10.90.0.3ಉದಾಹರಣೆಯಲ್ಲಿ ದಾಖಲೆ ವಿಳಾಸವನ್ನು ಬಳಸಿ ಮತ್ತು ಪರೀಕ್ಷಿಸಲು ಅನುಮತಿ ಇರುವ ಸೇವೆಯನ್ನು ಆದೇಶಿಸಿ. ಪ್ರಾಕ್ಸಿ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಚಲಿಸುವಾಗ ಹುಡುಕಾಟವನ್ನು ಪ್ರಾಕ್ಸಿಯ ಹೆಸರಿನ ಜಾಗದ ಒಳಗೆ ನಡೆಸಿ, ಏಕೆಂದರೆ ಹೋಸ್ಟ್‌ನ ನಿಯಮಗಳು ಪ್ರಕ್ರಿಯೆ ನೋಡುವ ನಿಯಮಗಳಲ್ಲ. ಉದ್ದೇಶಿತ ಟನೆಲ್ ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದರೆ, ಪ್ರಾಕ್ಸಿ ಹೋಸ್ಟ್‌ಗೆ ಗಮ್ಯಸ್ಥಾನ-ನಿರ್ದಿಷ್ಟ ನಿಯಮಗಳನ್ನು ಸೇರಿಸುವ ಬದಲು ನೆಟ್‌ವರ್ಕ್ ಮಾಲೀಕರಿಂದ ಸರಿಪಡಿಸಿ. ಹುಡುಕಾಟ ಯಶಸ್ವಿಯಾಗಲು ಹೋಸ್ಟ್ ಮಾರ್ಗಗಳನ್ನು ಅಳಿಸಬೇಡಿ ಮತ್ತು ಸರ್ವರ್ ತಳ್ಳುವ ಮಾರ್ಗಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ, ಹಳೆಯ ಮಾರ್ಗದರ್ಶಿ ಹಾಗೆ ಮಾಡಿದ್ದರೂ, ಏಕೆಂದರೆ ಅಂತಹ ಬದಲಾವಣೆಗಳು ಒಂದು ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗ ಸರಿಪಡಿಸಲು ಇಡೀ ಹೋಸ್ಟ್‌ನ ಅನುಮೋದಿತ VPN ವರ್ತನೆಯನ್ನು ಸರಿಸುತ್ತವೆ.
ಗಮ್ಯಸ್ಥಾನದಲ್ಲಿ ಮೂಲವನ್ನು ದೃಢೀಕರಿಸಿ
ವಿನಂತಿ ಬರುವಲ್ಲಿ ಮೂಲವನ್ನು ಓದಿ, ಅದು ಹೋಗುವಲ್ಲಿ ಅಲ್ಲ. ಗಮ್ಯಸ್ಥಾನದ ಅಪ್ಲಿಕೇಶನ್ ಲಾಗ್, ಅಥವಾ ಅದರ ಮುಂದಿನ ಎಡ್ಜ್ ಸಾಧನ, ಅದು ನಿಜವಾಗಿ ನೋಡಿದ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರಾಕ್ಸಿ ತನ್ನ ಉದ್ದೇಶವನ್ನು ಮಾತ್ರ ಹೇಳಬಲ್ಲದು. ಬದಲಾವಣೆಯ ನಂತರ ಉದ್ದೇಶಿತ ಆಲಿಸುವವರ ಮೂಲಕ ಒಂದು ಹೊಸ ವಿನಂತಿ ಮಾಡಿ, ಏಕೆಂದರೆ ಕ್ಯಾಶ್‌ನಲ್ಲಿರುವ ಸಂಪರ್ಕವು ಹೊಸ ಬಂಧನದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ನಂತರ ದಾಖಲಾದ ವಿಳಾಸವನ್ನು ನೀವು ಹೊಂದಿಸಿದ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ.
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl ಕೇವಲ ಸಂಚಾರ ಜನಕ; ಪರಿಶೀಲಿಸಲು ಯೋಗ್ಯವಾದ ವಿಳಾಸ ದೂರದ ಬದಿ ದಾಖಲಿಸಿದ್ದು, curl ಆಕಸ್ಮಿಕವಾಗಿ ಸಂಪರ್ಕಿಸಿದ ಸಹಚರನಲ್ಲ. ಎರಡೂ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ವ್ಯತ್ಯಾಸ ಮೂಲ-ಆಯ್ಕೆಯಿಂದ ಬರುತ್ತದೆಯೇ ಅಥವಾ ಮುಂದಿನ ಪರಿವರ್ತನೆಯಿಂದ ಎಂದು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಅವು ಬೇರೆ ಬೇರೆ ಕಡೆ ಸರಿಪಡಿಸಲ್ಪಡುತ್ತವೆ. ವಿಳಾಸ ಬದಲಾವಣೆಗಳು ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಮರುಪ್ರಾರಂಭವನ್ನು ಒಟ್ಟಿಗೆ ಯೋಜಿಸಿ, ಏಕೆಂದರೆ ಟನೆಲ್ ಇನ್ನು ಹೊಂದಿಲ್ಲದ ವಿಳಾಸವನ್ನು ಬಂಧಿಸುವುದು ಮರುಸಂಪರ್ಕದ ನಂತರ ಸದ್ದಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ. DNS ಮತ್ತು IPv6 ವರ್ತನೆಯನ್ನೂ ಪ್ರತ್ಯೇಕವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಿ, ಏಕೆಂದರೆ ಮೇಲಿನ IPv4 ತುಣುಕು ಎರಡರ ಬಗ್ಗೆಯೂ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.