VPN ಮತ್ತೆ ಸಂಪರ್ಕಗೊಂಡ ನಂತರ ಪ್ರಾಕ್ಸಿ ಇನ್ನೂ ಹಳೆಯ ಟನಲ್ ವಿಳಾಸದಲ್ಲಿದೆಯೇ?

VPN ಕ್ಲೈಂಟ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು ಟನಲ್ ಮರಳಿ ಬಂದಿದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಅದರ ಮೂಲಕ ಹೊರಹೋಗಲು ಹೇಳಲಾದ ಪ್ರಾಕ್ಸಿ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. Squid, tinyproxy ಮತ್ತು ಇತರ ಹೆಚ್ಚಿನ ಫಾರ್ವರ್ಡರ್ಗಳು ಪ್ರಾರಂಭದಲ್ಲಿ ಕಂಡುಕೊಂಡ ಸ್ಥಳೀಯ ಮೂಲ ವಿಳಾಸವನ್ನು ಯಾವುದೋ ಅವುಗಳನ್ನು ಮರುಲೋಡ್ ಮಾಡಲು ಒತ್ತಾಯಿಸುವವರೆಗೆ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತವೆ. ಮತ್ತೆ ಸಂಪರ್ಕಗೊಳ್ಳುವುದು ಹೊಸ ಟನಲ್ ವಿಳಾಸವನ್ನು ನೀಡಿದಾಗ, ಫಾರ್ವರ್ಡರ್ ಪ್ರತಿ ಹೊರಹೋಗುವ ಸಂಪರ್ಕದಲ್ಲೂ ವಿಫಲವಾಗುತ್ತದೆ, ಅಥವಾ ನಿಮ್ಮ ಸಾಮಾನ್ಯ ಮಾರ್ಗದ ಮೂಲಕ ಹೊರಹೋಗಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಎರಡನೇ ವೈಫಲ್ಯವೇ ಅಪಾಯಕಾರಿ: ಟನಲ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ಪುಟಗಳು ಲೋಡ್ ಆಗುತ್ತಿವೆ, ಮತ್ತು ಹೊರಹೋಗುವ ವಿಳಾಸ ಮಾತ್ರ ತಪ್ಪಾಗಿದೆ.

ಟನಲ್ನಿಂದಲ್ಲ, ಶ್ರೋತೃದಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಆಟದಲ್ಲಿ ಮೂರು ವಿಳಾಸಗಳಿವೆ, ಮತ್ತು ಮತ್ತೆ ಸಂಪರ್ಕಗೊಳ್ಳುವುದು ಅವುಗಳಲ್ಲಿ ಕೆಲವನ್ನು ಮಾತ್ರ ಸರಿಸುತ್ತದೆ. ಶ್ರೋತೃ ಎಂದರೆ ನಿಮ್ಮ ಬ್ರೌಸರ್ ತೋರಿಸುವ ಸ್ಥಳ, ಸಾಮಾನ್ಯವಾಗಿ 127.0.0.1 ಅಥವಾ LAN ವಿಳಾಸ, ಮತ್ತು ಟನಲ್ ಬದಲಾದುದು ಅದಕ್ಕೆ ಪರವಾಗಿಲ್ಲ. ಹೊರಹೋಗುವ ಸ್ಥಳೀಯ ಮೂಲ ಎಂದರೆ ಫಾರ್ವರ್ಡರ್ ಮುಂದಿನ ಹೆಜ್ಜೆಗೆ ಡಯಲ್ ಮಾಡುವಾಗ ಕರ್ಣಲ್ಗೆ ಬಳಸಲು ಕೇಳುವುದು, ಮತ್ತು ಅದು ಟನಲ್ ಸಾಧನಕ್ಕೆ ಬಂಧಿತವಾಗಿದೆ. ಸಾರ್ವಜನಿಕ ನಿರ್ಗಮನ ಎಂದರೆ ವೆಬ್ ಸರ್ವರ್ ದಾಖಲಿಸುವುದು, ಮತ್ತು ಅದು ಹಲವು ಹೆಜ್ಜೆಗಳ ದೂರದ ಅನುವಾದಿತ ವಿಳಾಸವಾಗಿರಬಹುದು.

