Redsocks ಲೂಪ್ಬ್ಯಾಕ್ನಲ್ಲಿ ಕೇಳುತ್ತದೆ ಆದರೆ VPN ಸಂಚಾರ ಎಂದಿಗೂ ಬರುತ್ತಿಲ್ಲ

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

ಮರುನಿರ್ದೇಶಿಸಿದ ಪ್ಯಾಕೆಟ್ ನಿಜವಾಗಿ ಎಲ್ಲಿ ಇಳಿಯುತ್ತದೆ

ಗೇಟ್ವೇಯಲ್ಲಿನ ಪಾರದರ್ಶಕ ಪ್ರಾಕ್ಸಿ PREROUTING ನಲ್ಲಿ nat ಕೋಷ್ಟಕದ REDIRECT ಬಳಸಿ ಬರುವ ಸಂಪರ್ಕದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಸ್ಥಳೀಯ ಪೋರ್ಟ್ಗೆ ಪುನಃ ಬರೆಯುತ್ತದೆ. ಪುನಃ ಬರೆದ ಗಮ್ಯಸ್ಥಾನವು ಪ್ಯಾಕೆಟ್ ಬಂದ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಕಾಣುವ ಸ್ಥಳೀಯ ವಿಳಾಸ, ಬೇರೆಡೆ ಪ್ರಾರಂಭಿಸಿದ ಪ್ರಕ್ರಿಯೆಯ ಲೂಪ್ಬ್ಯಾಕ್ ವಿಳಾಸವಲ್ಲ. ಕೇವಲ 127.0.0.1 ಗೆ ಬದ್ಧವಾದ ಆಲಿಸುವವನು ಈಗಾಗಲೇ ಹೋಸ್ಟ್ನಲ್ಲಿ ಸ್ಥಳೀಯವಾಗಿದ್ದ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಸುರಂಗ ಸಂಚಾರ ವಿಫಲವಾದಾಗ ಕೆಲಸ ಮುಂದುವರಿಸುವ ಸಂದರ್ಭ ನಿಖರವಾಗಿ ಅದೇ. ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಲೂಪ್ಬ್ಯಾಕ್ ಮೂರನೇ ವಿಳಾಸ ಮತ್ತು ಎಂದಿಗೂ ಗೇಟ್ವೇ ನಿಯಮದ ಗುರಿಯಲ್ಲ.

ಆದ್ದರಿಂದ ಅಪ್ಸ್ಟ್ರೀಮ್ ರುಜುವಾತುಗಳನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಎರಡು ಸಂಗತಿಗಳನ್ನು ಸ್ಥಾಪಿಸಿ: ನಿಯಮವು ಯಾವ ಸ್ಥಳೀಯ ವಿಳಾಸಕ್ಕೆ ಪುನಃ ಬರೆಯುತ್ತದೆ, ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಸಾಕೆಟ್ ಯಾವ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾಗಿದೆ.

ಆಲಿಸುವವನು ಮತ್ತು ಮರುನಿರ್ದೇಶನ ನಿಯಮವನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ

ಸಾಕೆಟ್ ಕೋಷ್ಟಕ ಮತ್ತು nat ನಿಯಮಗಳನ್ನು ಒಂದೇ ಹಾದಿಯಲ್ಲಿ ಮುದ್ರಿಸಿ, ಏಕೆಂದರೆ ಯಾರೂ ಹೊಂದಿರದ ಪೋರ್ಟ್ಗೆ ತೋರಿಸುವ ನಿಯಮವು ತಪ್ಪು ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುವ ನಿಯಮದಂತೆಯೇ ಕಾಣುತ್ತದೆ. sudo ss -ltnp | grep redsocks ಬೈಂಡ್ ವಿಳಾಸ ಮತ್ತು ಮಾಲೀಕ ಪ್ರಕ್ರಿಯೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. sudo iptables -t nat -S PREROUTING REDIRECT ಗುರಿಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು sudo iptables -t nat -L PREROUTING -v -n ಅದಕ್ಕೆ ಏನಾದರೂ ಹೊಂದಿಕೆಯಾದರೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

REDSOCKS ಎಂಬ ಬಳಕೆದಾರ ಸರಪಳಿಗೆ ಜಿಗಿಯುವುದು ಆ ಸರಪಳಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿದ್ದರೆ ಮತ್ತು ಉದ್ದೇಶಿತ ಹೊರಗಿಡುವಿಕೆಗಳು ಹಾಗೂ REDIRECT ಕ್ರಿಯೆಯನ್ನು ಹೊತ್ತಿರದಿದ್ದರೆ ಏನನ್ನೂ ಸಾಧಿಸುವುದಿಲ್ಲ. ಹೆಸರೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು sudo iptables -t nat -S REDSOCKS ಬಳಸಿ ಅದು ಜಿಗಿಯುವ ಸರಪಳಿಯನ್ನು ಓದಿ.

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

ಸಂಕುಚಿತವಾಗಿ ಬಂಧಿಸಿ, ನಂತರ ಅದನ್ನು ಏನು ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ಮಿತಿಗೊಳಿಸಿ

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

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

ಕ್ಲೈಂಟ್ನಿಂದ ಹೊಸ ಸಂಪರ್ಕದೊಂದಿಗೆ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಿ

ಗೇಟ್ವೇಯ ಶೆಲ್ನಿಂದಲ್ಲ, ನಿಜವಾದ VPN ಕ್ಲೈಂಟ್ನಿಂದ ಹೊಸ TCP ಸಂಪರ್ಕದೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ. ಕ್ಲೈಂಟ್ನಲ್ಲಿ curl -sS -o /dev/null -w '%{http_code}\n' http://example.com ಮರುನಿರ್ದೇಶಿತ ಮಾರ್ಗವನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಚಲಾಯಿಸುತ್ತದೆ.

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

ಕೊನೆಯದಾಗಿ, ಈ ಮಾರ್ಗವು ಏನನ್ನು ಆವರಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ಸಾಮಾನ್ಯ redsocks TCP ಮರುನಿರ್ದೇಶನವು UDP, QUIC ಅಥವಾ DNS ಅನ್ನು SOCKS ಸಂಚಾರವಾಗಿ ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಖಾಸಗಿ ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಪಷ್ಟ ಹೊರಗಿಡುವಿಕೆಗಳು ಬೇಕು. ಯಶಸ್ವಿ ಸ್ಥಳೀಯ ಪರೀಕ್ಷೆಯು ಎಂದಿಗೂ ಸಮಸ್ಯೆಯಾಗಿರದ ಲೂಪ್ಬ್ಯಾಕ್ ಮಾರ್ಗವನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.