TLS ರ್ಯಾಪರ್ ಅನ್ನು OpenVPN ಮುಂದೆ ಇರಿಸಿ ಮತ್ತು ನಿಯೋಜನೆಗೆ ಎರಡನೇ ಲಿಸನರ್ ಸಿಗುತ್ತದೆ, ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಎಂದಿಗೂ ಇಂಟರ್ನೆಟ್ ಎದುರು ನಿಲ್ಲಬಾರದು. ಸುರಂಗವು ಅದೇ ಯಂತ್ರದಿಂದ ಕೆಲಸ ಮಾಡಿ ಹೊರಗಿನಿಂದ ವಿಫಲವಾದಾಗ, ಫಾರ್ವರ್ಡ್ ಸಾಮಾನ್ಯವಾಗಿ ಎರಡರಲ್ಲಿ ತಪ್ಪಾದದ್ದನ್ನು ಗುರಿಯಾಗಿಸಿರುತ್ತದೆ. ಹೊಂದಿಕೆಯಾಗಬೇಕಾದದ್ದು ಒಂದು ಸರಪಳಿ: ಸಾರ್ವಜನಿಕ ನಿಯಮ ರ್ಯಾಪರ್ ತಲುಪುತ್ತದೆ, ಮತ್ತು ರ್ಯಾಪರ್ನ ಸ್ವಂತ ಬ್ಯಾಕೆಂಡ್ ಸಂಪರ್ಕ ನಿಜವಾದ VPN ಸಾಕೆಟ್ ತಲುಪುತ್ತದೆ. ನಾಲ್ಕು ಜಿಗಿತಗಳು ಈ ಸರಪಳಿಯನ್ನು ಹೊರುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ತನಿಖೆಯನ್ನು ಬೇಗ ಮುಗಿಸಬಹುದು.

ಎರಡು ಸಾಕೆಟ್, ಎರಡು ಮಾಲೀಕ, ಒಂದು ಸಾರ್ವಜನಿಕ

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

ಯಂತ್ರದಿಂದಲೇ ಕೆಲಸ ಮಾಡುವುದು ಸಾರ್ವಜನಿಕ ಮಾರ್ಗದ ಬಗ್ಗೆ ಬಹಳ ಕಡಿಮೆ ಸಾಬೀತು ಮಾಡುತ್ತದೆ. ಮೂಲ ಪೋರ್ಟ್ಗೆ ನೇರ ಸಂಪರ್ಕ ರ್ಯಾಪರ್ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ರ್ಯಾಪರ್ನ LAN ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕ ಅನುವಾದ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಮತ್ತು ಹೊರಗಿನ ಬಳಕೆದಾರ ಏನು ಮಾಡುತ್ತಾನೆ ಎಂಬುದನ್ನು ಗ್ರಾಹಕ ಬದಿಯ ಪೂರ್ಣ ವ್ಯವಸ್ಥೆ ಮಾತ್ರ ಅಭ್ಯಾಸ ಮಾಡುತ್ತದೆ. ಹೆಸರುಗಳನ್ನೂ ಎಚ್ಚರಿಕೆಯಿಂದ ಓದಬೇಕು, ಏಕೆಂದರೆ localhost ಆ ಘಟಕವನ್ನು ಚಲಾಯಿಸುತ್ತಿರುವ ಹೋಸ್ಟ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ, ನೀವು ಆಕಸ್ಮಿಕವಾಗಿ ಟೈಪ್ ಮಾಡುತ್ತಿರುವ ಹೋಸ್ಟ್ ಅಲ್ಲ. ಈ ವ್ಯತ್ಯಾಸವನ್ನು ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ತಾನು ಒಳಗೊಂಡ ಜಿಗಿತವನ್ನು ದಾಖಲಿಸದ ಪರೀಕ್ಷೆ ಎರಡು ವಿಭಿನ್ನ ವಸ್ತುಗಳ ಹೋಲಿಕೆಗೆ ಆಹ್ವಾನಿಸುತ್ತದೆ.