ಸಾರ್ವಜನಿಕ IP ಹುಡುಕಾಟ ಕೊನೆಯ ಪ್ರಶ್ನೆಗೆ ಮಾತ್ರ ಉತ್ತರಿಸುತ್ತದೆ. ಒಂದು ಸಾರ್ವಜನಿಕ ನಿರ್ಗಮನ ಹಲವು ಆಂತರಿಕ ಮೂಲಗಳನ್ನು ಮರೆಮಾಡಬಹುದಾದ್ದರಿಂದ, ಫಾರ್ವರ್ಡರ್ ಯಾವ ಸ್ಥಳೀಯ ವಿಳಾಸಕ್ಕೆ ಬಿಗಿಯಬೇಕು ಎಂದು ಅದು ಹೇಳಲಾರದು. ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿರುವವರಿಂದ ವಿಳಾಸ ಓದಿ: ಕ್ಲೈಂಟ್ನ ಸ್ಥಿತಿ ಔಟ್ಪುಟ್, ಇಂಟರ್ಫೇಸ್ ಸ್ವತಃ, ಅಥವಾ ಟನಲ್ ಇರುವ ನಾಮಸ್ಥಳ. ಟನಲ್ನಂತೆ ಕಾಣುವ ಹೆಸರಿನ ಮೊದಲ ಇಂಟರ್ಫೇಸ್ ಹಿಡಿಯುವುದು ಎರಡನೇ ಪ್ರೊಫೈಲ್ ಇದ್ದ ಕ್ಷಣ ತಪ್ಪು ಉತ್ತರ ನೀಡುತ್ತದೆ.

ಕಂಟೇನರ್ ಮತ್ತು ನಾಮಸ್ಥಳ ವಿನ್ಯಾಸಗಳು ಈ ಊಹೆಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ಮುರಿಯುತ್ತವೆ. ಒಂದು ನೆಟ್ವರ್ಕ್ ನಾಮಸ್ಥಳದಲ್ಲಿರುವ ಫಾರ್ವರ್ಡರ್ ಇನ್ನೊಂದರಲ್ಲಿರುವ ಟನಲ್ಗೆ ಬಿಗಿಯಲಾರದು, ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಸಂಪಾದನೆಯ ಯಾವುದೇ ಪ್ರಮಾಣ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

ಏನನ್ನಾದರೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳು

ಇವನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ. ಮೊದಲ ವಿಫಲ ಪರಿಶೀಲನೆಯೇ ನೀವು ನಿಲ್ಲುವ ಸ್ಥಳ, ಏಕೆಂದರೆ ಮುಂದಿನವು ಹಿಂದಿನವು ನಿಜ ಎಂದು ಊಹಿಸುತ್ತವೆ.

1. ಬಳಸುತ್ತಿರುವ ಟನಲ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ಸುತ್ತಲೂ ನಿರ್ಮಿಸಿದ ಪ್ರೊಫೈಲ್ ಎಂದು ಖಚಿತಪಡಿಸಿ, ತಾನಾಗಿ ಸಂಪರ್ಕಗೊಂಡ ಎರಡನೇ ಪ್ರೊಫೈಲ್ ಅಲ್ಲ.
2. ಆ ಸಾಧನದಲ್ಲಿರುವ ಪ್ರಸ್ತುತ ವಿಳಾಸವನ್ನು ಮುದ್ರಿಸಿ ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿರುವ ಕಾನ್ಫಿಗರೇಶನ್ನ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ.
3. ಡಿಸ್ಕ್ನಲ್ಲಿರುವ ಫೈಲ್ ಹೇಳುವುದಲ್ಲ, ಫಾರ್ವರ್ಡರ್ ಯಾವ ಮೂಲವನ್ನು ಕಂಡುಕೊಂಡಿತು ಎಂದು ಕೇಳಿ.
4. ಫಾರ್ವರ್ಡರ್ನಿಂದ ಬರುವ ಸಂಚಾರವು ನಿಜವಾಗಿಯೂ ನೀವು ನಿರೀಕ್ಷಿಸುವ ರೂಟಿಂಗ್ ಮತ್ತು ಫೈರ್ವಾಲ್ ನೀತಿಗೆ ಒಳಪಟ್ಟಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ಸಾಧನದ ವಿಳಾಸ ಸುಲಭ: ip -4 addr show dev tun0 ಪ್ರಸ್ತುತದ್ದನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ip -4 route get 1.1.1.1 ಆ ಗಮ್ಯಕ್ಕೆ ಕರ್ಣಲ್ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ನಿಖರ ವಿಳಾಸಕ್ಕೆ ಬಿಗಿಯುವ ಫಾರ್ವರ್ಡರ್ ವಿಳಾಸ ಕಣ್ಮರೆಯಾದಾಗ ಗಟ್ಟಿಯಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ. ಸಾಧನಕ್ಕೆ ಬಿಗಿಯುವ, ಅಥವಾ ಡೀಫಾಲ್ಟ್ ಮೂಲಕ್ಕೆ ಹಿಂತಿರುಗುವ ಫಾರ್ವರ್ಡರ್ ಕೆಲಸ ಮುಂದುವರಿಸಿ ಸೋರುತ್ತದೆ, ಮತ್ತು ಅದೇ ಶಾಂತ ಫಲಿತಾಂಶ.

