VPN ಗೇಟ್ವೇ ಮರುಪ್ರಾರಂಭದ ನಂತರವೂ IPv4 ಫಾರ್ವರ್ಡಿಂಗ್ ಉಳಿಯುವಂತೆ ಮಾಡಿ

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

ಗೇಟ್ವೇ ತಲುಪುವುದು ಫಾರ್ವರ್ಡಿಂಗ್ಗೆ ಸಮಾನವಲ್ಲ

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

ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೆಟ್ ಯಾವ ಇಂಟರ್ಫೇಸ್ಗೆ ಬರುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ದಾರಿ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಡುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ. ಎರಡೂ ಒಂದೇ ನೆಮ್ಸ್ಪೇಸ್ಗೆ ಸೇರಿವೆ, ಮತ್ತು ಮುಖ್ಯವಾದ ಸೆಟ್ಟಿಂಗ್ ಆ ನೆಮ್ಸ್ಪೇಸ್ನಲ್ಲಿದೆ.

ಪ್ಯಾಕೆಟ್ಗಳು ನಿಜವಾಗಿ ಇರುವಲ್ಲಿಯೇ ಮೌಲ್ಯವನ್ನು ಓದಿ

ಹೋಸ್ಟ್ ನೆಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ ರೂಟ್ ಮಾಡುವ ಗೇಟ್ವೇಯಲ್ಲಿ, ಒಂದು ಆಜ್ಞೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: sysctl net.ipv4.ip_forward. ಒಳಬರುವ ಮತ್ತು ಮುಂದಿನ ದಾರಿಗಳು ಹೆಸರಿಸಿದ ನೆಮ್ಸ್ಪೇಸ್ನಲ್ಲಿದ್ದರೆ, ಆ ನೆಮ್ಸ್ಪೇಸ್ ಅನ್ನು ಕೇಳಿ: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. ಹೋಸ್ಟ್ ಮೌಲ್ಯವು ನೆಮ್ಸ್ಪೇಸ್ ಮೌಲ್ಯದ ಪರ್ಯಾಯವಲ್ಲ, ಮತ್ತು ಹೋಸ್ಟ್ನಲ್ಲಿ ಒಂದು ಇರುವುದು ಯಾವುದಕ್ಕೂ ಸಾಕ್ಷಿಯಲ್ಲ.

ಪ್ರತಿ ರೂಟಿಂಗ್ ಸಂದರ್ಭಕ್ಕೂ ip netns ಗೆ ನೀಡಬಹುದಾದ ಲೇಬಲ್ ಇರುವುದಿಲ್ಲ. ಕಂಟೇನರ್ ರನ್ಟೈಮ್ಗಳು ಮತ್ತು ಸೇವೆಗಳು ಸ್ನೇಹಪರ ಹೆಸರಿನಲ್ಲಿ ಎಂದಿಗೂ ನೋಂದಣಿಯಾಗದ ನೆಮ್ಸ್ಪೇಸ್ಗಳನ್ನು ರಚಿಸುತ್ತವೆ, ಮತ್ತು ಅವಕ್ಕೆ ನೀವು ರನ್ಟೈಮ್ನ ಪರಿಶೀಲನಾ ಪರಿಕರಗಳನ್ನು ಬಳಸುತ್ತೀರಿ. vpn-gw ಬದಲಿಗೆ ನಿಜವಾದ ಹೆಸರನ್ನು ಅಥವಾ ಅದೇ ಸಂದರ್ಭವನ್ನು ತಲುಪುವ ರನ್ಟೈಮ್ ಕ್ರಿಯಾವಿಧಿಯನ್ನು ಹಾಕಿ, ಮತ್ತು ಹೋಸ್ಟ್ ಮಟ್ಟದಲ್ಲಿ ಊಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ.

ಸೆಟ್ಟಿಂಗ್ಗೆ ಒಬ್ಬನೇ ಮಾಲೀಕರನ್ನು ನೀಡಿ

ಸಾಂಪ್ರದಾಯಿಕ systemd ಹೋಸ್ಟ್ ಗೇಟ್ವೇಯಲ್ಲಿ, ಶಾಶ್ವತ ರೂಪವೆಂದರೆ ನಿರ್ವಾಹಕರು ಆಯ್ಕೆ ಮಾಡಿದ ಹೆಸರಿನ drop-in ಫೈಲ್, ಉದಾಹರಣೆಗೆ /etc/sysctl.d/60-vpn-forwarding.conf, ಅದರಲ್ಲಿ net.ipv4.ip_forward = 1 ಇರುತ್ತದೆ. ಫೈಲ್ ಬರೆಯಿರಿ, ನಂತರ ಜೀವಂತ ಸ್ಥಿತಿಯೂ ಬದಲಾಗುವಂತೆ ಅದೇ ನಿರ್ದಿಷ್ಟ ಫೈಲ್ ಲೋಡ್ ಮಾಡಿ: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, ನಂತರ ಮತ್ತೆ ಓದಿ ಪರಿಶೀಲಿಸಿ. ಫೈಲ್ನ ಹೆಸರು ಉದಾಹರಣೆ, ಕಾಯ್ದಿರಿಸಿದ VPN ಮಾರ್ಗವಲ್ಲ, ಮತ್ತು ಮುಂಚಿನ ಸಂಖ್ಯೆ ಮುಖ್ಯ ಏಕೆಂದರೆ ನಂತರ ವಿಂಗಡಿಸಲಾದ ಫೈಲ್ಗಳು ಗೆಲ್ಲುತ್ತವೆ.

