VPN ಸಂಪರ್ಕಗೊಂಡಿದೆ ಆದರೆ ಒಂದು ಸೇವೆ ವಿಫಲವಾಗಿದೆ: ಹಂತವನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ
ಪೂರ್ಣಗೊಂಡ ಹ್ಯಾಂಡ್ಶೇಕ್ ಹೆಸರು, ಮಾರ್ಗ, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರ ಅಥವಾ ಆಲಿಸುವವರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ನಾಲ್ಕು ಹಂತಗಳನ್ನು ದಾಟಿ ಮತ್ತು ಮೊದಲ ವೈಫಲ್ಯವೇ ದೋಷವನ್ನು ಹೆಸರಿಸಲಿ.
VPN ಟಿಕೆಟ್ನಲ್ಲಿ «ಸಂಪರ್ಕಗೊಂಡಿದೆ» ಎಂಬುದು ಅತ್ಯಂತ ಕಡಿಮೆ ಮಾಹಿತಿ ನೀಡುವ ಸತ್ಯ. ಎರಡು ಕಡೆಗಳು ಹ್ಯಾಂಡ್ಶೇಕ್ ಮುಗಿಸಿದ್ದನ್ನು ಅದು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಕೇಳಿದ ಹೆಸರು, ಪ್ಯಾಕೆಟ್ ಹೊರಟ ಇಂಟರ್ಫೇಸ್, ಅದರ ಗಾತ್ರ, ಅಥವಾ ದೂರದ ತುದಿ ಅದನ್ನು ಸ್ವೀಕರಿಸಿತೇ ಎಂಬ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಒಂದೇ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿನ ಉಳಿದ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೂ ಒಂದು ಸೇವೆ ವಿಫಲವಾಗಬಹುದು. ಹಂತಗಳನ್ನು ಕ್ರಮವಾಗಿ ದಾಟಿ, ಮೊದಲು ವಿಫಲವಾಗುವ ಹಂತವೇ ದೋಷವನ್ನು ಹೆಸರಿಸುತ್ತದೆ.
ಹೆಸರಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಟನೆಲ್ನಿಂದ ಅಲ್ಲ
ಮಾರ್ಗ ಮಾಡುವ ಮೊದಲು ಪರಿಹರಿಸಿ, ಏಕೆಂದರೆ ಕೆಟ್ಟ ಉತ್ತರವು ಮುಂದಿನ ಪ್ರತಿ ಪರೀಕ್ಷೆಯನ್ನೂ ಅರ್ಥಹೀನಗೊಳಿಸುತ್ತದೆ. ಸಿಸ್ಟಂ ರಿಜಾಲ್ವರ್ನಿಂದ ಹೆಸರನ್ನು ಕೇಳಿ ಮತ್ತು ಆ ಉತ್ತರವನ್ನು ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಬಳಸಿದ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ. ಖಾಸಗಿ ಹೆಸರು ಸಾರ್ವಜನಿಕ ವಿಳಾಸವಾಗಿ ಮರಳಿ ಬಂದರೆ, ಪ್ರಶ್ನೆ ಉತ್ತರಿಸುವ ಜವಾಬ್ದಾರಿ ಇಲ್ಲದ ರಿಜಾಲ್ವರ್ಗೆ ಹೋಗಿದೆ ಎಂದರ್ಥ. ಪರಿಹಾರವಾಗದ ಹೆಸರು ಅದೇ ವರ್ಗ, ಬರೀ ಹೆಚ್ಚು ಗಟ್ಟಿಯಾಗಿ.
resolvectl query host.internal
getent hosts host.internal
ತಮ್ಮದೇ ಸುರಕ್ಷಿತ-DNS ಸೆಟ್ಟಿಂಗ್ ಇರುವ ಬ್ರೌಸರ್ಗಳು ಇಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ, ಉಳಿದ ಸಿಸ್ಟಂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆದ್ದರಿಂದ ಬ್ರೌಸರ್ಗೆ ಮಾತ್ರ ಸಂಬಂಧಿಸಿದ ದೂರು ಮೊದಲು ಈ ಹಂತಕ್ಕೆ ಸೇರುತ್ತದೆ, ಯಾರಾದರೂ ಮಾರ್ಗವನ್ನು ಮುಟ್ಟುವ ಮೊದಲು. ಒಂದಲ್ಲ, ಎರಡೂ ಆದೇಶಗಳನ್ನು ಹೋಲಿಸಿ, ಏಕೆಂದರೆ getent NSS ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ರಿಜಾಲ್ವರ್ ಪ್ರಶ್ನೆ ಅಲ್ಲ.
ಕರ್ನೆಲ್ ಯಾವ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡಿತು ಎಂದು ಕೇಳಿ
ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವು ಆದ್ಯತೆಯ ಕ್ರಮ, ಮತ್ತು ಕರ್ನೆಲ್ ಆಯ್ಕೆ ಮಾಡುವ ಮಾರ್ಗ ಯಾವಾಗಲೂ ಚಿತ್ರದಲ್ಲಿ ತೋರಿಸಿದ್ದಲ್ಲ. ಪ್ರಶ್ನೆಯಲ್ಲಿರುವ ಗಮ್ಯಸ್ಥಾನದ ಬಗ್ಗೆ ನೇರವಾಗಿ ಅದನ್ನು ಕೇಳಿ. ಉತ್ತರವು ಇಂಟರ್ಫೇಸ್, ಮುಂದಿನ ಹಾಪ್ ಮತ್ತು ಬಳಸಲಾಗುವ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ದೂರದ ತುದಿ ನಿರಾಕರಿಸುವ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಟನೆಲ್ನಿಂದ ಹೊರಬಹುದು, ಮತ್ತು ಭೌತಿಕ ಕೋಷ್ಟಕದ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ನಮೂದು ಅದನ್ನು ಬದಲಿಗೆ Wi-Fi ಇಂಟರ್ಫೇಸ್ನಿಂದ ಕಳುಹಿಸಬಹುದು.
ip route get 10.20.30.40
ip -brief address show
dev, via ಮತ್ತು src ಕ್ಷೇತ್ರಗಳನ್ನು ಈ ಕ್ರಮದಲ್ಲಿ ಓದಿ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಸಂಶಯವನ್ನು ತೆಗೆಯುತ್ತದೆ. ಈ ಹಂತವು ಕ್ಲೈಂಟ್ ಸ್ಥಾಪಿಸಿದ ಸ್ಥಿತಿಯನ್ನೂ ಹೊಂದಿದೆ, ಏಕೆಂದರೆ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು ಮತ್ತು ಮಾರ್ಗಗಳು ಅಸಾಮಾನ್ಯ ನಿರ್ಗಮನದ ನಂತರವೂ ಉಳಿಯಬಹುದು. ಆದ್ದರಿಂದ «ಟನೆಲ್ ಇಲ್ಲದೆ ಇಂಟರ್ನೆಟ್ ಇಲ್ಲ» ಮತ್ತು «ಕ್ಲೈಂಟ್ ಓಡದಿದ್ದರೆ ಇಂಟರ್ನೆಟ್ ಇಲ್ಲ» ಎರಡಲ್ಲ, ಒಂದೇ ದೋಷ-ಕುಟುಂಬ.
ಪ್ಯಾಕೆಟ್ ಗಾತ್ರವನ್ನು ಪರೀಕ್ಷಿಸಿ
ದೊಡ್ಡ ವರ್ಗಾವಣೆ ನಿಂತಾಗ ಮರಳಿ ಬರುವ ಚಿಕ್ಕ ಉತ್ತರ ಮೊದಲು ಮಾರ್ಗದ MTUಗೆ ಸೂಚಿಸುತ್ತದೆ. ಟನೆಲ್ನ ಒಳಗಿನಿಂದ ಕಳುಹಿಸಿದ, do-not-fragment ಬಿಟ್ ಹೊಂದಿಸಿದ ಒಂದು ಪ್ರೋಬ್ ಈ ಹಂತವನ್ನು ಉಳಿದವುಗಳಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಪ್ರೋಬ್ ವಿಫಲವಾಗುವವರೆಗೆ ಪೇಲೋಡ್ ಹೆಚ್ಚಿಸಿ, ಮತ್ತು ಮುಖ್ಯವಾದ ಸಂಖ್ಯೆ ನಿಮ್ಮ ಬಳಿ ಇರುತ್ತದೆ.
ping -M do -s 1400 10.20.30.40
ಡೈರೆಕ್ಟರಿ ಪಟ್ಟಿ ಅಥವಾ ಅಪ್ಲೋಡ್ ನೇತಾಡುತ್ತಿರುವಾಗ ಚಿಕ್ಕ ಪ್ರೋಬ್ಗಳು ಉತ್ತೀರ್ಣವಾಗುವುದು ಈ ಹಂತದ ಸಹಿ. ದೂರು ರುಜುವಾತುಗಳು ಅಥವಾ ಫೈರ್ವಾಲ್ ನಿಯಮದಂತೆ ಕೇಳಿಸುತ್ತದೆ, ಆದರೆ ಎರಡೂ ಅಲ್ಲ.
ಸಂಖ್ಯೆ ಕ್ಲೈಂಟ್ನದಲ್ಲ, ಮಾರ್ಗದ ಗುಣಲಕ್ಷಣ, ಆದ್ದರಿಂದ ಕಚೇರಿ ಸಂಪರ್ಕದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಮೌಲ್ಯ ಮೊಬೈಲ್ ಲಿಂಕ್ನಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು. ಪ್ರೋಬ್ ಆದೇಶವನ್ನು ಟಿಕೆಟ್ನೊಂದಿಗೆ ಇರಿಸಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಅದೇ ಅಳತೆ ಬೇಕು. ಚಿಕ್ಕ ಪೇಲೋಡ್ ಉತ್ತೀರ್ಣವಾದರೆ, ಪರಿಹಾರ clamp ಅಥವಾ ಕಡಿಮೆ ಟನೆಲ್ MTU, ಹೊಸ ಸೈಫರ್ ಅಲ್ಲ.
ದೂರದ ತುದಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ
ಗಮ್ಯಸ್ಥಾನವನ್ನು ಅದರ ವಿಳಾಸದಿಂದ ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಅಲ್ಲಿ ಏನು ಆಲಿಸುತ್ತಿದೆ ಎಂದು ನೋಡಿ. ನಿರಾಕರಿಸಲಾದ ಸಂಪರ್ಕ ಮತ್ತು ಎಂದಿಗೂ ಉತ್ತರಿಸದ ಸಂಪರ್ಕ ಬೇರೆ ಬೇರೆ ಕಂಡುಹಿಡಿತಗಳು. ಮೊದಲನೆಯದು ಏನೋ ಚಾಲನೆಯಲ್ಲಿದೆ ಮತ್ತು ಆ ಪೋರ್ಟ್ಗೆ ಸೇವೆ ನೀಡುತ್ತಿಲ್ಲ ಎಂದು ಹೇಳುತ್ತದೆ, ಎರಡನೆಯದು ಏನೂ ಮರಳಿ ಬರಲಿಲ್ಲ ಎಂದು ಹೇಳುತ್ತದೆ. ಯಾವುದೂ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಕ್ಲೈಂಟ್ ಸಮಸ್ಯೆ ಅಲ್ಲ.
curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'
ಟನೆಲ್ ಮೂಲಕ ತಲುಪಬಹುದಾದ ಯಾವುದೂ ಕೇವಲ 127.0.0.1 ನಲ್ಲಿ ಆಲಿಸುವ ಸೇವೆಯಾಗಿರಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಆಲಿಸುವವರು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ. ದೂರದ ಹೋಸ್ಟ್ನ ಫೈರ್ವಾಲ್ ಕಚೇರಿ ಸಬ್ನೆಟ್ ಅನ್ನು ಅನುಮತಿಸಿ ಟನೆಲ್ ಪೂಲ್ ಅನ್ನು ನಿರಾಕರಿಸಿದಾಗ, ಫಲಿತಾಂಶ ಕ್ಲೈಂಟ್ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಅದು ಅಲ್ಲ. ವೆಬ್ ಟ್ರಾಫಿಕ್ ಬದುಕಿರುವಾಗ Remote Desktop ಅಥವಾ ಫೈಲ್ ಹಂಚಿಕೆ ಮುರಿಯುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಇಲ್ಲಿಗೇ ಬರುತ್ತದೆ, ಬಳಕೆದಾರರು ಹೇಗೇ ಹೇಳಿದರೂ.
ದೂರನ್ನು ಒಂದು ಹಂತಕ್ಕೆ ಹೊಂದಿಸಿ
ಹೆಚ್ಚಿನ ವರದಿಗಳು ಐದು ಆಕಾರಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಇಳಿಯುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿ ಆಕಾರವೂ ಒಂದು ಹಂತವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಟನೆಲ್ ಮೂಲಕ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ಒಂದು ಸೈಟ್ ಹೆಸರಿನ ಉತ್ತರ ಅಥವಾ ಮೂಲ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ನೀತಿ. ಟನೆಲ್ ಇಲ್ಲದೆ ನವೀಕರಣಗಳು ವಿಫಲವಾಗಿ ಬ್ರೌಸಿಂಗ್ ಕೆಲಸ ಮಾಡಿದರೆ, ಅದು ಆ ಕ್ಲೈಂಟ್ಗೆ ಹೆಸರು ಅಥವಾ ಮಾರ್ಗದ ಸಮಸ್ಯೆ.
ಪ್ರದಾತನ ಕ್ಲೈಂಟ್ ಪ್ರಾರಂಭವಾದಾಗ ಎಲ್ಲವೂ ನಿಲ್ಲುವುದು ಸ್ಥಾಪಿತ ಸ್ಥಿತಿ, ಅಂದರೆ ಮಾರ್ಗ ಮತ್ತು ಫೈರ್ವಾಲ್ ಪ್ರಶ್ನೆ. ಉಳಿದದ್ದು ಸರಿಯಿರುವಾಗ ಒಂದು ಸೇವೆ ತಲುಪಲಾಗದಿರುವುದು ದೂರದ ತುದಿ. ವರ್ಗಾವಣೆಗಳು ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಂತರ ನಿಲ್ಲುವುದು ಪ್ಯಾಕೆಟ್ ಗಾತ್ರ. ಆದೇಶಗಳನ್ನು ಓಡಿಸುವ ಮೊದಲು ಆಕಾರವನ್ನು ಹೊಂದಿಸಿ, ಏಕೆಂದರೆ ಯಾವ ಸಾಕ್ಷ್ಯವನ್ನು ಮೊದಲು ಸಂಗ್ರಹಿಸಬೇಕೆಂದು ಅದು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಮೊದಲ ವೈಫಲ್ಯವನ್ನು ಉಂಟುಮಾಡಿದ ಹಂತವನ್ನು ಆದೇಶದ ಔಟ್ಪುಟ್ನೊಂದಿಗೆ ದಾಖಲಿಸಿ. ಮೂಲ ವಿಳಾಸ ತಪ್ಪಾಗಿತ್ತು ಎಂದು ಹೇಳುವ, ಮಾರ್ಗದ ಸಾಲನ್ನು ಲಗತ್ತಿಸಿದ ಟಿಕೆಟ್ ಕ್ರಮಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ, ಆದರೆ VPN ಮುರಿದಿದೆ ಎಂದು ವರದಿ ಮಾಡುವ ಟಿಕೆಟ್ ಅಲ್ಲ.