ದಾಖಲೆಗಳನ್ನು ನೀವು ಚಲಾಯಿಸುವ ಆವೃತ್ತಿಗೆ ಹೊಂದಿಸಿ, ಹುಡುಕಾಟದ ಮೇಲ್ಭಾಗದ ಫಲಿತಾಂಶಕ್ಕಲ್ಲ. Squid ನ ಹೊರಹೋಗುವ ವಿಳಾಸ ಸೂಚನೆಯು v7 ಮತ್ತು ಹಿಂದಿನವುಗಳಿಗೆ ದಾಖಲಾಗಿದೆ, ಮತ್ತು v8 ದಾಖಲೆಗಳು ಆ ಸೂಚನೆ ಅಲ್ಲಿ ಲಭ್ಯವಿಲ್ಲ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಅದರ ಸುತ್ತ ನಿರ್ಮಿಸಿದ ಸ್ಕ್ರಿಪ್ಟ್ ಆ ಗಡಿಯನ್ನು ದಾಟುವುದಿಲ್ಲ (Squid tcp_outgoing_address ಉಲ್ಲೇಖ ನೋಡಿ). ಏನನ್ನಾದರೂ ಮರುಲೋಡ್ ಮಾಡುವ ಮೊದಲು ಉತ್ಪನ್ನದ ಸ್ವಂತ ಪಾರ್ಸರ್ನಿಂದ ಪರಿಶೀಲಿಸಿ: squid -k parse ದೋಷಗಳನ್ನು ವರದಿ ಮಾಡಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮುಟ್ಟದೆ ನಿರ್ಗಮಿಸುತ್ತದೆ.

ಪ್ರತಿ ಟನಲ್ ಅನ್ನು ಸಂಖ್ಯೆ ಮಾಡಿ ಮತ್ತು ಹಳೆಯ ಬದಲಾವಣೆಗಳನ್ನು ಎಸೆಯಿರಿ

ಮತ್ತೆ ಸಂಪರ್ಕಗೊಳ್ಳುವುದು ಹಸ್ತಾಂತರ, ಮತ್ತು ಹಸ್ತಾಂತರಕ್ಕೆ ಕ್ರಮ ಬೇಕು. ಗಮನಿಸಿದ ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕೆ ಪ್ರತಿ ಯಶಸ್ವಿ ಸ್ಥಾಪನೆಯಲ್ಲಿ ಹೆಚ್ಚಾಗುವ ಕೌಂಟರ್ ಅಥವಾ ಸಮಯ ಮುದ್ರೆಯ ಟ್ಯಾಗ್ ಹಾಕಿ, ನಂತರ ಆ ಟ್ಯಾಗ್ ಅನ್ನು ಅಭ್ಯರ್ಥಿ ಕಾನ್ಫಿಗರೇಶನ್ ಒಳಗೆ ಒಯ್ಯಿರಿ. ಅಭ್ಯರ್ಥಿಯ ಮೇಲಿನ ಟ್ಯಾಗ್ ಪ್ರಸ್ತುತದ್ದಕ್ಕಿಂತ ಹಳೆಯದಾದಾಗ, ಅದನ್ನು ಅನ್ವಯಿಸುವ ಬದಲು ಅಭ್ಯರ್ಥಿಯನ್ನು ಎಸೆಯಿರಿ, ಏಕೆಂದರೆ ಹಿಂದಿನ ಟನಲ್ಗೆ ಬರೆದ ನಿಧಾನ ನವೀಕರಣವು ಇಲ್ಲದಿದ್ದರೆ ಪ್ರಸ್ತುತದ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಅಳಿಸಿಹಾಕುತ್ತದೆ. ಘಟನೆಗಳ ಸ್ಫೋಟಗಳನ್ನು ಸೇರಿಸಿ, ಅಲುಗಾಡುವ ಲಿಂಕ್ ಹದಿನೈದಕ್ಕಿಂತ ಒಂದೇ ಪರಿವರ್ತನೆ ನೀಡಲಿ.

