VPN ನಲ್ಲಿ SSH ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ ಕಡಿತಗೊಳ್ಳುತ್ತದೆಯೇ? ಕಾರಣ keepalive ಅಲ್ಲ

SSH ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಸುಮಾರು ಒಂದು ನಿಮಿಷ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ನಂತರ ಪ್ರತಿ ಬಾರಿ ಸುಮಾರು ಅದೇ ಮಧ್ಯಂತರದಲ್ಲಿ ಹೆಪ್ಪುಗಟ್ಟುತ್ತದೆ. ಸಾಮಾನ್ಯ ವಿವರಣೆ ನಿಷ್ಕ್ರಿಯ ಟೈಮೌಟ್, ಆದ್ದರಿಂದ ಜನರು MTU ಕಡಿಮೆ ಮಾಡಿ ಕ್ಲೈಂಟ್ keepalives ಸೆಟ್ ಮಾಡುತ್ತಾರೆ. ನಾನು ಕೆಲಸ ಮಾಡಿದ WireGuard ಲಿಂಕ್ ಈ ಎಲ್ಲವನ್ನೂ ಈಗಾಗಲೇ ದಾಟಿತ್ತು: ಚಿಕ್ಕ ಟನಲ್ MTU, client-alive ಸೆಟ್ಟಿಂಗ್ಗಳು, ಸಂರಚಿಸಿದ ಟನಲ್ keepalive. ಕಡಿತಗಳು ಬದಲಾವಣೆ ಇಲ್ಲದೆ ಮುಂದುವರಿದವು. ಕಾರಣ ಅಸಮಮಿತ LAN ಮಾರ್ಗ ಎಂದು ತಿಳಿಯಿತು, ಮತ್ತು ಈ ಮಾದರಿಯನ್ನು ಗುರುತಿಸುವುದು ಯೋಗ್ಯ ಏಕೆಂದರೆ ಇದು ಟೈಮರ್ ಆಧಾರಿತ ಪ್ರತಿಯೊಂದು ಪರಿಹಾರವನ್ನೂ ಸೋಲಿಸುತ್ತದೆ.

keepalive ನಿಮ್ಮ ಹೋಸ್ಟ್ ಇನ್ನೂ ಕಳುಹಿಸಲು ಸಿದ್ಧವಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಅದು ಎಂದಿಗೂ ಅದರ ಮೂಲಕ ಹಾದುಹೋಗದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ಥಿತಿ ಇಟ್ಟುಕೊಳ್ಳುವ ಸಾಧನಕ್ಕೆ ನೋಡಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಪುರಾಣ: keepalives ಮೌನ ಕಡಿತವನ್ನು ಸರಿಪಡಿಸುತ್ತವೆ

SSH keepalives ಒಂದೇ ಕೆಲಸಕ್ಕಾಗಿ ಇವೆ: ಮೌನವನ್ನು ಎಣಿಸುವ ಯಾವುದೋ ಒಂದು ನಿಷ್ಕ್ರಿಯ ಸೆಷನ್ ಅನ್ನು ತೆಗೆದುಹಾಕದಂತೆ ತಡೆಯುವುದು. ಅವು ಅದನ್ನು ಚೆನ್ನಾಗಿ ಮಾಡುತ್ತವೆ. ಒಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಮೊದಲ ಪ್ಯಾಕೆಟ್ ನೋಡಿ ನಂತರ ಎಂದಿಗೂ ಪ್ರತಿಕ್ರಿಯೆ ನೋಡದ ಸ್ಥಿತಿ ಇಟ್ಟುಕೊಳ್ಳುವ ಸಾಧನದ ಸಮಸ್ಯೆಯನ್ನು ಅವು ಪರಿಹರಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಕಳುಹಿಸುವ ಯಾವುದೂ ಪ್ರತಿಕ್ರಿಯೆ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

