ರೂಟ್ ಮಾಡಿದ OpenVPN ಸುರಂಗದ ಮೇಲೆ ಹೆಸರಿನ ಹುಡುಕಾಟಗಳು ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ

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

ಪುರಾಣ: ಹೆಸರುಗಳು ವಿಫಲವಾಗುವುದರಿಂದ ಸುರಂಗ ಮುರಿದಿದೆ

ಲಕ್ಷಣವು ನಂಬಲರ್ಹವಾಗಿದೆ ಏಕೆಂದರೆ ಹೆಸರಿನ ಪದರದ ಮೇಲಿನ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ವಿಳಾಸಗಳು ರೂಟ್ ಆಗುತ್ತವೆ, ಇಂಟರ್‌ಫೇಸ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಮತ್ತು ಸಹಚರ ping ಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ವಿಫಲವಾದದ್ದು ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಕೊಂಡಿಯ ಮೇಲೆ ಎಂದೂ ಮಾರ್ಗವಿಲ್ಲದ ಅನ್ವೇಷಣಾ ಕಾರ್ಯವಿಧಾನ, ಮತ್ತು ಇದು ಮುರಿದ ಸುರಂಗಕ್ಕಿಂತ ಬೇರೆಯದೇ ಹೇಳಿಕೆ. ಈ ಎರಡು ಹೇಳಿಕೆಗಳನ್ನು ಬೇರ್ಪಡಿಸುವುದೇ ರೋಗನಿರ್ಣಯದ ಬಹುಪಾಲು.

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

ಪರಿಹಾರವನ್ನು ಹೆಸರಿಸುವ ಮೊದಲು ವಿಫಲವಾದ ಕಾರ್ಯವಿಧಾನವನ್ನು ಹೆಸರಿಸಿ. ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಬಳಸುವ ಹುಡುಕಾಟಕ್ಕೆ ಸೆಗ್ಮೆಂಟ್ ಬೇಕು, ಆದರೆ ರಿಸಾಲ್ವರ್ ಬಳಸುವ ಹುಡುಕಾಟಕ್ಕೆ ಕೇಳಲು ವಿಳಾಸ ಬೇಕು.

TUN ಏನನ್ನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಏನನ್ನು ಸಾಗಿಸುವುದಿಲ್ಲ

TUN ಸಾಧನವು IP ಇಂಟರ್‌ಫೇಸ್, ಮತ್ತು ಅದೇ ಅದನ್ನು ರೂಟ್ ಮಾಡಬಹುದಾದಂತೆ ಮಾಡುತ್ತದೆ. OpenVPN ಕ್ಲೈಂಟ್‌ಗೆ ವಿಳಾಸ ಮತ್ತು ಮಾರ್ಗಗಳ ಗುಂಪನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ಅಲ್ಲಿಂದ ಕ್ಲೈಂಟ್ ಸಹಚರನಿಗೆ ಡೇಟಾಗ್ರಾಮ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಆ ಮಾದರಿಯಲ್ಲಿ ಪ್ರತಿ ಹೋಸ್ಟ್ ಪ್ರತಿ ಫ್ರೇಮ್ ಕೇಳುವ ಹಂಚಿಕೆಯ ಕೊಂಡಿಯನ್ನು ಯಾವುದೂ ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ.

ಅನ್ವೇಷಣಾ ಸಂಚಾರವು ಆ ಮಾದರಿಗೆ ಸ್ವಲ್ಪವೂ ಹೊಂದುವುದಿಲ್ಲ. ಹಳೆಯ Windows ಹೆಸರಿನ ಪ್ರಶ್ನೆಗಳು, SSDP ಪ್ರಕಟಣೆಗಳು ಮತ್ತು mDNS ವಿನಂತಿಗಳು ಒಂದೇ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಬದಲಾಗಿ ಸೆಗ್ಮೆಂಟ್‌ನ ಎಲ್ಲರಿಗೂ ಕಳುಹಿಸಲ್ಪಡುತ್ತವೆ. ರೂಟ್ ಮಾಡಿದ ಕೊಂಡಿಗೆ ಕಳುಹಿಸಲು «ಎಲ್ಲರೂ» ಇಲ್ಲ. ಆ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯವಿಧಾನವೂ ಹಂಚಿಕೆಯ ಮಾಧ್ಯಮವನ್ನು ಊಹಿಸುತ್ತದೆ.

ಆದ್ದರಿಂದ ಸುರಂಗವು ಆರೋಗ್ಯಕರವಾಗಿರಬಹುದು, ಆದರೆ ಅನ್ವೇಷಣೆ ಸಂಪೂರ್ಣವಾಗಿ ವಿಫಲವಾಗಬಹುದು. ಯಾರಾದರೂ VPN ಡೌನ್ ಎಂದು ವರದಿ ಮಾಡಿದಾಗ ಈ ವಾಕ್ಯವನ್ನೇ ಹಿಡಿದುಕೊಳ್ಳಬೇಕು.

