NetworkManager ನಲ್ಲಿ gateway-ping-timeout ನಿಜವಾಗಿ ಯಾವುದಕ್ಕೆ ಕಾಯುತ್ತದೆ

ನೆಟ್ವರ್ಕ್ ಬಳಸಲು ಸಿದ್ಧವಾಗುವ ಮೊದಲೇ ಬೂಟ್ ಆಗುವ ಲ್ಯಾಪ್ಟಾಪ್ ಕುರಿತ ಥ್ರೆಡ್ನಲ್ಲಿ ನೀವು connection.gateway-ping-timeout ಕಾಣುತ್ತೀರಿ, ಅದನ್ನು ಹೆಚ್ಚಿಸುತ್ತೀರಿ, ಮತ್ತು ಏನೋ ಬದಲಾಗುತ್ತದೆ. ನೀವು ಭಾವಿಸುವ ಕಾರಣಕ್ಕೆ ಆ ಬದಲಾವಣೆ ಸಹಾಯ ಮಾಡಿತೇ ಎಂಬುದು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆ. ಉತ್ತರವು, ಆ ಟೈಮರ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದರಿಂದ, ಮತ್ತು ಕಾಯುವಿಕೆಗೆ ಎರಡು ಸಂಭಾವ್ಯ ಅಂತ್ಯಗಳಿವೆ ಎಂಬ ಅಂಶದಿಂದ ಆರಂಭವಾಗುತ್ತದೆ.

ಕಮಾಂಡ್ ಲೈನ್ನಿಂದ ಒಂದು ಸಂಪರ್ಕವನ್ನು ಅನುಸರಿಸಿ, ಅರ್ಥ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.

ಒಂದು ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆಯನ್ನು ಅನುಸರಿಸಿ

ಜಾಗತಿಕ ಡೀಫಾಲ್ಟ್ ಬದಲು ಉಳಿಸಿದ ಸಂಪರ್ಕವನ್ನು ನೋಡುವುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಇದು ಪ್ರತಿ-ಸಂಪರ್ಕ ಗುಣಲಕ್ಷಣ. ಸೇರಿಸಿ --show-secrets ನಿಜವಾಗಿ ಅಗತ್ಯವಿದ್ದರೆ ಮಾತ್ರ; ಸೆಟ್ಟಿಂಗ್ ಸ್ವತಃ ರಹಸ್ಯವಲ್ಲ.

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

ಗುಣಲಕ್ಷಣ ಶೂನ್ಯದಲ್ಲಿದ್ದಾಗ, ಅದು ದಾಖಲಿತ ಡೀಫಾಲ್ಟ್, ವಿಳಾಸೀಕರಣ ಮುಗಿದ ಕೂಡಲೇ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ ಮುಂದುವರಿಯುತ್ತದೆ. ಅದನ್ನು ಧನಾತ್ಮಕ ಮೌಲ್ಯಕ್ಕೆ ಇರಿಸಿ, ಆಗ IP ಸಂರಚನೆಯ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ ಗೇಟ್ವೇಯಿಂದ ಉತ್ತರ ಬರುವವರೆಗೆ ಅಥವಾ ಸಮಯ ಮಿತಿ ಮುಗಿಯುವವರೆಗೆ ಕಾಯುತ್ತದೆ.

ನಂತರ ಈವೆಂಟ್ ಸ್ಟ್ರೀಮ್ ನೋಡುತ್ತಾ ಸಂಪರ್ಕವನ್ನು ಕೆಳಗೆ ಮತ್ತು ಮೇಲೆ ತನ್ನಿ. ನೀವು ಕಾಣುವ ಕ್ರಮವೇ ಸೆಟ್ಟಿಂಗ್ನ ಕೆಲಸ: ಸಾಧನದ ಸ್ಥಿತಿ, ವಿಳಾಸೀಕರಣ, ಕಾಯುವಿಕೆ, ಮತ್ತು ಕೊನೆಗೆ ಅವಲಂಬಿತ ಸೇವೆಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಜೋಡಿಸುವ ಸಕ್ರಿಯ ಸ್ಥಿತಿ.

ಕಾಯುವಿಕೆಗೆ ಎರಡು ಅಂತ್ಯಗಳಿವೆ

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

