OpenVPN UDP ಸುರಂಗದೊಳಗೆ TCP ಮೇಲೆ NFS: ಎರಡು ಸಾಗಣೆ

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

ಏನನ್ನಾದರೂ ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ಎರಡನ್ನೂ ಪ್ರತ್ಯೇಕವಾಗಿ ಬರೆಯಿರಿ; ಈ ಘಟನೆಗಳ ಬಹುಪಾಲು ಯಾರೋ ತಪ್ಪು ಪದರವನ್ನು ಬದಲಿಸುವುದರಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ.

ಎರಡು ಪದರ, ಎರಡು ಸೆಟ್ಟಿಂಗ್

ಮೌಂಟ್ ಆಯ್ಕೆ proto=tcp NFS ಕ್ಲೈಂಟ್ NFS ಸರ್ವರ್ ಜೊತೆ ಹೇಗೆ ಮಾತನಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. VPN ಪ್ರೊಫೈಲ್ನ proto udp ಸೆಟ್ಟಿಂಗ್ ಸುರಂಗದ ತುದಿಗಳು ಎನ್ಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಹೇಗೆ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಮೌಂಟ್ ಆಯ್ಕೆಯನ್ನು ಬದಲಿಸುವುದರಿಂದ ಸುರಂಗ ಬದಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಸುರಂಗದ ಸಾಗಣೆಯನ್ನು ಬದಲಿಸುವುದರಿಂದ NFS ಕ್ಲೈಂಟ್ ಒಪ್ಪಂದ ಮಾಡಿಕೊಂಡದ್ದು ಬದಲಾಗುವುದಿಲ್ಲ. fstab ಸಾಲಿನ ಬದಲು nfsstat -m ಮೂಲಕ ಪರಿಣಾಮಕಾರಿ ಮೌಂಟ್ ಆಯ್ಕೆಗಳನ್ನು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ನಿಜವಾಗಿ ಬಳಸುತ್ತಿರುವ ಪ್ರೊಫೈಲ್ನಿಂದ VPN ಸಾಗಣೆಯನ್ನು ಖಚಿತಪಡಿಸಿ.

ನಂತರ ಅವುಗಳನ್ನು ಘಟನೆಯ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಎರಡು ಪ್ರತ್ಯೇಕ ಕ್ಷೇತ್ರಗಳಾಗಿ ದಾಖಲಿಸಿ. ಕಾಣುವ ಸುಧಾರಣೆಯನ್ನು ಯಾವ ಪದರ ಬದಲಾಯಿತು ಎಂದು ಟಿಪ್ಪಣಿ ಹೇಳಿದರೆ ಮಾತ್ರ ಪತ್ತೆಹಚ್ಚಬಹುದು.

ಬ್ರೌಸಿಂಗ್ ಎಂಬುದು ಬೃಹತ್ ಓದಲ್ಲ

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

ವಿಫಲವಾಗುತ್ತಿರುವ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿಖರವಾಗಿ ವಿವರಿಸಿ: ಮಾರ್ಗ, ದಿಕ್ಕು, ನಿಲುಗಡೆಯ ಅಂದಾಜು ಸ್ಥಳ, ಮತ್ತು ಕ್ಲೈಂಟ್, ಸರ್ವರ್ ಹಾಗೂ VPN ಲಾಗ್ಗಳಲ್ಲಿ ಕೊನೆಯ ಸಂಬಂಧಿತ ಘಟನೆ. ನಂತರ ಸಂಚಾರ ಎಲ್ಲಿ ಮುಂದುವರಿಯುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಎಂದು ಹೋಲಿಸಿ.

MTU ಒಂದು ಊಹೆ, ರೋಗನಿರ್ಣಯ ಅಲ್ಲ

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

ಕೇವಲ ಸಮಯ ಮಿತಿ UDP ಬದಲಾಯಿಸಬೇಕೇ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಇದು ಹಲವು ಸಂಭಾವ್ಯ ಮಾಲೀಕರಿರುವ ಲಕ್ಷಣ.

ಒಂದು ಸಮಯಕ್ಕೆ ಒಂದು ಚರ ಬದಲಿಸಿ

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

ಹಿಂದಿನ ಮೌಲ್ಯಗಳನ್ನೂ ಟಿಕೆಟ್ನಲ್ಲಿ ಇರಿಸಿ. ಬದಲಾವಣೆಯು ವಿಷಯಗಳನ್ನು ಹದಗೆಡಿಸಿದರೆ, ಹಿಂಪಡೆಯುವಿಕೆ ದಾಖಲಿತ ಸಂಖ್ಯೆಯಾಗಿರಬೇಕು, ಹಿಂದೆ ಹೇಗಿತ್ತು ಎಂಬ ಯಾರೋ ನೆನಪಲ್ಲ.

ವಿಫಲವಾದ ಪದರವನ್ನು ಓದಿ

ಸುರಂಗ ಚಾಲನೆಯಲ್ಲಿದ್ದು NFS ವಿನಂತಿ ಕಾಯುತ್ತಿದ್ದರೆ VPN ವಿಫಲವಾಗಿಲ್ಲ; ಫೈಲ್ ಸೇವೆ ವಿಫಲವಾಗಿದೆ. ಸುರಂಗ ಬಿದ್ದಿದ್ದರೆ, NFS ವಿನಂತಿಯ ವೈಫಲ್ಯ ಪರಿಣಾಮ, ಕಾರಣ ಅಲ್ಲ. ಎರಡೂ ಪದರಗಳ ಲಾಗ್ ಸಾಲುಗಳನ್ನು ಹೊಂದಿಸುವುದು ಈ ಎರಡು ಸಂದರ್ಭಗಳನ್ನು ಬೇರ್ಪಡಿಸುವ ಅತ್ಯಂತ ವೇಗದ ದಾರಿ, ಮತ್ತು ಅದು ಫೈಲ್ ನಿರ್ವಾಹಕದಿಂದ ಊಹಿಸುವುದಕ್ಕಿಂತ ಉತ್ತಮ.

ತೀರ್ಮಾನವನ್ನು ಎರಡು ವಾಕ್ಯಗಳಲ್ಲಿ ಬರೆಯಿರಿ, ಪ್ರತಿ ಪದರಕ್ಕೆ ಒಂದು. ಯಾವ ಸಾಗಣೆ ಯಾವುದು ಎಂದು ಮತ್ತೆ ತೀರ್ಮಾನಿಸದೆ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಲು ಅಷ್ಟೇ ಸಾಕು.