MTU ಬದಲಾವಣೆ ಇನ್ನೊಂದು ಜನಪ್ರಿಯ ಪರಿಹಾರ, ಮತ್ತು ಅದಕ್ಕೂ ಅದೇ ವಿಫಲತೆ ವಿಧಾನವಿದೆ. MTU ಕಡಿಮೆ ಮಾಡುವುದು ತುಣುಕು ಮತ್ತು ಪಥ-MTU ಸಮಸ್ಯೆಗಳಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಮಾರ್ಗಕ್ಕೆ ಏನೂ ಮಾಡುವುದಿಲ್ಲ. ನಿಮ್ಮ ಟೈಮರ್ಗಳು ಮತ್ತು MTU ಈಗಾಗಲೇ ಸಮಂಜಸವಾಗಿದ್ದು ಕಡಿತವು ಇನ್ನೂ ಪುನರಾವರ್ತಿತ ಮಧ್ಯಂತರದಲ್ಲಿದ್ದರೆ, ಮಧ್ಯಂತರವು ಎಲ್ಲೋ ಒಂದು ಟೈಮೌಟ್ ಬಗ್ಗೆ ಹೇಳುತ್ತದೆ, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರದ ಬಗ್ಗೆ ಅಲ್ಲ. ಮಧ್ಯಂತರವನ್ನು ಬರೆದಿಟ್ಟು ಪಥದ ಪ್ರತಿ ಸಾಧನದ ಸ್ಥಿತಿ ಟೈಮೌಟ್ಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಸೂಚನೆ ಎಂದರೆ ನಿಯಮಿತತೆ ಜೊತೆಗೆ ಆ ಮಧ್ಯಂತರದೊಳಗೆ ಸೆಷನ್ ಬಳಸಲು ಯೋಗ್ಯವಾಗಿ ಉಳಿಯುವುದು. ನಿಷ್ಕ್ರಿಯ ಟೈಮೌಟ್ಗಳು ಏನೂ ನಡೆಯದಿದ್ದಾಗ ಬಡಿಯುತ್ತವೆ; ಇದು ನೀವು ಟೈಪ್ ಮಾಡುವಾಗ ಬಡಿಯುತ್ತದೆ.

ಹೆಚ್ಚುವರಿ ಗೇಟ್ವೇ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ

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

ಕೆಳಗಿನ ವಿಳಾಸಗಳು ಆ ವ್ಯವಸ್ಥೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತವೆ:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

ಮರುನಿರ್ದೇಶನಗಳು ಮತ್ತು ಸ್ಥಿತಿ ನಿರ್ವಹಣೆ ನಂತರ ಕೆಲಸ ಮಾಡುವ ಹ್ಯಾಂಡ್ಶೇಕ್ ಅನ್ನು ತಕ್ಷಣವಲ್ಲ, ನಂತರ ಸಾಯುವ ಸಂಪರ್ಕವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತವೆ. ವಿಳಂಬವು ಸ್ಥಿತಿ ನಮೂದು ಹಳೆಯದಾಗುವುದು ಅಥವಾ ಕಠಿಣ ಪರಿಶೀಲನೆ ವಿಫಲವಾಗುವುದು, ಆದ್ದರಿಂದ ಮಧ್ಯಂತರವು ಇಷ್ಟು ಯಾಂತ್ರಿಕವಾಗಿ ಕಾಣುತ್ತದೆ.

ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಕ್ಲೈಂಟ್ ಸಂರಚನೆಯಲ್ಲಿ ಕಾಣುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದರ ಹುಡುಕಾಟ ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪು ಫೈಲ್ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಒಂದು ಉದ್ದೇಶಪೂರ್ವಕ ಮಾರ್ಗವನ್ನು ಆರಿಸಿ

ಮೇಲಿನ ವ್ಯವಸ್ಥೆಗೆ, ದೂರದ ಸಬ್ನೆಟ್ ಅನ್ನು ನೇರವಾಗಿ VPN ಗೇಟ್ವೇಗೆ ರೂಟ್ ಮಾಡುವುದು ಅರ್ಧ ಸಂಪರ್ಕವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

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

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

