OpenVPN ಮನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಒಂದು ನೆಟ್ವರ್ಕ್‌ನಲ್ಲಿ ಇಲ್ಲ: UDP ಅಥವಾ TCP?

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

ಯಾವ ಹಂತ ವಿಫಲವಾಯಿತು ಎಂಬುದು ಯಾವ ಹೋಲಿಕೆ ಮುಖ್ಯ ಎಂಬುದನ್ನು ತಿಳಿಸುತ್ತದೆ

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

ನಂತರ ಅಲ್ಲ, ಮರುಪ್ರಯತ್ನಿಸುವಾಗ ಸೆರೆಹಿಡಿಯಿರಿ. ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ tcpdump -ni any udp port 1194 ಯಾವುದೇ ಉತ್ತರವು ಒಟ್ಟಿಗೆ ಬರುತ್ತದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ನೀವು ನಿಯಂತ್ರಿಸುವ ಸರ್ವರ್‌ನ WAN ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಅದನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಇದು ಆ ಪ್ಯಾಕೆಟ್‌ಗಳು ಒಟ್ಟಿಗೆ ದೂರದ ತುದಿಗೆ ತಲುಪುತ್ತವೆಯೇ ಎಂದು ಬಯಲು ಮಾಡುತ್ತದೆ.

ಏಕಪಕ್ಷೀಯ ಸಂಚಾರವು ಇಲ್ಲಿ ಲಭ್ಯವಿರುವ ಅತ್ಯಂತ ಉಪಯುಕ್ತ ಫಲಿತಾಂಶ, ಏಕೆಂದರೆ ಅದು ಮಧ್ಯಂತರ ದೂರನ್ನು ತನಿಖೆಯ ದಿಕ್ಕಾಗಿ ಬದಲಿಸುತ್ತದೆ. ಸೆರೆಹಿಡಿಯುವ ಫೈಲ್‌ಗಳನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಅದೇ ಸಮಸ್ಯೆಯ ಮುಂದಿನ ವರದಿಯನ್ನು ವಿವರಣೆಗಿಂತ ಸಾಕ್ಷ್ಯದಿಂದ ಮುಚ್ಚುವುದು ಸುಲಭ.

UDP ಫಿಲ್ಟರಿಂಗ್ ಮತ್ತು ಮುಚ್ಚಿದ ಪೋರ್ಟ್

ಅನೇಕ ಪ್ರವೇಶ ನೆಟ್ವರ್ಕ್‌ಗಳು ನಿರಂತರ UDP ಅನ್ನು ಸಂಶಯಾಸ್ಪದವೆಂದು ಪರಿಗಣಿಸುತ್ತವೆ, ಮತ್ತು ಕೆಲವು ISPಗಳು ಅವರೊಂದಿಗೆ ಒಪ್ಪುತ್ತವೆ. ಮುಚ್ಚಿದ ಪೋರ್ಟ್ ಕ್ಲೈಂಟ್ ಕಡೆಯಿಂದ ಅದೇ ಮೌನವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ವ್ಯತ್ಯಾಸವೆಂದರೆ ಆಯ್ಕೆಶೀಲತೆ: ಫಿಲ್ಟರ್ ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳು ಅಥವಾ ಪೋರ್ಟ್‌ಗಳನ್ನು ಬಿಡುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಆಯ್ಕೆಮಾಡುತ್ತದೆ, ಆದರೆ ಮುಚ್ಚಿದ ಪೋರ್ಟ್ ಆ ಪೋರ್ಟ್‌ಗೆ ಗುರಿಯಾಗಿರುವ ಎಲ್ಲವನ್ನೂ ನಿರಾಕರಿಸುತ್ತದೆ.

