OpenVPN DNS ಅನ್ನು ತಳ್ಳಿದ ನಂತರ ಸ್ಥಳೀಯ Samba ಹಂಚಿಕೆ ಕಣ್ಮರೆಯಾಯಿತು

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

ಐದು ಪರಿಶೀಲನೆಗಳು, ಪ್ರತಿ ಹಂತದಲ್ಲಿ ಹೆಚ್ಚು ಸಾಧ್ಯತೆಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಕ್ರಮದಲ್ಲಿ.

ಸಣ್ಣ ಹೆಸರಿಗೆ ಯಾರು ಉತ್ತರಿಸುತ್ತಾರೆ

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

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

Samba ತಪ್ಪು ಉತ್ತರವನ್ನು ಏಕೆ ನಂಬುತ್ತದೆ

Samba name resolve order ನಿಗದಿಪಡಿಸಿದ ಸ್ಥಿರ ಅನುಕ್ರಮದ ಮೂಲಕ ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ವಿತರಣೆಗಳಲ್ಲಿ ಡೀಫಾಲ್ಟ್ host ಅನ್ನು ಒಳಗೊಂಡಿದೆ, ಅಂದರೆ DNS, ಮತ್ತು ಅದು NetBIOS ಪ್ರಸಾರದಂತಹ ಲ್ಯಾನ್-ಮಾತ್ರ ಕಾರ್ಯವಿಧಾನಗಳ ಮೊದಲು ಚಲಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ರಿಜಾಲ್ವರ್ ಅನ್ನು ತಳ್ಳುವ ಸುರಂಗವು ಪ್ರತಿ ಹಂಚಿಕೆ ಹೆಸರಿನ ಮೇಲೆ ಮೊದಲ ನಿರಾಕರಣೆಯ ಹಕ್ಕನ್ನು ಪಡೆಯುತ್ತದೆ, ಕಟ್ಟಡವನ್ನು ಎಂದಿಗೂ ಬಿಡಬಾರದಿದ್ದ ಏಕ-ಲೇಬಲ್ ಹೆಸರುಗಳೂ ಸೇರಿದಂತೆ.

ಸಾಮಾನ್ಯವಾಗಿ ಅಪರಿಚಿತ ಹೆಸರು ನಕಾರಾತ್ಮಕ ಉತ್ತರವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಕಾರ್ಯವಿಧಾನಕ್ಕೆ ಸರದಿ ಸಿಗುತ್ತದೆ. ಕೆಲವು ರಿಜಾಲ್ವರ್ಗಳು, ವಿಶೇಷವಾಗಿ ಗ್ರಾಹಕ ISP ಮತ್ತು ಸಾರ್ವಜನಿಕ ರಿಜಾಲ್ವರ್ಗಳು, ಅಪರಿಚಿತ ಹೆಸರುಗಳಿಗೆ ಬದಲಾಗಿ ಹುಡುಕಾಟ ಪುಟ ಅಥವಾ ಜಾಹೀರಾತು ವಿಳಾಸದಿಂದ ಉತ್ತರಿಸುತ್ತವೆ. ಆ ಉತ್ತರವು ರಿಜಾಲ್ವರ್ ಲೈಬ್ರರಿಗೆ ಯಶಸ್ಸಿನಂತೆ ಕಾಣುತ್ತದೆ, ಆದ್ದರಿಂದ Samba ಹುಡುಕುವುದನ್ನು ನಿಲ್ಲಿಸಿ ನಿಮ್ಮ ನೆಟ್ವರ್ಕ್ಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲದ ವಿಳಾಸಕ್ಕೆ ಡಯಲ್ ಮಾಡುತ್ತದೆ.

ಫಲಿತಾಂಶವು ದೋಷ ಸಂವಾದವಿಲ್ಲದೆ ಕಣ್ಮರೆಯಾಗುವ ಹಂಚಿಕೆ. ಆ ಅನುಕ್ರಮದಲ್ಲಿ ಯಾವುದೂ VPN ರೂಟಿಂಗ್ ವೈಫಲ್ಯವಲ್ಲ, ಆದ್ದರಿಂದ NAS ಗೆ ping ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ ಅದಕ್ಕೆ ಬ್ರೌಸ್ ಮಾಡುವುದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.

ಬೇರೆ ಬೇರೆ ವ್ಯಾಪ್ತಿಯ ಎರಡು ದುರಸ್ತಿಗಳು