ಬ್ರಿಡ್ಜಿಂಗ್ ಗಡಿಯನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ

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

ಪರಿಹಾರ ರೂಟಿಂಗ್ ಗಡಿಯನ್ನು ತೆಗೆದುಹಾಕುವುದು, ಸುರಂಗದೊಳಗೆ ಹೆಸರಿನ ಹೊಸ ಸಾಮರ್ಥ್ಯವಲ್ಲ. ಸೆಗ್ಮೆಂಟ್ ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಮಾಡುವ ಎಲ್ಲವೂ ಈಗ ಕೊಂಡಿಯನ್ನೂ ದಾಟುತ್ತದೆ.

ಸಣ್ಣ ಪ್ರಯೋಗಾಲಯಕ್ಕೆ ಇದು ನ್ಯಾಯಯುತ ವಿನಿಮಯ. ಚದುರಿದ ಪಡೆಗೆ ಅಪರೂಪ.

DNS ಮತ್ತು WINS ಪುಶ್ ಮಾಡುವುದೇ ಸಣ್ಣ ಸರಿಪಡಿಸುವಿಕೆ

ಕ್ಲೈಂಟ್‌ಗೆ ಕೇಳಲು ನಿರ್ದಿಷ್ಟ ಸ್ಥಳ ನೀಡಿ. dhcp-option DNS ಮತ್ತು dhcp-option DOMAIN ಆಂತರಿಕ ಹೆಸರುಗಳನ್ನು ವಲಯವನ್ನು ತಿಳಿದಿರುವ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸುತ್ತವೆ, ಮತ್ತು ಇನ್ನೂ NetBIOS ಅನ್ನು ಅವಲಂಬಿಸಿರುವ Windows ಕ್ಲೈಂಟ್ ಅದೇ ರೀತಿಯಲ್ಲಿ WINS ಸರ್ವರ್ ಪಡೆಯಬಹುದು. ಸುರಂಗವು ರೂಟ್ ಆಗಿಯೇ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಸೆಗ್ಮೆಂಟ್ ತನ್ನ ಸ್ಥಳದಲ್ಲೇ ಉಳಿಯುತ್ತದೆ.

ಎರಡು ಷರತ್ತುಗಳು ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಹೆಸರಿಸಿದ ಸರ್ವರ್ ವಲಯಕ್ಕೆ ಉತ್ತರಿಸಬೇಕು, ಮತ್ತು ಪ್ರಶ್ನೆಗೆ ಸುರಂಗದ ಮೂಲಕ ಅನುಮತಿ ಇರಬೇಕು.

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

ಯಾವ ಪದರ ವಿಫಲವಾಯಿತು ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ

ಮೊದಲು ವಿಳಾಸಕ್ಕೆ ping ಮಾಡಿ, ನಂತರ ಹೆಸರನ್ನು ಬಿಡಿಸಿ ಮತ್ತು ಯಾವ ಸರ್ವರ್ ಉತ್ತರಿಸಿತು ಎಂದು ಓದಿ. ವಲಯವನ್ನು ಹೋಸ್ಟ್ ಮಾಡದ ಸರ್ವರ್‌ನ ಋಣಾತ್ಮಕ ಉತ್ತರವು ಯಂತ್ರದಿಂದ ಎಂದೂ ಹೊರಡದ ಪ್ರಶ್ನೆಗಿಂತ ಬೇರೆಯಾಗಿ ಕಾಣುತ್ತದೆ. ಬಿಡಿಸುವ ಆದರೆ ಸಂಪರ್ಕಗಳನ್ನು ನಿರಾಕರಿಸುವ ಹೆಸರು ಸಂಪೂರ್ಣವಾಗಿ ಮೂರನೇ ಸಮಸ್ಯೆ.

ಮಲ್ಟಿಕಾಸ್ಟ್ ಅದೇ ಗೋಡೆಯ ಹಿಂದಿದೆ. 224.0.0.251 ನಂತಹ ಗುಂಪು ಡಿಫಾಲ್ಟ್ ಆಗಿ ರೂಟ್ ಮಾಡಿದ ಸುರಂಗದ ಮೂಲಕ ಹಾದುಹೋಗುವುದಿಲ್ಲ, ಮತ್ತು ಮಲ್ಟಿಕಾಸ್ಟ್ ಅರಿವಿರುವ ಮಾರ್ಗ ಅಥವಾ LAN ನಲ್ಲಿ ಪ್ರತಿಫಲಕ ಇಲ್ಲದೆ ಗುಂಪಿನ ಮಾರ್ಗ ಸಾಕಾಗುವುದಿಲ್ಲ.