ಫಾರ್ವರ್ಡ್ ನಿಜವಾಗಿ ಎಲ್ಲಿ ಇಳಿಯುತ್ತದೆ

ಸರಪಳಿಯನ್ನು ಮೂರು ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳಿಗಿಂತ ನಾಲ್ಕು ಜಿಗಿತಗಳಾಗಿ ಹಿಡಿದಿಡುವುದು ಸುಲಭ, ಏಕೆಂದರೆ ಒಂದೇ ಸಂಖ್ಯೆ ಪ್ರತಿ ತುದಿಯಲ್ಲಿ ಬೇರೆ ಅರ್ಥ ನೀಡಬಹುದು. ಕೋಷ್ಟಕವನ್ನು ಸಾಲು ಸಾಲು ಓದಿ: ಪ್ರತಿ ಸಾಲು ಒಂದು ಸಾಕೆಟ್, ಅದು ಸಂಪರ್ಕ ಸ್ವೀಕರಿಸಿ ನಂತರ ಮುಂದಿನದನ್ನು ತೆರೆಯಬೇಕು. ಸಾಲು ತಪ್ಪು ಜೋಡಿಗೆ ಗುರಿಯಾದಾಗ, ಕೊನೆಯ ಕಾಲಮ್ನ ಲಕ್ಷಣವೇ ಬಳಕೆದಾರ ವರದಿ ಮಾಡುವುದು.

HopListens onMust reachSymptom when it points elsewhere
Client machineA local plaintext portThe wrapper's public TLS addressPlain text offered to a TLS endpoint
Router forwardPublic TCP 443The wrapper host on its translated portWrapper records no connection at all
Wrapper, server modeIts accepted port, 8443 hereThe native VPN socket on loopbackHandshake completes, then silence
Native VPN listenerLoopback TCP portIts peer, over TCP onlyA UDP socket behind a byte-stream relay

ರ್ಯಾಪರ್ ಬದಲು ಮೂಲ VPN ಪೋರ್ಟ್ ಗುರಿಯಾಗಿಸುವ ನಿಯಮ TLS ಮುಕ್ತಾಯವನ್ನು ಸಂಪೂರ್ಣ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಇದು ಈ ತಪ್ಪಿನ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ರೂಪ: ಕ್ಲೈಂಟ್ OpenVPN ಫ್ರೇಮಿಂಗ್ ನಿರೀಕ್ಷಿಸುವ ಲಿಸನರ್ ಜೊತೆ ಹ್ಯಾಂಡ್ಶೇಕ್ ತೆರೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂಪರ್ಕ ತೆರೆದು ನಂತರ ನಿಲ್ಲಬಹುದು. ಅನುವಾದಿತ ಪೋರ್ಟ್ ಅನ್ನು ನೆನಪಿಗಿಂತ ರ್ಯಾಪರ್ನ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ನೊಂದಿಗೆ ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಆ ಫೈಲ್ ಮುಂದೆ ಸಂಪಾದಿಸುವವರು ಬೇರೆ ಸಂಖ್ಯೆ ಆಯ್ಕೆ ಮಾಡಿರಬಹುದು. ಕೆಳಗಿನ ಎರಡು ಆಜ್ಞೆಗಳು ಆ ಪ್ರಶ್ನೆಯ ಎರಡೂ ಬದಿಗಳನ್ನು ಒಟ್ಟಿಗೆ ತೋರಿಸುತ್ತವೆ.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

ನಿಮ್ಮನ್ನು ನಿರಾಕರಿಸುವ ಬೈಂಡ್ ವಿಳಾಸ

