DHCP ನವೀಕರಣದ ನಂತರ OpenVPN ಕುಸಿಯುತ್ತದೆ: ಎಂಡ್ಪಾಯಿಂಟ್ ಮಾರ್ಗವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ

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

ಲಕ್ಷಣವನ್ನು ಅರ್ಧ-ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ

redirect-gateway def1 ಜೊತೆಗೆ, OpenVPN ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬದಲಿಸುವ ಬದಲು 0.0.0.0/1 ಮತ್ತು 128.0.0.0/1 ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಎರಡೂ ಸೇರಿ ಇಡೀ ವಿಳಾಸ ಸ್ಥಳವನ್ನು ಆವರಿಸುತ್ತವೆ, ಮತ್ತು ಅವು ಕೇವಲ ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದದಿಂದ 0.0.0.0/0 ಅನ್ನು ಸೋಲಿಸುತ್ತವೆ. ಆದ್ದರಿಂದ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಹೊಂದಾಣಿಕೆ ಇಲ್ಲದ ಯಾವುದೇ ಗಮ್ಯಸ್ಥಾನ ಟನೆಲ್ ಪ್ರವೇಶಿಸುತ್ತದೆ.

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

ಬೇರೆ ಯಾವುದನ್ನೂ ಮುಟ್ಟುವ ಮೊದಲು ಕೋಷ್ಟಕದ ಆಕಾರವನ್ನು ದೃಢೀಕರಿಸಿ. ip route show ಎರಡೂ ಅರ್ಧಗಳನ್ನು ಮತ್ತು ಸರ್ವರ್ ವಿಳಾಸಕ್ಕೆ ಹೋಸ್ಟ್ ಮಾರ್ಗವನ್ನು ಪಟ್ಟಿ ಮಾಡಬೇಕು; ಹೋಸ್ಟ್ ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದರೆ, ಉಳಿದ ತನಿಖೆಗೆ ಸ್ಪಷ್ಟ ಆರಂಭಿಕ ಬಿಂದು ಇರುತ್ತದೆ.

ಮೆಟ್ರಿಕ್ ಬದಲಿಸದೆ ಅರ್ಧ-ಡೀಫಾಲ್ಟ್ಗಳು ಏಕೆ ಗೆಲ್ಲುತ್ತವೆ

ಕಡಿಮೆ ಮೆಟ್ರಿಕ್ ಉದ್ದವಾದ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಸೋಲಿಸುವುದಿಲ್ಲ. /1 ಮಾರ್ಗಗಳು ಗೆಲ್ಲುತ್ತವೆ ಏಕೆಂದರೆ ಕರ್ನಲ್ ಮೊದಲು ಅತ್ಯಂತ ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗವನ್ನು ಹೊಂದಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದಲ್ಲಿ ಮೆಟ್ರಿಕ್ ಹೆಚ್ಚಿಸುವುದು ಟನೆಲ್ಗೆ ಹೋಗುವ ಸಂಚಾರ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಮೆಟ್ರಿಕ್ಗಳ ಹಿಂದೆ ಓಡುವುದು ಈ ರೋಗನಿರ್ಣಯದಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು ತಿರುವು.

ip route get 203.0.113.10 ನೊಂದಿಗೆ ಆಯ್ಕೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಅದರಲ್ಲಿ ನಿಜವಾದ ಸರ್ವರ್ ವಿಳಾಸವನ್ನು ಹಾಕಿ. ಉತ್ತರವು ಕರ್ನಲ್ ನಿಜವಾಗಿ ಬಳಸುವ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಇದು ಕೋಷ್ಟಕ ಓದಿ ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮಾಹಿತಿಪೂರ್ಣ.

ಆ ಆದೇಶವನ್ನು ಟನೆಲ್ ಆರಂಭವಾಗುವ ಮೊದಲು, ಅದು ಚಾಲನೆಯಲ್ಲಿರುವಾಗ, ಮತ್ತು ಲೀಜ್ ಘಟನೆಯ ನಂತರ ಚಲಾಯಿಸಿ. ಒಂದು ಆದೇಶದಿಂದ ಮೂರು ಉತ್ತರಗಳು, ಮತ್ತು ವ್ಯತ್ಯಾಸದ ಬಿಂದು ಗೋಚರವಾಗುತ್ತದೆ.

ಒಂದಲ್ಲ, ಮೂರು ಸ್ನ್ಯಾಪ್ಶಾಟ್ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ

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

ಸ್ನ್ಯಾಪ್ಶಾಟ್ಗಳನ್ನು ಸಮಯಮುದ್ರೆಗಳೊಂದಿಗೆ ಒಂದೇ ಕಡತದಲ್ಲಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ನಂತರ ಆಸಕ್ತಿಕರ ಪ್ರಶ್ನೆ ಕ್ರಮ. DHCP ಘಟನೆ OpenVPN ತನ್ನ ಮಾರ್ಗವನ್ನು ನವೀಕರಿಸುವ ಮೊದಲು ಬಂತೋ ಅಥವಾ ನಂತರವೋ? ಉತ್ತರವು ಅದನ್ನು ಯಾರು ಸರಿಪಡಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ತಪ್ಪು ಗಡಿಯಾರದ ಸಮಯಮುದ್ರೆ ಇಲ್ಲದಿರುವುದಕ್ಕಿಂತ ಕೆಟ್ಟದು, ಆದ್ದರಿಂದ ಅದನ್ನು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ಹೊಂದಿರುವ ಹೋಸ್ಟ್ನಿಂದ ತೆಗೆದುಕೊಳ್ಳಿ.

