Synology ನಲ್ಲಿ OpenVPN ಹ್ಯಾಂಡ್‌ಶೇಕ್ ವಿಫಲವೇ? LAN ಫಾರ್ವರ್ಡ್ ಪರಿಶೀಲಿಸಿ

ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ವಿಫಲವಾಗಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಹಾಗಾಗಿ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸುವ ಪ್ರಲೋಭನೆ ಬರುತ್ತದೆ. ಅದಕ್ಕೂ ಮೊದಲು ಹೆಚ್ಚು ನೀರಸ ಪ್ರಶ್ನೆ ಕೇಳಿ: Synology ನಿಜವಾಗಿ ಯಾವ Ethernet ಪೋರ್ಟ್‌ನಲ್ಲಿ ಕೇಳುತ್ತಿದೆ? ಎರಡು LAN ಪೋರ್ಟ್‌ಗಳ NAS ಗೆ ಎರಡು ವಿಳಾಸಗಳಿರುತ್ತವೆ, ಮತ್ತು DSM ನ VPN Server ಪ್ಯಾಕೇಜ್ ತನ್ನ OpenVPN ಶ್ರೋತೃವನ್ನು ಅವುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಬಂಧಿಸುತ್ತದೆ. ರೌಟರ್ 1194 ಅನ್ನು ಇನ್ನೊಂದು ವಿಳಾಸಕ್ಕೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದಾಗ, ಯಾವ ಪ್ಯಾಕೆಟ್ ಕೂಡ ಸೇವೆಗೆ ತಲುಪುವುದಿಲ್ಲ, ಮತ್ತು ಕ್ಲೈಂಟ್‌ನ ಬಳಿ ಮಾತುಕತೆ ನಡೆಸಲು ಏನೂ ಇರುವುದಿಲ್ಲ.

ದೋಷದ ಪಠ್ಯ ದಾರಿ ತಪ್ಪಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅದು ಕ್ಲೈಂಟ್ ಕೊನೆಯದಾಗಿ ಪ್ರಯತ್ನಿಸಿದ್ದನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮೊದಲು ಏನು ತಪ್ಪಾಯಿತು ಎಂಬುದನ್ನಲ್ಲ. ಪ್ಯಾಕೇಜ್ ಪುಟವನ್ನು ರೌಟರ್ ನಿಯಮದೊಂದಿಗೆ ಹೋಲಿಸಲು ಎರಡು ನಿಮಿಷ ಸಾಕು.

ಶ್ರೋತೃ ಬಂಧಿಸಲ್ಪಟ್ಟ ವಿಳಾಸವನ್ನು ಹುಡುಕಿ

DSM ತನ್ನ ಪೋರ್ಟ್‌ಗಳನ್ನು LAN 1 ಮತ್ತು LAN 2 ಎಂದು ಕರೆಯುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಪ್ರತ್ಯೇಕ ವಿಳಾಸ ಮತ್ತು ಉಪಜಾಲವಿದೆ. VPN Server ತೆರೆಯಿರಿ, OpenVPN ಟ್ಯಾಬ್‌ನಲ್ಲಿ ಹೆಸರಿಸಿದ ಇಂಟರ್ಫೇಸ್ ಓದಿ, ನಂತರ Control Panel ತೆರೆದು DSM ಅದೇ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಹೊಂದಿರುವ IPv4 ವಿಳಾಸವನ್ನು ಬರೆದಿಡಿ. ಫಾರ್ವರ್ಡ್ ಹೆಸರಿಸಬೇಕಾದದ್ದು ಈ ಎರಡು ಮೌಲ್ಯಗಳನ್ನು, NAS ನ ಹೋಸ್ಟ್‌ಹೆಸರನ್ನಲ್ಲ.

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

SSH ಮೂಲಕ ಸಾಕೆಟ್ ಅನ್ನೇ ನೋಡಿ, ಏಕೆಂದರೆ ಡೀಮನ್ ನಿಜವಾಗಿ ಯಾವುದಕ್ಕೆ ಬಂಧಿಸಲ್ಪಟ್ಟಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುವ ಏಕೈಕ ಸ್ಥಳ ಅದೇ, ಸೆಟ್ಟಿಂಗ್ಸ್ ಪುಟದ ಉದ್ದೇಶವಲ್ಲ.

sudo netstat -anp | grep 1194

ಹೊಸದನ್ನು ಸೇರಿಸುವ ಬದಲು ಇರುವ ಫಾರ್ವರ್ಡ್ ಸಂಪಾದಿಸಿ