127.0.0.1 ಗೆ ಬದ್ಧವಾದ accept ಸಾಲು ಹೋಸ್ಟ್ಗೆ ಮಾತ್ರ ಉತ್ತರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ LAN ವಿಳಾಸಕ್ಕೆ ಬರುವ ಫಾರ್ವರ್ಡ್ ಸಂಪರ್ಕಿಸಲಾರದು ಮತ್ತು ಕ್ಲೈಂಟ್ಗೆ ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರ್ ಸಮಸ್ಯೆಯಂತೆ ಕೇಳಿಸುವ ನಿರಾಕರಣೆ ಕಾಣುತ್ತದೆ. ಫೈರ್ವಾಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಸಾಕೆಟ್ ನೋಡಿ, ಏಕೆಂದರೆ ಸಾಕೆಟ್ ಅಗ್ಗದ ಉತ್ತರ. ರ್ಯಾಪರ್ ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಗುರಿಯಾಗಿಸುವ ಇಂಟರ್ಫೇಸ್ಗೆ ಬಂಧಿಸಿ, ಅಥವಾ ಅದನ್ನು loopback ನಲ್ಲಿ ಇಟ್ಟು, ನಿಜವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಯಾವುದೋ ಮೂಲಕ ಫಾರ್ವರ್ಡ್ loopback ತಲುಪುವಂತೆ ಮಾಡಿ. ಇವು ಎರಡು ವಿನ್ಯಾಸಗಳು, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ನಿಯಮ ಬೇಕು.

ಎರಡನ್ನೂ ಬೆರೆಸುವುದೇ ಕೆಲಸ ಮಾಡುವ ರ್ಯಾಪರ್ ಹೊರಗಿನಿಂದ ತಲುಪಲಾಗದಂತಾಗುವ ದಾರಿ, ಆದರೆ ಪ್ರತಿ ಫೈಲ್ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ. ಕೆಳಗಿನ ಪರಿಶೀಲನೆ ಒಂದು ಆಜ್ಞೆ, ಮತ್ತು ಫೈರ್ವಾಲ್ ನಿಯಮಗಳ ಪರಿಶೀಲನೆ ಉತ್ತರಿಸಲಾಗದ ಪ್ರಶ್ನೆಗೆ ಅದು ಉತ್ತರಿಸುತ್ತದೆ. ಔಟ್ಪುಟ್ loopback ವಿಳಾಸ ತೋರಿಸಿ, ಫಾರ್ವರ್ಡ್ LAN ವಿಳಾಸ ಗುರಿಯಾಗಿಸಿದರೆ, ಸರಿಪಡಿಸುವುದು accept ಸಾಲಿನಲ್ಲಿ, ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರ್ನಲ್ಲಿ ಅಲ್ಲ.

ss -lntp '( sport = :8443 )'

ಸ್ಥಳೀಯ ಪರೀಕ್ಷೆ ನಿಜವಾಗಿ ಏನು ಸಾಬೀತು ಮಾಡಿತು

ತಾನು ಒಳಗೊಂಡ ಜಿಗಿತವನ್ನು ದಾಖಲಿಸದ ಯಶಸ್ಸು ಬೇರೆ ಜಿಗಿತಗಳ ಬಗ್ಗೆ ಸಾಕ್ಷಿಯಲ್ಲ. ಪರೀಕ್ಷೆ ಯಾವ ವಿಳಾಸ ಬಳಸಿತು ಮತ್ತು ಯಾವ ಪ್ರಕ್ರಿಯೆ ಉತ್ತರಿಸಿತು ಎಂದು ಬರೆದಿಡಿ. ನಂತರ ಅದೇ Wi-Fi ನ ಫೋನ್ನಿಂದ ಅಲ್ಲ, ಜಾಲದ ಹೊರಗಿನಿಂದ ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಹೇರ್ಪಿನ್ ವರ್ತನೆ ರೌಟರ್ಗಳ ನಡುವೆ ಬದಲಾಗುತ್ತದೆ ಮತ್ತು LAN ಬಿಟ್ಟು ಎಂದೂ ಹೋಗದ ಸಂಪರ್ಕವೂ ಫಾರ್ವರ್ಡ್ ಸಂಪೂರ್ಣ ಒಳಗೊಳ್ಳದೆ ಕ್ಲೈಂಟ್ ತೃಪ್ತಿಪಡಿಸಬಹುದು. ಆ ಎರಡನೇ ಪ್ರಯತ್ನ ಮಾತ್ರ ಅಪರಿಚಿತ ವ್ಯಕ್ತಿ ಹೋಗುವ ಮಾರ್ಗವನ್ನು ಅಭ್ಯಾಸ ಮಾಡುತ್ತದೆ.