ಪೋರ್ಟ್ 443 ನಲ್ಲಿ TCP ಪ್ರೊಫೈಲ್ ಸಾಮಾನ್ಯ ಪರಿಹಾರ, ಏಕೆಂದರೆ ಅದು ಸಾಮಾನ್ಯ HTTPS ಹರಿವಿನಂತೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಕ್ಯಾಪ್ಟಿವ್ ಪೋರ್ಟಲ್‌ಗಳು ಮತ್ತು ನಿರ್ಗಮನ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ದಾಟುತ್ತದೆ. ಎರಡು ಷರತ್ತುಗಳು ಪಾಲಿಸಬೇಕು. ಸರ್ವರ್ proto tcp-server ನೊಂದಿಗೆ ಕೇಳಬೇಕು ಮತ್ತು ಕ್ಲೈಂಟ್ proto tcp-client ಗೆ ಹೊಂದಬೇಕು, ಮತ್ತು ನಿರ್ವಾಹಕರು ಆ ಪರ್ಯಾಯ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಪ್ರಕಟಿಸಬೇಕು. ಕಾರ್ಯನಿರ್ವಹಿಸುವ UDP ಪ್ರೊಫೈಲ್ ಅನ್ನು TCP 443 ಎಂದು ಹೇಳಲು ಮರುಬರೆಯುವುದು ಆಚೆ ಯಾರೂ ಕೇಳದಿದ್ದರೆ ಏನೂ ಸಾಧಿಸುವುದಿಲ್ಲ.

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

ಹಳೆಯ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಈ ಅಕ್ಷದಲ್ಲಿ ಕೆಟ್ಟದಾಗಿ ಹೋಲುತ್ತವೆ. PPTP ಗೆ TCP 1723 ಜೊತೆಗೆ GRE ಬೇಕು, ಮತ್ತು GRE ಪೋರ್ಟ್ ಅಲ್ಲ, IP ಪ್ರೋಟೋಕಾಲ್ 47, ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡ್ ಅದನ್ನು ವ್ಯಕ್ತಪಡಿಸುವುದಿಲ್ಲ.

ಸ್ವಿಚ್ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಬಿಡುತ್ತಿರುವಾಗ

ನಿರ್ವಹಿತ ಸ್ವಿಚ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಟನೆಲ್ ಅನ್ನು ಬಿಡಬಹುದು. ಕೆಲವು HPE ಮತ್ತು Aruba ಮಾದರಿಗಳು ಸುಧಾರಿತ ಭದ್ರತಾ ವಿಭಾಗದಲ್ಲಿ UDP ಫ್ಲಡ್ ರಕ್ಷಣಾ ನಿಯಂತ್ರಣವನ್ನು ಒದಗಿಸುತ್ತವೆ, ಕೆಲವೊಮ್ಮೆ Prevent UDP Blat Attack ಎಂದು ಲೇಬಲ್ ಮಾಡಲಾಗುತ್ತದೆ. ಆ ನಿಯಂತ್ರಣ ಸಕ್ರಿಯವಾದಾಗ, ಸ್ವಿಚ್ ಹಿಂದೆ ಇರುವ ಸರ್ವರ್ ಯಾವುದಕ್ಕೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಅದೇ ರೀತಿಯಲ್ಲಿ ಸಮಯ ಮೀರುತ್ತದೆ. ಅದನ್ನು ತೆರವುಗೊಳಿಸಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಸಂರಚನೆಯನ್ನು ಉಳಿಸುವುದೇ ಪೂರ್ಣ ದುರಸ್ತಿ, ಆದರೆ ಸ್ವಿಚ್ ನಿಜವಾಗಿಯೂ ಮಾರ್ಗದಲ್ಲಿದೆ ಎಂದು ಸ್ಥಾಪಿಸಿದ ನಂತರವೇ.

ಸ್ವಿಚ್ ಬಿಡುವಿಕೆಯನ್ನು ಪೂರೈಕೆದಾರರ ಬ್ಲಾಕ್‌ನಿಂದ ಬೇರ್ಪಡಿಸುವುದು ಪ್ರತಿಸಾಕ್ಷ್ಯ. ISP ಯೊಂದಿಗೆ ಟಿಕೆಟ್ ತೆರೆಯುವ ಮೊದಲು ಇಂಟರ್ಫೇಸ್ ಕೌಂಟರ್‌ಗಳು ಮತ್ತು ಫ್ಲಡ್ ರಕ್ಷಣಾ ಲಾಗ್ ಓದಿ. DoS ಅಥವಾ ಫ್ಲಡ್ ರಕ್ಷಣೆ ಇರುವ ಗ್ರಾಹಕ ರೌಟರ್‌ಗಳು ಅದೇ ಆಕಾರದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಸಣ್ಣ UDP ಐಡಲ್ ಸಮಯ ಮಿತಿ ಇರುವ ಯಾವುದೇ ಮಧ್ಯವರ್ತಿ ಸಾಧನವೂ ಹಾಗೆಯೇ. ಎಂದಿಗೂ ಪೂರ್ಣಗೊಳ್ಳದ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಬಿಡುವಿಕೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಆದರೆ ಕೆಲವು ನಿಮಿಷಗಳ ಮೌನದ ನಂತರ ಸಾಯುವ ಟನೆಲ್ ಸಮಯ ಮಿತಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ.

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