ಒಂದು ಬಾಹ್ಯ ಪೋರ್ಟ್‌ಗೆ ಎರಡು ನಿಯಮಗಳಿದ್ದರೆ ರೌಟರ್ ಆಯ್ಕೆ ಮಾಡಲು ಸ್ವತಂತ್ರವಾಗಿರುತ್ತದೆ, ಮತ್ತು ಯಾವುದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂಬುದು ಫರ್ಮ್‌ವೇರ್ ನವೀಕರಣ ಅಥವಾ ರೀಬೂಟ್ ನಂತರ ಬದಲಾಗಬಹುದು. ಈಗಾಗಲೇ ಇರುವ ನಿಯಮ ತೆರೆಯಿರಿ, ಅದರ ಆಂತರಿಕ ವಿಳಾಸ ಬದಲಿಸಿ, ಉಳಿಸಿ, ನಂತರ ಅದನ್ನು ಮತ್ತೆ ತೆರೆದು ಮೌಲ್ಯ ಓದಿ. ನಿಯಮಕ್ಕೆ ಸೇವೆಯ ಹೆಸರಿಡುವುದು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಐದು ಒಂದೇ ರೀತಿಯ ಫಾರ್ವರ್ಡ್‌ಗಳ ಪಟ್ಟಿಯೇ ತಪ್ಪಾದದ್ದು ಬದುಕುಳಿಯುವ ದಾರಿ.

external 1194/udp  ->  192.0.2.20:1194/udp

ಆಂತರಿಕ ಪೋರ್ಟ್ ಅನ್ನು ಕೇಳುವ ಪೋರ್ಟ್‌ಗೆ ಸಮವಾಗಿಡಿ, ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಸುಸಂಗತವಾಗಿಡಿ. UDP 1194 ಡೀಫಾಲ್ಟ್ ಶ್ರೋತೃ, ಆದರೆ TCP ಪ್ರೊಫೈಲ್‌ಗೆ ಪ್ಯಾಕೇಜ್ ಬದಿಯಲ್ಲಿ ತನ್ನದೇ ಶ್ರೋತೃ ಮತ್ತು ರೌಟರ್‌ನಲ್ಲಿ ಹೊಂದುವ ಫಾರ್ವರ್ಡ್ ಬೇಕು. UDP ಮಾತ್ರ ಕೇಳುವ ಸೇವೆಗೆ TCP ಫಾರ್ವರ್ಡ್ ಮಾಡಿದರೆ ದೋಷವಲ್ಲ, ಮೌನ ಸಿಗುತ್ತದೆ.

NAS ನ ವಿಳಾಸ DHCP ನಿಂದ ಬಂದರೆ, ನಿಯಮ ಉಳಿಸುವ ಮೊದಲು ಅದನ್ನು ಕಾಯ್ದಿರಿಸಿ. ಲೀಜ್ ಅವಧಿ ಮುಗಿದಾಗ ವಿಳಾಸ ಮತ್ತೆ ಹಂಚಿಕೆಯಾಗುತ್ತದೆ, ಫಾರ್ವರ್ಡ್ ಹಳೆಯ ಮೌಲ್ಯಕ್ಕೇ ತೋರಿಸುತ್ತಿರುತ್ತದೆ, ಮತ್ತು ಯಾರೂ NAS ಮುಟ್ಟದ ದಿನದಂದು ಹ್ಯಾಂಡ್‌ಶೇಕ್ ವಿಫಲವಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. NAS ಬದಿಯ ಸ್ಥಿರ ಸಂರಚನೆ ಅದೇ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರ, ವಿಳಾಸ ರೌಟರ್‌ನ DHCP ಶ್ರೇಣಿಯ ಹೊರಗಿದ್ದರೆ.

ಪ್ಯಾಕೆಟ್‌ಗಳು ಸ್ವಲ್ಪವಾದರೂ ತಲುಪುತ್ತವೆಯೇ ಎಂದು ಸಾಬೀತು ಮಾಡಿ

ಮೊದಲು NAS ನಲ್ಲಿ ಕ್ಯಾಪ್ಚರ್ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಕ್ಲೈಂಟ್‌ನಿಂದ ಸಂಪರ್ಕಿಸಿ, ಮತ್ತು ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಮೂಲ ವಿಳಾಸ ಓದಿ. ವೈಫಲ್ಯದ ನಂತರ ಪ್ರಾರಂಭಿಸಿದ ಕ್ಯಾಪ್ಚರ್ ಏನನ್ನೂ ತೋರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಏನನ್ನೂ ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ.

sudo tcpdump -i any -n udp port 1194