ಸಣ್ಣ ದುರಸ್ತಿ ತಳ್ಳಲಾದ ರಿಜಾಲ್ವರ್ ಅನ್ನು ಉಳಿಸಿಕೊಂಡು Samba ಅದರಿಂದ ಏನನ್ನು ಕೇಳಬಹುದು ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಡೀಮನ್ ನಿಜವಾಗಿ ಓದುವ Samba ಸಂರಚನೆಗೆ ಎರಡು ಸಾಲುಗಳನ್ನು ಸೇರಿಸಿ, ನಂತರ ಸೇವೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

ಆ ಪಟ್ಟಿಯಲ್ಲಿ host ಇಲ್ಲದಿದ್ದರೆ ಹಂಚಿಕೆ ಹುಡುಕಾಟದ ಮಾರ್ಗದಿಂದ DNS ಹೊರಗಾಗುತ್ತದೆ, ಮತ್ತು ಏಕ-ಲೇಬಲ್ ಹೆಸರುಗಳು ಸ್ಥಳೀಯ ವಿಭಾಗದಲ್ಲಿ ಉಳಿಯುತ್ತವೆ. ಕಚೇರಿ ಹೆಸರುಗಳು ಇತರ ಪ್ರತಿ ಪ್ರೋಗ್ರಾಂಗೂ ಸಾಮಾನ್ಯವಾಗಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ, ಏಕೆಂದರೆ ಇದು Samba ಅನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸುತ್ತದೆ. ಬೆಲೆ ಎಂದರೆ Samba ಇನ್ನು DNS ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸಲಾರದು, ಆದ್ದರಿಂದ ಸಂಪೂರ್ಣ ಅರ್ಹ ಕಚೇರಿ ಹೆಸರಿನಿಂದ ವಿಳಾಸೀಕರಿಸಿದ ಹಂಚಿಕೆ ಸಮಸ್ಯೆಯಾಗುತ್ತದೆ.

ವಿಶಾಲ ದುರಸ್ತಿ ಕಾರಣವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ: ತನ್ನದಲ್ಲದ ಹೆಸರುಗಳಿಗೆ ಉತ್ತರಿಸುವ ರಿಜಾಲ್ವರ್ ಅನ್ನು ತಳ್ಳುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಅಥವಾ ವಿಭಜಿತ DNS ನೀತಿಯನ್ನು ತಳ್ಳಿ ಇದರಿಂದ ಕಚೇರಿ ಪ್ರತ್ಯಯಗಳು ಮಾತ್ರ ಕಚೇರಿ ರಿಜಾಲ್ವರ್ ತಲುಪುತ್ತವೆ. ನಿರ್ವಹಿತ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಇದು ಉತ್ತಮ ದೀರ್ಘಕಾಲೀನ ಉತ್ತರ ಏಕೆಂದರೆ ಇದು ಬ್ರೌಸರ್ ಮತ್ತು ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಅನ್ನೂ ರಕ್ಷಿಸುತ್ತದೆ, ಆದರೆ ಸರ್ವರ್ ಭಾಗದಲ್ಲಿ ಆಡಳಿತಾತ್ಮಕ ಪ್ರವೇಶ ಮತ್ತು ತಳ್ಳಲಾದ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಪಾಲಿಸುವ ಕ್ಲೈಂಟ್ ಅಗತ್ಯ.

ಒಂದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆರಿಸಿ. ರಿಜಾಲ್ವರ್ ಬದಲಾವಣೆ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ ಒಂದೇ ಬಾರಿಗೆ ಹೆಸರು ಪರಿಹಾರವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಅದು ಬದಲಾವಣೆ ದಾಖಲೆ, ಬೆಂಬಲ ಕರೆಗಾಗಿ ಸಂಪಾದನೆ ಅಲ್ಲ.

ಪ್ರತ್ಯಯವು ಎಲ್ಲವನ್ನೂ ವಿವರಿಸಬಹುದು

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

ಇಲ್ಲಿ ಪರಿಹಾರವೆಂದರೆ ಸಂಪೂರ್ಣ ಅರ್ಹ ಸ್ಥಳೀಯ ಹೆಸರನ್ನು ಬಳಸುವುದು ಅಥವಾ ಸ್ಥಳೀಯ ಪ್ರತ್ಯಯವನ್ನು ಹೊಂದಿರುವ ವಿಭಜಿತ DNS ನಿಯಮವನ್ನು ಸೇರಿಸುವುದು. ಎರಡೂ Samba ಅನ್ನು ಮುಟ್ಟುವ ಅಗತ್ಯವಿಲ್ಲ.

ಮತ್ತೆ ಸಂಪರ್ಕದ ನಂತರ ಅದನ್ನು ಸಾಬೀತುಪಡಿಸಿ

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

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

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