ಎಂಡ್ಪಾಯಿಂಟ್ ವಿಳಾಸದ ಬದಲು ಹೆಸರಾಗಿ ಸಂರಚಿಸಲ್ಪಟ್ಟಾಗ, ಅದನ್ನು ಪ್ರತಿ ಸ್ನ್ಯಾಪ್ಶಾಟ್ನಲ್ಲೂ ಪರಿಹರಿಸಿ. ಪ್ರವೇಶ ಲಿಂಕ್ನಲ್ಲಿ DNS ಬದಲಾವಣೆ ಯಾವುದೇ ಮಾರ್ಗವನ್ನು ಮುಟ್ಟದೆ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಸರಿಸಬಹುದು.

ಯಾವ ಘಟಕ ವಿನಾಯಿತಿಯನ್ನು ನವೀಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ

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

ವಿಶ್ವಾಸಾರ್ಹ ಮಾಲೀಕ ಎಂದರೆ ಈಗಾಗಲೇ ಎರಡೂ ಬದಿಗಳನ್ನು ತಿಳಿದಿರುವ ಸಂಯೋಜನೆ: VPN ಸಂಪರ್ಕವನ್ನು ನಿರ್ವಹಿಸುವ ನೆಟ್ವರ್ಕ್ ನಿರ್ವಾಹಕ, ಅಥವಾ ಪ್ರವೇಶ ಲಿಂಕ್ ಮೇಲೇರಿದ ನಂತರ ಜೋಡಿಸಲಾದ ಘಟಕ. ಹುಕ್ ಸೇರಿಸಿದ ಸ್ಥಿರ ಮಾರ್ಗವು ಮುಂದಿನ ಗೇಟ್ವೇ ಬದಲಾವಣೆಯವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ನಂತರ ಅದೇ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ನೀವು ಹುಕ್ ಬಳಸುವುದಾದರೆ, ಇಂದು ನೋಡಿದ ಗೇಟ್ವೇಯನ್ನು ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡುವ ಬದಲು ರನ್ಟೈಮ್ನಲ್ಲಿ ಪ್ರಸ್ತುತ ಗೇಟ್ವೇಯನ್ನು ಓದಲು ಅನುಮತಿಸಿ.

ಮಾಲೀಕನನ್ನು ಸಂರಚನೆಯ ಒಳಗೆ ದಾಖಲಿಸಿ. ಮರುಸಂಪರ್ಕವನ್ನು ಡೀಬಗ್ ಮಾಡುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ವಿನಾಯಿತಿ ಮಾರ್ಗಕ್ಕೆ VPN ಅಲ್ಲ, ಹುಕ್ ಜವಾಬ್ದಾರಿ ಎಂದು ತಿಳಿಯಬೇಕು.

ಮರುಸಂಪರ್ಕ ಮಾತ್ರವಲ್ಲ, ಜೀವನಚಕ್ರವನ್ನು ಪರೀಕ್ಷಿಸಿ

dhcpcd -n eth0 ನಿಂದ ಅಥವಾ ಲೀಜ್ ಬಿಟ್ಟು ಮತ್ತೆ ಪಡೆಯುವ ಮೂಲಕ ನವೀಕರಣವನ್ನು ಒತ್ತಾಯಿಸಿ, ನಂತರ ಎಂಡ್ಪಾಯಿಂಟ್ಗಾಗಿ ip route get ಅನ್ನು ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ. ಅದನ್ನು ಎರಡು ಬಾರಿ ಮಾಡಿ, ಏಕೆಂದರೆ ಎರಡನೇ ಸುತ್ತು ನಕಲಿ ಮಾರ್ಗಗಳನ್ನು ಸೇರಿಸುವ ಹುಕ್ಗಳನ್ನು ಹಿಡಿಯುತ್ತದೆ. ನಂತರ ಮರುಬೂಟ್ ಮಾಡಿ, ಏಕೆಂದರೆ ನಿರಂತರತೆ ಸರಿಯಾಗಿರುವಿಕೆಗಿಂತ ಬೇರೆ ಗುಣ.

ನವೀಕರಣ ಮತ್ತು ಮರುಬೂಟ್ ಎರಡನ್ನೂ ತಾಳಿಕೊಳ್ಳುವ ಟನೆಲ್ಗೆ ಮಾಲೀಕ ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ವಿನಾಯಿತಿ ಇರುತ್ತದೆ. ಕೈಯಿಂದ ಮರುಪ್ರಾರಂಭವನ್ನು ಮಾತ್ರ ತಾಳಿಕೊಳ್ಳುವ ಟನೆಲ್ಗೆ ಎರಡೂ ಇಲ್ಲ, ಮತ್ತು ನೀವು ನಿಗದಿಪಡಿಸಲಾಗದ ಮುಂದಿನ ಘಟನೆಯಲ್ಲಿ ಅದು ವಿಫಲವಾಗುತ್ತದೆ.