UFW ನ before.rules ನಲ್ಲಿ VPN NAT ಎಲ್ಲಿದೆ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಪರೀಕ್ಷಿಸುವುದು

ಶೆಲ್‌ನಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದಾಗ ಕೆಲಸ ಮಾಡುವ NAT ನಿಯಮವು before.rules ಗೆ ಅಂಟಿಸಿದಾಗ ವಿಫಲವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಆ ಫೈಲ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅಲ್ಲ. ಅದು ಟೇಬಲ್ ವಿಭಾಗಗಳು, ಚೈನ್ ಘೋಷಣೆಗಳು ಮತ್ತು ಪ್ರತಿ ಟೇಬಲ್‌ಗೆ COMMIT ಗುರುತಿನೊಂದಿಗೆ ಮರುಸ್ಥಾಪನೆ ಸ್ವರೂಪದ ದಾಖಲೆಯಾಗಿದೆ. ತಪ್ಪು ಸ್ಥಳದಲ್ಲಿರುವ ಸಾಲು ಒಟ್ಟು ಮರುಸ್ಥಾಪನೆಯನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಅಥವಾ ನೀವು ಇವೆ ಎಂದು ನಂಬಿದ್ದ ನಿಯಮಗಳನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಡುತ್ತದೆ. ಕೆಳಗಿನ ಕೈಪಿಡಿ ತುಣುಕನ್ನು ಚೌಕಟ್ಟು ನಿರೀಕ್ಷಿಸುವ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಮರುಲೋಡ್‌ಗೆ ಮೊದಲು ಫಲಿತಾಂಶವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

ಶೆಲ್ ಆಜ್ಞೆ ಮರುಸ್ಥಾಪನೆ ಫೈಲ್ ಅಲ್ಲ

iptables -t nat ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಸಾಲು iptables ಬೈನರಿಗೆ ಸೂಚನೆ, ಆದರೆ UFW ಓದುವ ಫೈಲ್ ಪೂರ್ಣ ನಿಯಮ ಸಂಗ್ರಹದ ವಿವರಣೆ. ವ್ಯತ್ಯಾಸ ಕಾಸ್ಮೆಟಿಕ್ ಅಲ್ಲ: ಮರುಸ್ಥಾಪನೆ ಸ್ವರೂಪವು ಯಾವ ಟೇಬಲ್‌ನಲ್ಲಿದೆ, ಯಾವ ಚೈನ್‌ಗಳಿವೆ ಮತ್ತು ಟೇಬಲ್ ಎಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಎಂದು ತಿಳಿಯಬೇಕು. ಆ ದಾಖಲೆಗೆ ಅಂಟಿಸಿದ ಆಜ್ಞೆ ಸಿಂಟ್ಯಾಕ್ಸ್ ದೋಷ ಅಥವಾ, ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿ, ತಪ್ಪು ಟೇಬಲ್‌ಗೆ ಜೋಡಿಸಿದ ನಿಯಮ. ಚೌಕಟ್ಟು ಈ ಫೈಲ್‌ಗಳನ್ನು ಮರುಸ್ಥಾಪನೆ ಪರಿಕರಗಳ ಮೂಲಕ ಲೋಡ್ ಮಾಡುವುದು ಅವು ಕ್ರಮಬದ್ಧವಲ್ಲ, ಘೋಷಣಾತ್ಮಕವಾಗಿರುವುದರಿಂದಲೇ.

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

ತುಣುಕನ್ನು ಇರುವ ಟೇಬಲ್ ವಿಭಾಗದ ಒಳಗೆ ಇರಿಸಿ

NAT ತುಣುಕಿಗೆ ಒಂದು ಆಕಾರವಿದೆ, ಮತ್ತು ಆಕಾರವು ಅದರೊಳಗಿನ ನಿಯಮ ಪಠ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ. ಟೇಬಲ್ ಶೀರ್ಷಿಕೆ ವಿಭಾಗವನ್ನು ತೆರೆಯುತ್ತದೆ, ಚೈನ್ ಘೋಷಣೆಗಳು ಕೌಂಟರ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತವೆ, ನಿಯಮಗಳು ಅನುಸರಿಸುತ್ತವೆ, ಮತ್ತು COMMIT ವಿಭಾಗವನ್ನು ಮುಚ್ಚುತ್ತದೆ.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

ಮೇಲಿನ ಪೂಲ್ ಮತ್ತು ಇಂಟರ್‌ಫೇಸ್ ನಿಮ್ಮ ಮೌಲ್ಯಗಳಿಗೆ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್‌ಗಳು; ನಕಲಿಸಲು ಯೋಗ್ಯವಾದ ಭಾಗ ರಚನೆ. ಫೈಲ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ *nat ವಿಭಾಗ ಇದ್ದರೆ, ಎರಡನೆಯದನ್ನು ತೆರೆಯುವ ಬದಲು ಅದೇ ವಿಭಾಗದ ಒಳಗೆ ನಿಯಮವನ್ನು ಸೇರಿಸಿ, ಏಕೆಂದರೆ ಸ್ವರೂಪವು ಪ್ರತಿ ಟೇಬಲ್‌ಗೆ ಒಂದು COMMIT ನಿರೀಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಒಂದೇ ಟೇಬಲ್‌ಗೆ ಎರಡು ವಿಭಾಗಗಳು ಸಂಭವಿಸಲು ಕಾಯುತ್ತಿರುವ ದುರಸ್ತಿ. ವಿತರಣೆಯ ಚೈನ್ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಅಕ್ಷತವಾಗಿ ಇರಿಸಿ, ಮಾರಾಟಗಾರರು ತಮ್ಮ ಸ್ವಂತ ಸಂಯೋಜನೆಗಾಗಿ ಸೇರಿಸಿದ ಯಾವುದನ್ನೂ ಒಳಗೊಂಡಂತೆ. UFW ಚೌಕಟ್ಟು ಕೈಪಿಡಿ before, user ಮತ್ತು after ಫೈಲ್‌ಗಳನ್ನು ಮತ್ತು ಹೊಂದುವ COMMIT ಅಗತ್ಯವನ್ನು ದಾಖಲಿಸುತ್ತದೆ.

ಫೈಲ್ ಖಾಲಿಯಾಗಿದ್ದರೆ, ಅದನ್ನು ಟ್ಯುಟೋರಿಯಲ್‌ನಿಂದ ತುಂಬಬೇಡಿ. ಯಾವ ಪ್ಯಾಕೇಜ್ ಅದನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಲೈವ್ ನೀತಿ ವಾಸ್ತವವಾಗಿ ಏನು ಎಂದು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಖಾಲಿ ಶಾಶ್ವತ ಫೈಲ್ ಕರ್ನೆಲ್‌ನಲ್ಲಿ ಯಾವುದೇ ನಿಯಮಗಳಿಲ್ಲ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಲೋಡ್ ಆದ ನಿಯಮ ಸಂಗ್ರಹ ಮುಂದಿನ ಮರುಲೋಡ್‌ಗೆ ಓದಲು ಪೂರ್ಣ ಫೈಲ್ ಇರುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಮೊದಲು ಬೆಂಬಲಿತ ಮೂಲರೇಖೆಯನ್ನು ಮರುಸ್ಥಾಪಿಸಿ, ನಂತರ ಅದರ ಮೇಲೆ ಸೈಟ್ ಬದಲಾವಣೆಗಳನ್ನು ಮತ್ತೆ ಅನ್ವಯಿಸಿ.

ಅಭ್ಯರ್ಥಿಯನ್ನು ಅನ್ವಯಿಸದೆ ಪರೀಕ್ಷಿಸಿ

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

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

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

ಸ್ಥಾಪಿತ ಬ್ಯಾಕೆಂಡ್ ಮತ್ತು ವಿಳಾಸ ಕುಟುಂಬಕ್ಕೆ ಹೊಂದುವ ಪರಿಕರವನ್ನು ಆರಿಸಿ. ಹೊಂದಾಣಿಕೆ ಪದರದ ಮೂಲಕ nft ಬ್ಯಾಕೆಂಡ್ ಚಲಾಯಿಸುವ ಹೋಸ್ಟ್‌ಗೆ ಅನುಗುಣವಾದ ಆಜ್ಞೆ ಬೇಕು, ಮತ್ತು IPv6 ನಿಯಮಗಳು ಸಂಪೂರ್ಣ ಬೇರೆ ಫೈಲ್‌ನಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ.

ರವಾನೆ, NAT ಮತ್ತು ಪ್ರವೇಶ ನೀತಿಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಡಿ

ಮೂಲ ಅನುವಾದವು ವಿಳಾಸ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು ಏನನ್ನೂ ನೀಡುವುದಿಲ್ಲ. ಮುಂದಕ್ಕೆ ರವಾನೆ sysctl ಮತ್ತು ಫಿಲ್ಟರ್ ಟೇಬಲ್ ನಿಯಂತ್ರಿಸುವ ಪ್ರತ್ಯೇಕ ಅನುಮತಿ, ಮತ್ತು ಸುರಂಗ ಮಾರ್ಗ ಮಾಡಿದರೂ ಸಂಚಾರವನ್ನು ಹಾದುಹೋಗದಿದ್ದಾಗ ಜನರು ಅದನ್ನೇ ಮರೆತುಬಿಡುತ್ತಾರೆ. ಪ್ರವೇಶ ನೀತಿ ಯಾವ ಮೂಲಗಳು ಯಾವ ಸೇವೆಗಳನ್ನು ತಲುಪಬಹುದು ಎಂಬ ಮೂರನೇ ನಿರ್ಧಾರ, ಮತ್ತು ಯಾವುದೇ NAT ನಿಯಮ ಅದನ್ನು ವ್ಯಕ್ತಪಡಿಸುವುದಿಲ್ಲ. ಈ ಮೂರನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುವುದೇ ವೈಫಲ್ಯವನ್ನು ಒಂದು ಅಸ್ಪಷ್ಟ ಲಕ್ಷಣದ ಬದಲು ನಿರ್ಣಯಿಸಬಲ್ಲದಾಗಿಸುತ್ತದೆ.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

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

ಮರುಲೋಡ್, ನಿರಾಕರಣೆ ಮತ್ತು VPN ನಷ್ಟವನ್ನು ಪರಿಶೀಲಿಸಿ

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

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

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

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