ಕೆಲಸವನ್ನು ನಾಲ್ಕು ಹೆಜ್ಜೆಗಳಲ್ಲಿ ಜೋಡಿಸಿ: ಹಳೆಯ ನಿರ್ಗಮನ ಸ್ಥಿತಿಯನ್ನು ಅಮಾನ್ಯಗೊಳಿಸಿ, ಸಂಪರ್ಕದ ಮಾಲೀಕರು ಪೂರ್ಣಗೊಂಡದ್ದನ್ನು ವರದಿ ಮಾಡುವವರೆಗೆ ಕಾಯಿರಿ, ನಿರ್ವಹಿತ ತುಣುಕನ್ನು ಮಾತ್ರ ನಿರ್ಮಿಸಿ, ನಂತರ ಸೇವಾ ವ್ಯವಸ್ಥಾಪಕ ಮೂಲಕ ಪರಿಶೀಲಿಸಿ ಸಕ್ರಿಯಗೊಳಿಸಿ. ಎರಡು ವಿಳಾಸ ಮೌಲ್ಯಗಳಿಂದ ಇಡೀ ಫೈಲ್ ಅನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದೇ ಶ್ರೋತೃ ನಿರ್ಬಂಧಗಳು, ದೃಢೀಕರಣ ಮತ್ತು ಗಮ್ಯ ನೀತಿ ಸದ್ದಿಲ್ಲದೆ ಮಾಯವಾಗುವ ದಾರಿ. ಉದ್ದೇಶಪೂರ್ವಕ ನಿಲುಗಡೆಯನ್ನೂ ಗೌರವಿಸಿ. ಬಳಕೆದಾರರು ಆಫ್ ಮಾಡಿದ ಟನಲ್ಗೆ ಡಯಲ್ ಮಾಡುತ್ತಲೇ ಇರುವ ಸಹಾಯಕ ಬಗ್, ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವಲ್ಲ.

ತೆರೆದ ಸಾಕೆಟ್ಗಳು ಹೊಸ ವಿಳಾಸವನ್ನು ಅನುಸರಿಸುವುದಿಲ್ಲ

ಫಾರ್ವರ್ಡರ್ ಅನ್ನು ಮರುಸಂರಚಿಸುವುದು ಈಗಾಗಲೇ ಸ್ಥಾಪಿತವಾದ ಸಂಪರ್ಕಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಅವು ಖಾಲಿಯಾಗುತ್ತವೆಯೇ ಅಥವಾ ಸಾಯುತ್ತವೆಯೇ ಎಂಬುದು ಉತ್ಪನ್ನವನ್ನು ಅವಲಂಬಿಸಿದೆ, ಆದ್ದರಿಂದ ಊಹಿಸುವ ಬದಲು ವರ್ತನೆಯನ್ನು ಗಮನಿಸಿ.

ಬದಲಾವಣೆಗೆ ಮೊದಲು ತೆರೆದ ಸಾಕೆಟ್ ಮೂಲಕ ನೀಡಲಾದ ವಿನಂತಿ ಹೊಸ ಕಾನ್ಫಿಗರೇಶನ್ ಸರಿಯಾಗಿದ್ದರೂ ಹಳೆಯ ಮಾರ್ಗದಿಂದಲೇ ಹೊರಹೋಗುತ್ತದೆ. ಅದು ಮುಖ್ಯವಾದರೆ ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ಧರಿಸಿ: ಸಣ್ಣ ಖಾಲಿ ಮಾಡುವ ಅವಧಿ ನೀಡಿ ಹೊಸ ಕೆಲಸ ಸ್ವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಅಥವಾ ಹಳೆಯ ಸಾಕೆಟ್ಗಳನ್ನು ಮುಚ್ಚಿ ದೋಷಗಳನ್ನು ಸ್ವೀಕರಿಸಿ. ನಂತರ ಹೊಸ ಸಂಪರ್ಕದಿಂದ ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಆ ಫಲಿತಾಂಶವನ್ನು ಖಾಲಿ ಮಾಡುವ ಪರಿಶೀಲನೆಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಮೂಲಕ್ಕೆ ಬಿಗಿಯುವುದೂ ಭದ್ರತಾ ಗಡಿಯಲ್ಲ. ಸಂಚಾರ ಎಂದಿಗೂ ಸಾಮಾನ್ಯ ಮಾರ್ಗವನ್ನು ಮುಟ್ಟಬಾರದಿದ್ದರೆ, ಗುರುತುಗಳು ಮತ್ತು ಫೈರ್ವಾಲ್ ನಿಯಮಗಳಿಂದ, DNS ಮತ್ತು IPv6 ಸೇರಿಸಿ ಜಾರಿಗೊಳಿಸಿ, ವಿಫಲ ಮರುಲೋಡ್ ಪ್ರಾಕ್ಸಿಯನ್ನು ತೆರೆದಿಡುವ ಬದಲು ಸ್ಪಷ್ಟವಾಗಿ ಆಫ್ ಇರಿಸಲಿ.