ಆ ಒಂದು ವಾಕ್ಯವು ಹೋಟೆಲ್ಗಳು ಮತ್ತು ಸಮ್ಮೇಳನ ಸ್ಥಳಗಳಲ್ಲಿನ ಲ್ಯಾಪ್ಟಾಪ್ಗಳ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಗೊಂದಲವನ್ನು ನಿವಾರಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಕ್ಯಾಪ್ಟಿವ್ ಪೋರ್ಟಲ್ ನೀವು ಲಾಗಿನ್ ಆಗುವವರೆಗೆ ICMP ಅನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ. ಸಮಯ ಮಿತಿ ಮುಗಿದ ನಂತರವೂ ಸಂಪರ್ಕ ಸಕ್ರಿಯಗೊಳ್ಳುತ್ತದೆ; ಅದು ಬೇಕಾದುದಕ್ಕಿಂತ ತಡವಾಗಿ ಮಾಡುತ್ತದೆ ಅಷ್ಟೇ, ಮತ್ತು ಸಂಪರ್ಕದ ನಂತರ ಜೋಡಿಸಲಾದ ಪ್ರತಿ ಸೇವೆಯೂ ಅದರೊಂದಿಗೆ ಕಾಯುತ್ತದೆ.

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

ಎರಡು ವಸ್ತುಗಳು, ಒಂದು ಸೆಟ್ಟಿಂಗ್

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

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

ಹೆಸರುಗಳ ಬದಲು UUID ಓದಿ. ಮರುಸ್ಥಾಪನೆ ಅಥವಾ ಮರುಸ್ಥಾಪಿತ ಪ್ರೊಫೈಲ್ ನಂತರ ಹೆಸರುಗಳು ನಕಲಾಗುತ್ತವೆ, ಮತ್ತು ಒಂದೇ ಕಾಣುವ ಹೆಸರಿನ ಎರಡು ಸಂಪರ್ಕಗಳು ನಿಜವಾದದ್ದು ಬದಲಾಗದೆ ಇರುವಾಗ ನಿಮ್ಮಿಂದ ತಪ್ಪು ಫೈಲ್ ಸಂಪಾದಿಸುವಂತೆ ಮಾಡುತ್ತವೆ.

ಸ್ಥಾಪಿತವಾದ NetworkManager ಆವೃತ್ತಿಯೂ ಮುಖ್ಯ. ಪ್ಲಗಿನ್ನ ವರ್ತನೆ ಮತ್ತು ಸಂಪರ್ಕ ಪ್ರಕಾರವು ಈ ಗುಣಲಕ್ಷಣವನ್ನು ತನ್ನದೇ ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ ಹಂತಗಳಿಗೆ ಹೇಗೆ ನಕ್ಷೆ ಮಾಡುತ್ತದೆ ಎಂಬುದು ಬದಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ನಿಯೋಜಿಸುವ ಆವೃತ್ತಿಯಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ, ನೀವು ಕಂಡ ಪೋಸ್ಟ್ ಬದಲಾವಣೆ ಇಲ್ಲದೆ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದು ಊಹಿಸಬೇಡಿ.

ಕಾಯುವಿಕೆ ಏನನ್ನು ಪ್ರಮಾಣೀಕರಿಸಲಾಗದು

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

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

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

ಬದಲಿಸಿದರೆ ಕಾರಣ ಬರೆಯಿರಿ

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

ಒಂದು ಐತಿಹಾಸಿಕ ಬಲೆಗೆ ಹೆಸರಿಡುವುದು ಯೋಗ್ಯ: ಇಂತಹ ಮೌಲ್ಯವನ್ನು ಕೆಲವೊಮ್ಮೆ ಹಳೆಯ ಸಂಪಾದಕ ಪ್ರೊಫೈಲ್ ಸ್ವೀಕರಿಸಲು ಬದಲಿಸಲಾಗುತ್ತದೆ. ಅದೇ ನಿಜವಾದ ಕಥೆಯಾದರೆ, ನಿಮಗೆ ಒಂದಲ್ಲ ಎರಡು ಘಟನೆಗಳಿವೆ. ಸಂಪಾದಕ ಉಳಿಸಿತು, ಮತ್ತು ಜೀವಂತ ನೆಟ್ವರ್ಕ್ ನೀತಿ ಬದಲಾಯಿತು. ಸಂಪಾದಕ ಅಥವಾ ಪ್ಲಗಿನ್ ಸರಿಪಡಿಸಿ ಟೈಮರ್ ಅನ್ನು ಹಿಂದಕ್ಕೆ ಇರಿಸಿ.

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