OpenVPN ಪ್ರೊಫೈಲ್ ಮನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ ಹೋಟೆಲ್ನಲ್ಲಿ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ

ಕಚೇರಿಯ Wi-Fi ಮತ್ತು ಹೋಟೆಲ್ ಕೊಠಡಿ ಒಂದೇ ಲ್ಯಾಪ್ಟಾಪ್ಗೆ ಎರಡು ಸಂಪೂರ್ಣ ಭಿನ್ನ ನೆಟ್ವರ್ಕ್ಗಳನ್ನು ನೀಡಬಹುದು, ಮತ್ತು ನಡುವಿನ ಪ್ರೊಫೈಲ್ಗೆ ಅದರ ಬಗ್ಗೆ ಏನೂ ಗೊತ್ತಿಲ್ಲ. ಮನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದು ಸಡಿಲವಾದ ಅಪ್ಲಿಂಕ್, ಕೆಲಸ ಮಾಡುವ ಹೆಸರು ವಿಭೇದನ ಮತ್ತು ಟನಲ್ ಸಾಗಿಸುವ ಯಾವುದೇ ವಸ್ತುವಿನೊಂದಿಗೆ ಘರ್ಷಿಸದ ಸ್ಥಳೀಯ ಸಬ್ನೆಟ್ ಅನ್ನು ಊಹಿಸುತ್ತದೆ. ಈ ಪ್ರತಿಯೊಂದು ಊಹೆಯೂ ಪ್ರತ್ಯೇಕವಾಗಿ ವಿಫಲವಾಗಬಹುದು.

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

ನಾಲ್ಕು ನೆಟ್ವರ್ಕ್ ಸತ್ಯಗಳು ಸ್ಥಳಗಳ ನಡುವೆ ಬದಲಾಗುತ್ತವೆ

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

ಎರಡನೆಯದು ಹೆಸರು ವಿಭೇದನ. DNS ಅನ್ನು ಪ್ರತಿಬಂಧಿಸುವ ಪೋರ್ಟಲ್ ಪ್ರತಿ ಪ್ರಶ್ನೆಗೂ ತನ್ನದೇ ವಿಳಾಸದಿಂದ ಉತ್ತರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ VPN ಹೋಸ್ಟ್ಹೆಸರು ಪೋರ್ಟಲ್ಗೆ ವಿಭೇದನವಾಗಿ ಕ್ಲೈಂಟ್ ವೆಬ್ ಪುಟಕ್ಕೆ ಟನಲ್ ಕಟ್ಟಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.

ಮೂರನೆಯದು ಸಾರಿಗೆ ಫಿಲ್ಟರಿಂಗ್. ಬ್ರೌಸಿಂಗ್ಗೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡಲು ಬಯಸುವ ನೆಟ್ವರ್ಕ್ಗಳು TCP 443 ಅನ್ನು ಯಾವುದೇ ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಹಾದುಹೋಗಲು ಬಿಟ್ಟು UDP ಸೇರಿದಂತೆ ಬಹುತೇಕ ಎಲ್ಲವನ್ನೂ ಬಿಟ್ಟುಬಿಡುತ್ತವೆ.

ನಾಲ್ಕನೆಯದು ವಿಳಾಸೀಕರಣ. ಸ್ಥಳೀಯ ಸಬ್ನೆಟ್ ಟನಲ್ನ ಹಿಂದಿನ ನೆಟ್ವರ್ಕ್ನೊಂದಿಗೆ ಓವರ್ಲ್ಯಾಪ್ ಆಗಬಹುದು, ಅಥವಾ ಅಪ್ಲಿಂಕ್ ಯಾವುದೇ ಉಪಯುಕ್ತ IPv4 ಮಾರ್ಗವನ್ನೇ ನೀಡದಿರಬಹುದು.

ಹೆಸರು ವಿಭೇದನ ಮತ್ತು ಕ್ಯಾಪ್ಟಿವ್ ಪೋರ್ಟಲ್

ಪ್ರೊಫೈಲ್ನಲ್ಲಿನ ಹೋಸ್ಟ್ಹೆಸರನ್ನು ಸರ್ವರ್ನ ಸಂಖ್ಯಾ ವಿಳಾಸದಿಂದ ಬದಲಿಸಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ. IP ಸಂಪರ್ಕಗೊಂಡು ಹೆಸರು ಸಂಪರ್ಕಗೊಳ್ಳದಿದ್ದರೆ, ತಪ್ಪು ಹೆಸರು ವಿಭೇದನದ್ದು, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಸ್ವತಃ ಸರಿಯಾಗಿದೆ.

VPN ಮುಟ್ಟುವ ಮೊದಲು ಬ್ರೌಸರ್ ತೆರೆದು ಸಾಮಾನ್ಯ HTTP ಪುಟವನ್ನು ಪ್ರಯತ್ನಿಸಿ. ಲಾಗಿನ್ ಪುಟಕ್ಕೆ ಮರುನಿರ್ದೇಶನ ಎಂದರೆ ಪೋರ್ಟಲ್ ಇನ್ನೂ ಬಾಕಿಯಿದೆ; ಅದನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ, ನಂತರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ. ಅನೇಕ ಹೋಟೆಲ್ಗಳು ಕೆಲವು ಗಂಟೆಗಳ ನಂತರ ಅಧಿವೇಶನವನ್ನೂ ಮುಗಿಸುತ್ತವೆ, ಇದು ಲಾಗಿನ್ ಸಮಸ್ಯೆಯ ಬದಲು ಮಧ್ಯಾಹ್ನದ ಕಡಿತದಂತೆ ಕಾಣುತ್ತದೆ.

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