DNS ವೈಫಲ್ಯದಂತೆ ಕಾಣುವ ವಿಳಾಸ ಅತಿಕ್ರಮಣ

10.0.0.0/8 ಒಳಗೆ ಸಂಖ್ಯೆ ಮಾಡಿದ ಪ್ರವೇಶ ನೆಟ್ವರ್ಕ್ ಟನೆಲ್ ಪೂಲ್‌ನೊಂದಿಗೆ ಅತಿಕ್ರಮಿಸಬಹುದು, ಮತ್ತು ರೆಸಾಲ್ವರ್ ಸಾಮಾನ್ಯವಾಗಿ ಆ ಪೂಲ್ ಒಳಗೆ ಇರುತ್ತದೆ. ಲ್ಯಾಪ್‌ಟಾಪ್ Wi-Fi ನಲ್ಲಿ 10.184.178.50 ನಂತಹ ವಿಳಾಸವನ್ನು /8 ಮಾಸ್ಕ್‌ನೊಂದಿಗೆ ಪಡೆದಾಗ, ಪ್ರತಿ 10.x ಗಮ್ಯಸ್ಥಾನವೂ ವ್ಯಾಖ್ಯಾನದಿಂದ ಸ್ಥಳೀಯವಾಗಿರುತ್ತದೆ. 10.4.0.1 ಗೆ ಪ್ಯಾಕೆಟ್‌ಗಳು ನಂತರ LAN ಗೆ ಹೋಗುತ್ತವೆ, ಟನೆಲ್ ಮೇಲಿರುತ್ತದೆ, ಮತ್ತು ಹೆಸರು ಪರಿಹಾರ ವಿಫಲವಾಗುತ್ತದೆ.

ip addr ಅತಿಕ್ರಮಣವನ್ನು ಒಂದು ನೋಟದಲ್ಲಿ ಬಯಲು ಮಾಡುತ್ತದೆ, ಮತ್ತು ip route get 10.4.0.1 ಪ್ಯಾಕೆಟ್ ನಿಜವಾಗಿ ಎಲ್ಲಿ ತಲುಪಿಸಲಾಗುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಗೋಚರ ಲಕ್ಷಣ ರೆಸಾಲ್ವರ್ ವೈಫಲ್ಯವಾದ್ದರಿಂದ, ಇದು ಹಲವು ಸುತ್ತಿನ DNS ಬದಲಾವಣೆಗಳ ನಂತರವೂ ಬದುಕುಳಿಯುತ್ತದೆ.

ಪೂಲ್ ಅನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡಿ ಅಥವಾ ಆ ಪ್ರವೇಶ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿಡಿ. ಯಾವುದೇ ಕ್ಲೈಂಟ್-ಸೈಡ್ ಸೆಟ್ಟಿಂಗ್ ಅತಿಕ್ರಮಣದಿಂದ ಚೇತರಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ.

TCP ಬ್ಯಾಕಪ್ ಮತ್ತು ಮಾರ್ಗ ದುರಸ್ತಿಯ ನಡುವೆ ಆಯ್ಕೆ

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

ಫಲಿತಾಂಶವನ್ನು ಬಳಕೆದಾರರಿಗಿಂತ ನೆಟ್ವರ್ಕ್ ಪ್ರಕಾರ ದಾಖಲಿಸಿ. ಅದೇ ವೈಫಲ್ಯದ ಮುಂದಿನ ವರದಿ ನಂತರ ಪ್ರಮಾಣಪತ್ರ ಸಿದ್ಧಾಂತದಿಂದ ಅಲ್ಲ, ತಿಳಿದ ಹಂತದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಆ ದಾಖಲೆಯೇ, ಎಂದಾದರೂ ಅಗತ್ಯವಿದ್ದರೆ, ಶಾಶ್ವತ ಎರಡನೇ listener ಅನ್ನು ಸಮರ್ಥಿಸುತ್ತದೆ.