ಮೌನ ಎಂದರೆ ಸಂಚಾರ ಸೇವೆಗೆ ತಲುಪುವ ಮೊದಲೇ ಸತ್ತಿದೆ: ತಪ್ಪು ಆಂತರಿಕ ವಿಳಾಸ, DSM ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿ ಮುಚ್ಚಿದ ಪೋರ್ಟ್, ಅಥವಾ ಆಡಳಿತಾತ್ಮಕವಾಗಿ ನಿಷ್ಕ್ರಿಯ ಇಂಟರ್ಫೇಸ್. ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳಿದ್ದರೆ ಫಾರ್ವರ್ಡ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಉಳಿದ ದೋಷ ಜಾಲ ಪದರದ ಮೇಲಿದೆ, ಅದು ಬಹಳ ಚಿಕ್ಕ ಹುಡುಕಾಟ ಕ್ಷೇತ್ರ.

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

ಪ್ಯಾಕೆಟ್‌ಗಳು ಬಂದಾಗ, ಫಾರ್ವರ್ಡ್‌ಗೆ ದೋಷ ಹೇರುವುದನ್ನು ನಿಲ್ಲಿಸಿ

ಪ್ರೊಫೈಲ್ ಮುಂದಿನ ಸಂಶಯಾಸ್ಪದ, ಮತ್ತು ಸಾಮಾನ್ಯ ಕಾರಣ ಹಳೆಯದಾಗಿರುವುದು. ರಫ್ತಾದ .ovpn ಫೈಲ್ ರಫ್ತಿನ ಕ್ಷಣದ ಅಧಿಕಾರ ಮತ್ತು ಸಾಮಗ್ರಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಹಾಗಾಗಿ ಪ್ರಮಾಣಪತ್ರ ನಂತರ ಬದಲಾದ ಪ್ಯಾಕೇಜ್ ಹಳೆಯ ಪ್ರತಿಯನ್ನು ಹೊತ್ತಿರುವ ಕ್ಲೈಂಟ್ ಅನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ.

ಸಾಗಣೆ ಸ್ಪಷ್ಟವಾಗಿ ಪರಿಶೀಲಿಸಬೇಕಾದ ಇನ್ನೊಂದು ಅಸಂಗತಿ, ಏಕೆಂದರೆ ಪ್ರೊಫೈಲ್ ಮತ್ತು ಪ್ಯಾಕೇಜ್ ಬೇರೆ ಬೇರೆ ಕಡೆ ಸಂಪಾದನೆಯಾಗುತ್ತವೆ. ಪ್ಯಾಕೇಜ್ ಬದಲಿಸದೆ ಪ್ರೊಫೈಲ್ ಅನ್ನು UDP ನಿಂದ TCP ಗೆ ಬದಲಿಸಿದರೆ ಕ್ಲೈಂಟ್ ಇಲ್ಲದ ಶ್ರೋತೃವಿಗಾಗಿ ಕಾಯುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಉಳಿದ ಎಲ್ಲದಕ್ಕೂ ಹೇಳುವ ಅದೇ ಸಾಮಾನ್ಯ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪಠ್ಯವನ್ನು ಹೇಳುತ್ತದೆ. ಫೈಲ್‌ನಲ್ಲಿ proto ಸಾಲು ಓದಿ, ನಂತರ ಸರ್ವರ್ ಪುಟದಲ್ಲಿ ಆಯ್ಕೆಯಾದ ಪ್ರೋಟೋಕಾಲ್ ನೋಡಿ, ಆಮೇಲಷ್ಟೇ ಅವು ಹೊಂದುತ್ತವೆ ಎಂದು ತೀರ್ಮಾನಿಸಿ. DSM ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳನ್ನು ಓದುವುದು ಮೂರನೇ ಪರಿಶೀಲನೆ: ಸ್ಥಳೀಯ ಉಪಜಾಲದಿಂದ ಪೋರ್ಟ್ ತೆರೆದು ಇಂಟರ್ನೆಟ್‌ನಿಂದ ತೆರೆಯದ ನಿಯಮವನ್ನು ಪರೀಕ್ಷೆಯ ನಂತರ ಬಿಟ್ಟುಬಿಡುವುದು ಸುಲಭ, ಮತ್ತು ಅದು ಅಡುಗೆಮನೆಯಿಂದ ಕೆಲಸ ಮಾಡಿ ಉಳಿದ ಎಲ್ಲೆಡೆಯಿಂದ ವಿಫಲವಾಗುವ ಸಂಪರ್ಕವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ದೂರದ ಬಳಕೆದಾರ ನಿಜವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುವ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಿ

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

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