Netgate ನ ಅಸಮಮಿತ ರೂಟಿಂಗ್ ಕುರಿತು ಟಿಪ್ಪಣಿಗಳು ಅದೇ ಇಂಟರ್ಫೇಸ್ ಮಟ್ಟದ ಅಸಮಮಿತಿ ಮತ್ತು ಅದರಿಂದ ಉಂಟಾಗುವ ಸ್ಥಿತಿ ಸಮಸ್ಯೆಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಸ್ಥಿತಿ ನಿರ್ವಹಣೆಯನ್ನು ಜಾಗತಿಕವಾಗಿ ಸಡಿಲಿಸುವ ಮೊದಲು ಅವುಗಳನ್ನು ಓದಿ. ಈ ಪ್ರಕರಣದಂತಹ ಸಮಯಬದ್ಧ ಸಂಪರ್ಕ ಕಡಿತಗಳು ತಾವಾಗಿಯೇ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಲೇಖನವನ್ನು ಒಂದು ವಿಫಲತೆ ವಿಧಾನದ ವಿವರಣೆ ಎಂದು ಪರಿಗಣಿಸಿ, ನಂತರ ಜಾಗತಿಕ ಸ್ಥಿತಿ ನೀತಿ ಬದಲಿಸುವ ಮೊದಲು ನಿಮ್ಮ ಸ್ವಂತ ನೆಟ್ವರ್ಕ್ ಅದಕ್ಕೆ ಹೊಂದುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ.

ಎರಡೂ ತುದಿಗಳಿಂದ ಪರೀಕ್ಷಿಸಿ

ಲ್ಯಾಪ್ಟಾಪ್ನ ಗಮ್ಯಸ್ಥಾನದ ಕಡೆಗಿನ ಮಾರ್ಗ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಲ್ಯಾಪ್ಟಾಪ್ನ ಕಡೆಗಿನ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಓದಿ; ಇವು ಎರಡು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರಗಳು ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ತಪ್ಪಾಗಿರಬಹುದು. ಗೇಟ್ವೇಯಿಂದಲೇ ಯಶಸ್ವಿಯಾಗುವ ping ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮರೆಮಾಡಬಹುದು, ಏಕೆಂದರೆ ಅದು ಮಾರ್ಗ ಈಗಾಗಲೇ ಸರಿಯಾಗಿರುವ ಯಂತ್ರದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ನಿಜವಾದ ಸೆಷನ್‌ನ ಎರಡೂ ತುದಿಗಳು ನೋಡುವಂತೆ ಎರಡೂ ದಿಕ್ಕುಗಳು ನಿಮಗೆ ಬೇಕು.

ಸರಿಪಡಿಸಿದ ನಂತರ SSH ಅನ್ನು ಮತ್ತೆ ತೆರೆಯಿರಿ ಮತ್ತು ಹಿಂದೆ ವಿಫಲವಾಗುತ್ತಿದ್ದ ಮಧ್ಯಂತರಕ್ಕಿಂತ ಬಹಳ ಮುಂದೆಯೂ ಸೆಷನ್ ತೆರೆದಿಡಿ. ನಂತರ ಅನುಮೋದಿತ ನೆಟ್ವರ್ಕ್ ಸಂರಚನೆಯಲ್ಲಿ ಮಾರ್ಗವನ್ನು ಶಾಶ್ವತಗೊಳಿಸಿ, ಏಕೆಂದರೆ ಒಂದು ಬಾರಿಯ ಆಜ್ಞೆ ಮರುಪ್ರಾರಂಭದ ಯೋಜನೆ ಅಲ್ಲ ಮತ್ತು ಮುಂದಿನ ಮರುಪ್ರಾರಂಭದಲ್ಲಿ ಸಮಸ್ಯೆ ಹೊಸ ಒಗಟಿನೊಂದಿಗೆ ಮರಳುತ್ತದೆ.

ಅಸಮಮಿತಿ ಯಾವಾಗ ಸರಿ

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

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