tun0 ಇಲ್ಲವೇ? nftables ನಲ್ಲಿ ಡಿಕ್ರಿಪ್ಟ್ ಆದ IPsec ಅನ್ನು meta ipsec ನೊಂದಿಗೆ ಹೊಂದಿಸಿ

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

ಒಳ ವಿನಂತಿ ಇನ್ನೂ ತನ್ನದೇ ಮೂಲ, ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಸೇವೆಯನ್ನು ಹೊಂದಿರುವ ಪ್ರತ್ಯೇಕ ಪ್ಯಾಕೆಟ್, ಮತ್ತು ಕರ್ನಲ್ಗೆ ಅದು ಯಾವ ಭದ್ರತಾ ಸಂಘದಿಂದ ಹೊರಬಂತು ಎಂದು ತಿಳಿದಿದೆ. ಈ ಜ್ಞಾನವನ್ನೇ ಫೈರ್ವಾಲ್ ನಿಯಮ ಹೊಂದಿಸಬಲ್ಲದು.

ಎರಡು ಪ್ಯಾಕೆಟ್, ಒಂದು ಇಂಟರ್ಫೇಸ್

ಒಳಬರುವ ದಿಕ್ಕನ್ನು ಊಹಿಸಿ. ESP ಅಥವಾ UDP ನಲ್ಲಿ ಸುತ್ತಿದ ಪ್ಯಾಕೆಟ್ ಬರುತ್ತದೆ, ಕರ್ನಲ್ ಹೊಂದಿಕೆಯಾಗುವ ನೀತಿಯನ್ನು ಕಂಡುಕೊಂಡು ಡಿಕ್ರಿಪ್ಟ್ ಮಾಡಿ ಸ್ಪಷ್ಟ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ರವಾನೆ ಮಾರ್ಗಕ್ಕೆ ಕೊಡುತ್ತದೆ. ಇಂಟರ್ಫೇಸ್ ಹೆಸರನ್ನು ಮಾತ್ರ ನೋಡುವ ನಿಯಮವು ಆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅದೇ ತಂತಿಯಲ್ಲಿ ಬರುವ ಬೇರೆ ಯಾವುದೇ ಸಂಚಾರದಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾರದು.

ಅದನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ಪ್ಯಾಕೆಟ್ಗೆ ಜೋಡಿಸಿದ ಒಳಬರುವ ಭದ್ರತಾ ಮಾರ್ಗದ ಸಂದರ್ಭ. nftables ಅದನ್ನು meta ipsec exists ಎಂದು ತೋರಿಸುತ್ತದೆ, ಪ್ಯಾಕೆಟ್ IPsec ಭದ್ರತಾ ಮಾರ್ಗದ ಮೂಲಕ ಬಂದಾಗ ಇದು ನಿಜ. ಅದನ್ನು ಕ್ಲೈಂಟ್ ಪೂಲ್, ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಸೇವೆಯೊಂದಿಗೆ ಸೇರಿಸಿ, ನಿಯಮ ಸುರಕ್ಷಿತವಾಗಲು ಸಾಕಷ್ಟು ನಿರ್ದಿಷ್ಟವಾಗುತ್ತದೆ.

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

ರವಾನೆ ನಿಯಮ ಬರೆಯಿರಿ

10.90.0.0/24 ನಲ್ಲಿ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಹೊಂದಿರುವ ದೃಢೀಕೃತ IPv4 ದೂರಸ್ಥ ಪ್ರವೇಶ ಸೇವೆ ಮತ್ತು 203.0.113.40 ನಲ್ಲಿ ಒಂದು ಅನುಮೋದಿತ ಗಮ್ಯಸ್ಥಾನ ಇದೆ ಎಂದು ಭಾವಿಸಿ. ಆ ಹರಿವಿಗೆ ನಿಯಮದ ತುಣುಕು ಹೀಗಿದೆ.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

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

ಹೊರ ವಿನಿಮಯದ ಅನುಮತಿಗಳು ಪ್ರತ್ಯೇಕ. ಗೇಟ್ವೇನ ಒಳಮುಖ ಮಾರ್ಗಕ್ಕೆ ಅದು ನಿಜವಾಗಿ ಬಳಸುವ IKE ಮತ್ತು ESP ಅಥವಾ UDP ಸುತ್ತುವ ಪೋರ್ಟ್ಗಳು ಬೇಕು, ಮತ್ತು ಆ ಅನುಮತಿಗಳು ಒಳಗಿನ ಡಿಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಅನುಮೋದಿಸುವುದಿಲ್ಲ. ಎರಡನ್ನೂ ಬೆರೆಸುವುದು ಕೆಲಸ ಮಾಡುವ ಟನಲ್ ಎಲ್ಲವನ್ನೂ ರವಾನಿಸುವ ಫೈರ್ವಾಲ್ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವ ದಾರಿ.

ಒಳಬರುವ ಸಂದರ್ಭ ಹೊರಹೋಗುವ ಸಂದರ್ಭವಲ್ಲ

ಅದೇ ಅಭಿವ್ಯಕ್ತಿ ಕುಟುಂಬವು ಇನ್ನೊಂದು ದಿಕ್ಕನ್ನು rt ipsec ನಿಂದ ಆವರಿಸುತ್ತದೆ, ಅದು ಪ್ಯಾಕೆಟ್ ಬಳಸಲಿರುವ ಹೊರಹೋಗುವ ಭದ್ರತಾ ಸಂಘವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅದು ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಈ ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಂದ ಬಂತು ಎಂಬುದಲ್ಲ, ಬದಲಿಗೆ ಮುಂದಿನ ಹಂತದಲ್ಲಿ ಅದು ಸಂರಕ್ಷಿತವಾಗುತ್ತದೆಯೇ ಎಂಬುದು.

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

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

NAT ಫೈರ್ವಾಲ್ ನಿರ್ಧಾರವಲ್ಲ

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

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

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

ನಿಖರ ಒಳ ಸೇವೆಯನ್ನು ಪರಿಶೀಲಿಸಿ

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

nftables ಉಲ್ಲೇಖ meta ipsec, rt ipsec ಮತ್ತು ದಿಕ್ಕಿಗೆ ನಿರ್ದಿಷ್ಟ ಅಭಿವ್ಯಕ್ತಿಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ನೀವು ಸ್ಥಾಪಿಸಿದ ಆವೃತ್ತಿಯೊಂದಿಗೆ ವಾಕ್ಯರಚನೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ಸ್ಥಳ ಅದೇ. ಮತ್ತು ವ್ಯಾಪ್ತಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಇರಿಸಿ: ಇದು IPv4 ಉದಾಹರಣೆ, ಇದು IPv6 ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಅನಿಯಂತ್ರಿತ ಸಾರ್ವಜನಿಕ ಪೋರ್ಟ್ ರವಾನೆಯನ್ನು VPN ಸೇವೆಯ ಭಾಗವಾಗಿಸುವುದಿಲ್ಲ.