ಸಾರಿಗೆ ಫಿಲ್ಟರಿಂಗ್: ಮೊದಲು UDP, ಬ್ಯಾಕಪ್ ಆಗಿ TCP 443

UDP 1194 ಮೇಲಿನ OpenVPN ಹರಿವು ಹೋಟೆಲ್ ಫೈರ್ವಾಲ್ ಗುರುತಿಸುವ ಯಾವುದಕ್ಕೂ ಹೋಲುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ದೋಷವಿಲ್ಲದೆ ಬಿಸಾಡಲಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್ ತನ್ನ ಕಾಲಮಿತಿ ಮುಗಿಯುವವರೆಗೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಮತ್ತು ಬಳಕೆದಾರ ನಿರಾಕರಣೆಯ ಬದಲು ಎಂದೂ ಸ್ಥಾಪಿತವಾಗದ ಸಂಪರ್ಕವನ್ನು ಕಾಣುತ್ತಾನೆ. ಹೀಗೆ ವರ್ತಿಸುವ ಫೈರ್ವಾಲ್ಗಳು ಬಿಸಾಡುವಿಕೆಯನ್ನು ನೀವು ನೋಡಬಹುದಾದ ಸ್ಥಳದಲ್ಲಿ ಅಪರೂಪವಾಗಿ ದಾಖಲಿಸುತ್ತವೆ. ನಿರಾಕರಣೆಯ ಅನುಪಸ್ಥಿತಿಯೇ ಸುಳಿವು.

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

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

ವಿಳಾಸ ಘರ್ಷಣೆಗಳು ಮತ್ತು IPv4 ಇಲ್ಲದ ಅಪ್ಲಿಂಕ್ಗಳು

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

ಶಾಶ್ವತ ಪರಿಹಾರ ಎಂದರೆ ದೂರದ LAN ಅನ್ನು ಅಪರೂಪದ ಖಾಸಗಿ ಶ್ರೇಣಿಗೆ ಸ್ಥಳಾಂತರಿಸುವುದು. ಮನೆಯಲ್ಲಿ ಯಾರೂ ಬಳಸದ ಶ್ರೇಣಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು, ಉದಾಹರಣೆಗೆ 10.42.0.0/24, ಸಮಸ್ಯೆಯನ್ನು ಒಂದಕ್ಕೆ ಬದಲು ಪ್ರತಿ ಭವಿಷ್ಯದ ಸ್ಥಳಕ್ಕೂ ತಡೆಯುತ್ತದೆ. ಸ್ಥಳೀಯ ತಾತ್ಕಾಲಿಕ ಉಪಾಯ ಎಂದರೆ ಆ ಹೋಟೆಲ್, ಹಾಟ್ಸ್ಪಾಟ್ ಅಥವಾ ರೂಟರ್ ಅನ್ನು ತಪ್ಪಿಸುವುದು, ಅದು ಪರಿಹಾರವೇ ಅಲ್ಲ.

ಮೊಬೈಲ್ ಅಪ್ಲಿಂಕ್ಗಳು ಎರಡು ವೈವಿಧ್ಯಗಳನ್ನು ಸೇರಿಸುತ್ತವೆ. ವಾಹಕ ಮಟ್ಟದ NAT ಎಂದರೆ ಒಳಬರುವ ಸಂಪರ್ಕಗಳು ತಲುಪುವುದಿಲ್ಲ, ಇದು ಸರ್ವರ್ ಹೋಸ್ಟ್ ಮಾಡಿದರೆ ಮುಖ್ಯ ಆದರೆ ಹೊರಹೋಗುವ ಕ್ಲೈಂಟ್ಗೆ ಅಲ್ಲ. NAT64 ಅನುವಾದದೊಂದಿಗೆ IPv6 ಮಾತ್ರ ಎಂದು ಸಂರಚಿಸಿದ APN ನಿಜವಾದ IPv4 ಮಾರ್ಗವನ್ನು ಒತ್ತಾಯಿಸುವ ಕ್ಲೈಂಟ್ ಅನ್ನು ವಿಫಲಗೊಳಿಸಬಹುದು, ಮತ್ತು ಸಾಮಾನ್ಯ ಪರಿಹಾರ APN ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು IPv4 ಅಥವಾ ದ್ವಿ ಸ್ಟ್ಯಾಕ್ಗೆ ಬದಲಿಸುವುದು.

ಟನಲ್ ಮೇಲೆದ್ದ ನಂತರದ ಲಕ್ಷಣಗಳು

ಸಂಪರ್ಕಗೊಂಡು ನಂತರ ಮೌನವಾಗುವ ಟನಲ್ ಸಾಮಾನ್ಯವಾಗಿ keepalive ಅಥವಾ MTU ಸಮಸ್ಯೆ, ತಡೆಹಿಡಿಯಲಾದ ಪೋರ್ಟ್ ಅಲ್ಲ. ನಿಗದಿತ ನಿಮಿಷಗಳ ನಂತರ ಬೀಳುವ ಸಂಪರ್ಕ keepalive ಅಥವಾ ಮರುಸಂಧಾನ ಟೈಮರ್ಗೆ ಸೂಚಿಸುತ್ತದೆ. ಉತ್ತರಗಳು ನಿಂತಾಗ ಕ್ಲೈಂಟ್ ತನ್ನ ಜೊತೆಗಾರನನ್ನು ಪರೀಕ್ಷಿಸಿ ಮರುಪ್ರಾರಂಭಿಸುವಂತೆ ಹೊಂದಿಸಿ, ಮತ್ತು ping ಯಶಸ್ವಿಯಾಗಿ ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳು ನಿಂತರೆ ಚಿಕ್ಕ ಟನಲ್ MTU ಪರೀಕ್ಷಿಸಿ.

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