ಆದ್ಯತೆ ಎಂಬುದು ಶಾಶ್ವತತೆ ಮೌನವಾಗಿ ಮುರಿಯುವ ಸ್ಥಳ. ವಿತರಣೆಯ ಲೋಡರ್ ಜೊತೆಗೆ ನಿಮ್ಮ drop-in ಅನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ procps sysctl --system ಕೊನೆಯಲ್ಲಿ /etc/sysctl.conf ಅನ್ನೂ ಓದುತ್ತದೆ, ಆದರೆ systemd ನ sysctl.d ಕ್ರಮ ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ಅನುಕ್ರಮ. ನಂತರದ ನಿಯೋಜನೆ ಅದೇ ಕೀಲಿಯನ್ನು ತಕ್ಷಣ ಹಿಂತಿರುಗಿಸಬಹುದು, ನಿಮ್ಮ ಫೈಲ್ ಸರಿಯಾಗಿದ್ದರೂ ಪರಿಣಾಮಕಾರಿ ಮೌಲ್ಯ ತಪ್ಪಾಗಿರುತ್ತದೆ. ಆ ವಾದವನ್ನು ಗೆಲ್ಲಲು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನಿರ್ವಾಹಕ ಫೈಲ್ ಅನ್ನು ಮೇಲೆ ಬರೆಯಬೇಡಿ; ಮಾಲೀಕರನ್ನು ಹುಡುಕಿ ಅಲ್ಲಿಯೇ ಬದಲಿಸಿ.

ಬೂಟ್ ನಂತರ ರಚಿಸಿದ ನೆಮ್ಸ್ಪೇಸ್ ಅನ್ನು ಹೋಸ್ಟ್ drop-in ನಿಯಂತ್ರಿಸುವುದೇ ಇಲ್ಲ. ಅದರ ಸೆಟ್ಟಿಂಗ್ ಅದನ್ನು ರಚಿಸುವುದಕ್ಕೆ ಸೇರಿದೆ, ಅದು ಕಂಟೇನರ್ ರನ್ಟೈಮ್ ಆಗಿರಲಿ ಅಥವಾ ನೆಮ್ಸ್ಪೇಸ್ನ ಒದಗಿಸುವಿಕೆ ಘಟಕವಾಗಿರಲಿ. ಪ್ರಶ್ನೆಯನ್ನು ತಪ್ಪಿಸಲು ಕಂಟೇನರ್ಗೆ ವಿಶಾಲ ಹೋಸ್ಟ್ ಸವಲತ್ತುಗಳನ್ನು ನೀಡುವುದು ಸರಿಯಾದ ಮಾಲೀಕರನ್ನು ಗುರುತಿಸಲು ಹತ್ತು ನಿಮಿಷ ಕಳೆಯುವುದಕ್ಕಿಂತ ಕೆಟ್ಟ ವ್ಯವಹಾರ.

ಸ್ವಿಚ್ ತಿರುಗಿಸುವ ಮೊದಲು ಅದರ ಬೆಲೆ ಏನೆಂದು ತಿಳಿಯಿರಿ

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

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

ಶಾಶ್ವತತೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿ, ನಂತರ ಮಾರ್ಗದ ಉಳಿದ ಭಾಗವನ್ನು ಪರೀಕ್ಷಿಸಿ

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

ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯವಾಗಿದ್ದರೂ ಮೂರು ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು. ಕ್ಲೈಂಟ್ಗೆ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಮಾರ್ಗ ಬೇಕು, ಗೇಟ್ವೇಗೆ ಮುಂದಿನ ಮಾರ್ಗ ಮತ್ತು ಅದನ್ನು ಬಳಸುವ ಅನುಮತಿ ಬೇಕು, ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಕ್ಲೈಂಟ್ನ ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಮರಳುವ ದಾರಿ ಬೇಕು. ಖಾಸಗಿ ರೂಟ್ ಮಾಡಿದ LAN ಗೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ NAT ಬೇಕಿಲ್ಲ, ಆದ್ದರಿಂದ ಮೂರರಲ್ಲಿ ಯಾವುದು ಕಾಣೆಯಾಗಿದೆ ಎಂದು ತಿಳಿಯುವ ಮೊದಲು masquerading ಸೇರಿಸಬೇಡಿ, ಮತ್ತು ಗೇಟ್ವೇಯಿಂದಲ್ಲ, ಉದ್ದೇಶಿತ ಕ್ಲೈಂಟ್ನಿಂದ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಗೇಟ್ವೇಯಲ್ಲಿ ಹುಟ್ಟಿದ ವಿನಂತಿ ನೀವು ಈಗ ಸಕ್ರಿಯಗೊಳಿಸಿದ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗವನ್ನು ಎಂದಿಗೂ ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ. IPv6 ತನ್ನದೇ ಆದ ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ರೂಟಿಂಗ್ ನೀತಿಯನ್ನು ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ IPv4 ಪರೀಕ್ಷೆ ಅದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

drop-in ಮಾರ್ಗ, ನೆಮ್ಸ್ಪೇಸ್ನ ಮಾಲೀಕ ಮತ್ತು ಮತ್ತೆ ಓದುವ ಆಜ್ಞೆಯನ್ನು runbook ನಲ್ಲಿ ಒಟ್ಟಿಗೆ ಇರಿಸಿ. ಮುಂದೆ ಇದನ್ನು ತೆಗೆದುಕೊಳ್ಳುವವರು ಮೌಲ್ಯವನ್ನು ಓದಲು, ಅದರ ಮಾಲೀಕರು ಯಾರೆಂದು ನೋಡಲು, ಮತ್ತು ಸಮಸ್ಯೆ ಶಾಶ್ವತತೆಯದೋ ಅಥವಾ ಮಾರ್ಗದ ಉಳಿದ ಭಾಗದದೋ ಎಂದು ಒಂದು ನಿಮಿಷದಲ್ಲಿ ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಾಗಬೇಕು.