net.ipv4.conf.default.forwarding tun0 ಅನ್ನು ಏಕೆ ಹಾಗೆಯೇ ಬಿಡುತ್ತದೆ

ನೀವು net.ipv4.conf.default.forwarding=1 ಅನ್ನು ಸೆಟ್ ಮಾಡಿದ್ದೀರಿ, VPN ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದ್ದೀರಿ, ಆದರೂ ಟನೆಲ್ ಇನ್ನೂ ಗೇಟ್‌ವೇ ರೂಟ್ ಮಾಡಬೇಕಾದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಬೀಳಿಸುತ್ತಿದೆ. ಫೈಲ್‌ನಲ್ಲಿ ಸೆಟ್ಟಿಂಗ್ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಇನ್ನೂ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಷ್ಕ್ರಿಯ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ಏನೂ ಮುರಿದಿಲ್ಲ: ನೀವು ಭವಿಷ್ಯದ ಇಂಟರ್ಫೇಸ್‌ಗಳು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುವ ಮೌಲ್ಯವನ್ನು ಬದಲಿಸಿದ್ದೀರಿ, ಜೀವಂತ ಟನೆಲ್ ಬಳಸುವ ಮೌಲ್ಯವನ್ನಲ್ಲ.

ಟನೆಲ್ ಅನ್ನು ಹೊಂದಿರುವ ಹೋಸ್ಟ್‌ನಲ್ಲಿ, ಟನೆಲ್ ನಿಜವಾಗಿ ಇರುವ ನೆಟ್‌ವರ್ಕ್ namespace ನಲ್ಲಿ ಇದನ್ನು ನೋಡಿ. ಕಂಟೇನರ್ ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ namespace ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಹುದು, ಆದರೆ ಹೋಸ್ಟ್ ಬೇರೆ ಸಂಖ್ಯೆಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.

ಮೂರು ಮೌಲ್ಯಗಳನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ

ಗೇಟ್‌ವೇ-ವ್ಯಾಪಿ ಸ್ವಿಚ್, ಹೊಸ ಇಂಟರ್ಫೇಸ್‌ಗಳಿಗೆ ಟೆಂಪ್ಲೇಟ್ ಮತ್ತು ನಿಮಗೆ ಮುಖ್ಯವಾದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೋಲಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ. tun0 ಬದಲಿಗೆ ನಿಜವಾದ ಒಳಬರುವ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಇರಿಸಿ, ಮತ್ತು ಹಿಂತಿರುಗುವ ಇಂಟರ್ಫೇಸ್ ಅನ್ನೂ ಓದಿ, ಏಕೆಂದರೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಪ್ಯಾಕೆಟ್ ಬರುವ ಬಿಂದುವಿನಲ್ಲೇ ಮೌಲ್ಯಮಾಪನವಾಗುತ್ತದೆ.

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

ಸಾಮಾನ್ಯ ಫಲಿತಾಂಶ ip_forward = 0, default.forwarding = 1 ಮತ್ತು tun0.forwarding = 0. ಮೊದಲ ಎರಡು ಹೋಸ್ಟ್‌ನ ಪಾತ್ರದ ಬಗ್ಗೆ ಒಪ್ಪುವುದಿಲ್ಲ, ಮತ್ತು ಮೂರನೆಯದು ಇಂಟರ್ಫೇಸ್ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಈ ಸಂಯೋಜನೆಯು ಎಂದೂ ರೂಟರ್ ಆಗಿ ಕಾನ್ಫಿಗರ್ ಆಗದ, ಕೇವಲ ಟೆಂಪ್ಲೇಟ್ ಮೌಲ್ಯ ಪಡೆದ ಹೋಸ್ಟ್‌ಗೆ ಹೊಂದುತ್ತದೆ. ಮೂರು ಸಂಖ್ಯೆಗಳು ಪರಸ್ಪರ ವಿರುದ್ಧವಲ್ಲ; ಅವು ಮೂರು ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ. ಟೆಂಪ್ಲೇಟ್ ಮೌಲ್ಯವನ್ನು ಬರೆಯುವುದೂ ಹೋಸ್ಟ್‌ನ ಪಾತ್ರವನ್ನು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ.

ಏಕೆ ಜಾಗತಿಕ ಸ್ವಿಚ್‌ನೇ ಚಲಿಸುತ್ತದೆ