ಪ್ರಯತ್ನ ವಿಫಲವಾದಾಗ, ಒಂದೇ ಸಂಪರ್ಕವನ್ನು ಎರಡೂ ಲಾಗ್ಗಳಲ್ಲಿ ಅನುಸರಿಸಿ: ರ್ಯಾಪರ್ನ ಸ್ವೀಕೃತ ಮತ್ತು ಸಂಪರ್ಕಿತ ಸಾಲುಗಳು, ನಂತರ VPN ಡೀಮನ್ನ ಸ್ವಂತ ಸೆಷನ್ ಲಾಗ್. ಏನನ್ನೂ ದಾಖಲಿಸದ ಮೊದಲ ಗಡಿಯೇ ಮುಂದಿನ ಬದಲಾವಣೆಯ ಸ್ಥಳ. OpenVPN ಜೋಡಿ ಆಯ್ಕೆಗಳನ್ನು ಹೋಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಆ ಸಂದೇಶಗಳನ್ನು ಆ ಅನುಷ್ಠಾನದ ನಿಯಮಗಳಿಂದ ನಿರ್ಣಯಿಸಿ. link-mtu ಅಸಂಗತಿಯ ಎಚ್ಚರಿಕೆ ತಾನಾಗಿ ಮಾರಕವಲ್ಲ, link-mtu ಅನ್ನು 1500 ಕ್ಕೆ ಪಿನ್ ಮಾಡುವುದು ವಿಭಜನೆ ನಿಂತಿದೆ ಎಂದು ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಸೈಫರ್ ಮಾತುಕತೆ ರೌಟರ್ನ ಫಾರ್ವರ್ಡ್ನದಲ್ಲ, ಒಳಗಿನ OpenVPN ಕಾನ್ಫಿಗರೇಶನ್ನದು.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

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

ಎರಡು ಗುರುತು, ಎರಡು ವೈಫಲ್ಯ ಕ್ರಮ

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

stunnel ಕೈಪಿಡಿ accept, connect ಮತ್ತು ಕ್ಲೈಂಟ್ ಮೋಡ್ ಅನ್ನು ನಿಖರವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಮತ್ತು ಆ ವಿಭಾಗಗಳು ಊಹೆಗಿಂತ ವೇಗವಾಗಿ ಸಾಕೆಟ್ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತವೆ. ಯಾವ ಪದರ ಉತ್ತರಿಸಿತು ಎಂದು ಇನ್ನೂ ಹೇಳಲಾಗದಿದ್ದರೆ, ಕೆಳಗಿನ ಆಜ್ಞೆಯಿಂದ ಸಾರ್ವಜನಿಕ ಪೋರ್ಟ್ ಒದಗಿಸುವ ಪ್ರಮಾಣಪತ್ರ ಓದಿ. ಔಟ್ಪುಟ್ನಲ್ಲಿ ರ್ಯಾಪರ್ ಪ್ರಮಾಣಪತ್ರ ಇದ್ದರೆ ಫಾರ್ವರ್ಡ್ ರ್ಯಾಪರ್ ತಲುಪಿತು, ಮೌನ ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್ ದೋಷ ಎಂದರೆ ತಲುಪಲಿಲ್ಲ. ಆ ಒಂದೇ ವ್ಯತ್ಯಾಸ ಇಲ್ಲಿನ ಯಾವುದೇ ಪರಿಶೀಲನೆಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ಉಳಿಸುತ್ತದೆ.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

ಸಂಬಂಧಿತ ಲೇಖನಗಳು