ಹೊಸ ನಿರ್ಗಮನವನ್ನು ಹೊಸ ವಿನಂತಿಯಿಂದ ಸಾಬೀತುಪಡಿಸಿ

ಮುಖ್ಯವಾದದ್ದು ಸಕ್ರಿಯಗೊಳಿಸಿದ ನಂತರ ತೆರೆದ ವಿನಂತಿ, ping ಅಲ್ಲ ಮತ್ತು ಈಗಾಗಲೇ ಕ್ಯಾಶ್ ಆದ ಪುಟವಲ್ಲ. ಪ್ರಾಕ್ಸಿಯನ್ನು ನಿಜವಾದ URL ಕೇಳಿ ಮತ್ತು ದೂರದ ತುದಿ ವರದಿ ಮಾಡುವ ನಿರ್ಗಮನ ವಿಳಾಸ ಓದಿ, ನಂತರ ಪೂರೈಕೆದಾರರು ಒಂದನ್ನು ತೋರಿಸಿದಾಗ ಕ್ಲೈಂಟ್ನ ಟನಲ್ ಕುರಿತಾದ ತನ್ನದೇ ದೃಷ್ಟಿಕೋನದೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಪಾರ್ಸಿಂಗ್, ಮರುಲೋಡ್ ಮತ್ತು ವಿನಂತಿಯನ್ನು ಪ್ರತ್ಯೇಕ ಆದೇಶಗಳಾಗಿ ಇರಿಸಿ, ವೈಫಲ್ಯ ಒಂದೇ ಹೆಜ್ಜೆಯನ್ನು ತೋರಿಸಲಿ. ಮೊದಲೆರಡು ವಿಫಲವಾದಾಗ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಅವು ಮರುಪ್ರಾರಂಭಕ್ಕೆ ಮೊದಲು ಚಲಿಸುತ್ತವೆ.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

ಮರುಲೋಡ್ ವಿಫಲವಾದರೆ ಸೇವೆಯನ್ನು ನಿಲ್ಲಿಸಿ ತುಣುಕನ್ನು ಸರಿಪಡಿಸಿ; ಹಳೆಯ ನಿರ್ಗಮನದಿಂದ ಸೇವೆ ನೀಡುವ ಪ್ರಾಕ್ಸಿ ಸಣ್ಣ ಅಡಚಣೆಗಿಂತ ಕೆಟ್ಟದು. ಮರುಲೋಡ್ ಯಶಸ್ವಿಯಾಗಿ ಹೊಸ ವಿನಂತಿ ಇನ್ನೂ ಎಲ್ಲೋ ಅನಿರೀಕ್ಷಿತವಾಗಿ ಹೊರಹೋದರೆ, ವಿಳಾಸಗಳನ್ನು ಮತ್ತೆ ಸಂಪಾದಿಸುವ ಬದಲು ರೂಟಿಂಗ್ ಪರಿಶೀಲನೆಗೆ ಮರಳಿ. ನೀವು ಪರಿಶೀಲಿಸಿದ ಟನಲ್ ಪೀಳಿಗೆಯನ್ನು ದಾಖಲಿಸಿ, ಮುಂದಿನ ಮತ್ತೆ ಸಂಪರ್ಕಕ್ಕೆ ಹೋಲಿಸಲು ನಿರ್ದಿಷ್ಟವಾದದ್ದು ಇರಲಿ.