net.ipv4.ip_forward ಗೇಟ್‌ವೇ-ವ್ಯಾಪಿ ನಿಯಂತ್ರಣವಾಗಿದೆ. ಅದನ್ನು ಬದಲಿಸುವುದು ಅದೇ ಕ್ರಿಯೆಯ ಭಾಗವಾಗಿ ಪ್ರತಿ-ಇಂಟರ್ಫೇಸ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ನವೀಕರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದೇ ಬರವಣಿಗೆ ಇರುವ ಟನೆಲ್ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಬಹುದು. default.forwarding ನಂತರ ಆರಂಭವಾಗುವ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಮಾತ್ರ ಬಿತ್ತುತ್ತದೆ, ಆದ್ದರಿಂದ ಈಗಾಗಲೇ ಇದ್ದ ಟನೆಲ್ ಹುಟ್ಟಿದ ಮೌಲ್ಯವನ್ನೇ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.

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

ಪ್ರತಿ-ಇಂಟರ್ಫೇಸ್ ಮೌಲ್ಯಗಳೂ ಒಂದು ಕಾರಣಕ್ಕಾಗಿ ಇವೆ. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ವಹಿಸಲಾದ ಗೇಟ್‌ವೇ ಎಂದೂ ರೂಟ್ ಮಾಡಬಾರದ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಫಾರ್ವರ್ಡಿಂಗ್ ಆಫ್ ಆಗಿ ಇರಿಸಬಹುದು, ಹೋಸ್ಟ್ ಬೇರೆಡೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತಿದ್ದರೂ ಸಹ. ಆದ್ದರಿಂದಲೇ ಜೀವಂತ ಇಂಟರ್ಫೇಸ್ ಓದುವುದು ಮುಖ್ಯ ಮತ್ತು ಆದ್ದರಿಂದಲೇ ಕೇವಲ ಜಾಗತಿಕ ಮೌಲ್ಯವೇ ಪೂರ್ಣ ಉತ್ತರವಲ್ಲ. ಅಂತಹ ಅಪವಾದವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕ ನಿರ್ಧಾರ ಎಂದು ಓದಿ, ಮತ್ತು ಆ ಇಂಟರ್ಫೇಸ್ ಏಕೆ ಬೇರೆ ಎಂದು ಬರೆಯಿರಿ. ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ಸಹಾಯ ಮಾಡುವ ಉದ್ದೇಶದಿಂದ ಅದನ್ನು "ಸರಿಪಡಿಸುತ್ತಾರೆ".

ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿ ಶಾಶ್ವತಗೊಳಿಸಿ

ಒಂದು ಯಶಸ್ವಿ ಒಂದು-ಬಾರಿಯ sysctl -w ಕರ್ನಲ್ ಮೌಲ್ಯವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಅದು ರೀಬೂಟ್ ನಂತರ ಉಳಿಯುವುದಿಲ್ಲ, ಮತ್ತು ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವಾಗ ಇಂಟರ್ಫೇಸ್ ಕಾನ್ಫಿಗರೇಶನ್ ಬಗ್ಗೆ ತನ್ನದೇ ಕಲ್ಪನೆಯನ್ನು ಮತ್ತೆ ಅನ್ವಯಿಸುವ ನೆಟ್‌ವರ್ಕ್ ಮ್ಯಾನೇಜರ್ ನಂತರವೂ ಉಳಿಯುವುದಿಲ್ಲ. ಗೇಟ್‌ವೇ ಪಾತ್ರವನ್ನು sysctl ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ನಲ್ಲಿ ಅಥವಾ ಹೋಸ್ಟ್ ಅನ್ನು ಹೊಂದಿರುವ ನೆಟ್‌ವರ್ಕ್ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿ ಇರಿಸಿ, ನಂತರ ಅದನ್ನು ಅನ್ವಯಿಸುವ ಸೇವೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ.

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

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

ತಪ್ಪು ಸಾಧನದಿಂದ ಇದನ್ನು ಸರಿಪಡಿಸಬೇಡಿ

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

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

IPv6 ಪ್ರಕರಣವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿರಿಸಿ

ಇಲ್ಲಿ ಎಲ್ಲವೂ IPv4. IPv6 ಫಾರ್ವರ್ಡಿಂಗ್, ರೂಟರ್ ಘೋಷಣೆಗಳು ಮತ್ತು accept_ra ವರ್ತನೆಗೆ ತಮ್ಮದೇ ನಿಯಂತ್ರಣಗಳಿವೆ, ಮತ್ತು ipv4 ಮಾರ್ಗವನ್ನು ipv6 ಸೆಟ್ಟಿಂಗ್‌ಗೆ ನಕಲಿಸುವುದು ನಂಬಲರ್ಹವಾಗಿ ಕಾಣುವ ಆದರೆ ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಮಾಡದ ಫೈಲ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ದ್ವಂದ್ವ-ಸ್ಟ್ಯಾಕ್ ಗೇಟ್‌ವೇ ಎರಡೂ ಸೆಟ್‌ಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು.

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