OpenBSD VPN ಗೇಟ್‌ವೇಯಲ್ಲಿ tun0 ಮೂಲಕ LAN ಗೆ NAT

ಒಂದೇ OpenBSD ಗೇಟ್‌ವೇ ಹೊಂದಿರುವ ಇಬ್ಬರು ಎಂಜಿನಿಯರ್‌ಗಳು ದೂರದ ನೆಟ್‌ವರ್ಕ್ ತಲುಪಲು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ಬೇರೆ ನಿಯಮ ಸಂಗ್ರಹಗಳನ್ನು ನೀಡುತ್ತಾರೆ, ಮತ್ತು ಎರಡನ್ನೂ ಸಮರ್ಥಿಸಬಹುದು. ಮೂಲ ಅನುವಾದ ಮತ್ತು ಮರಳು ಮಾರ್ಗದ ನಡುವಿನ ಆಯ್ಕೆ ಸಂಪೂರ್ಣವಾಗಿ ವಾಕ್ಯರಚನೆಯ ಪ್ರಶ್ನೆಯಲ್ಲ. ಅದು ದೂರದ ಬದಿ 192.168.88.0/24 ಬಗ್ಗೆ ಈಗಾಗಲೇ ಏನು ತಿಳಿದಿದೆ ಮತ್ತು ನೀವು ನಿಮ್ಮ ಲಾಗ್‌ಗಳಲ್ಲಿ ಏನನ್ನು ಇಟ್ಟುಕೊಳ್ಳಬೇಕು ಎಂಬುದರ ಮೇಲೆ ನಿಂತಿದೆ. ಇಲ್ಲಿ ತಪ್ಪಾದರೆ nat-to ಸಾಲು ಪರಿಪೂರ್ಣವಾಗಿ ಸರಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಉತ್ತರಗಳು ದೂರದ ಪೂರ್ವನಿಗದಿ ಗೇಟ್‌ವೇಯಲ್ಲಿ ಮಾಯವಾಗುತ್ತವೆ.

ಮಾರ್ಗನಿರ್ದೇಶನ ಮತ್ತು ಮರುಬರವಣಿಗೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ

ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕವು 172.20.0.0/16 tun0 ಮೂಲಕ ತಲುಪಬಹುದು ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ನಿರ್ಧಾರ ಯಾವುದೇ pf ಅನುವಾದವನ್ನು ಸಂಪರ್ಕಿಸುವ ಮೊದಲೇ ಆಗುತ್ತದೆ. ನಂತರ ಮೂಲ ಅನುವಾದವು ಪ್ಯಾಕೆಟ್ ಶೀರ್ಷಿಕೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ದೂರದ ತುದಿ LAN ಹೋಸ್ಟ್ ಬದಲು ಗೇಟ್‌ವೇಯ ಸುರಂಗ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ. ಎರಡೂ ಕಾರ್ಯವಿಧಾನಗಳು ಒಂದರ ಸ್ಥಾನವನ್ನು ಇನ್ನೊಂದು ತುಂಬುವುದಿಲ್ಲ: nat ನಿಯಮ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸಲಾರದು, ಮತ್ತು ಮಾರ್ಗವು ನಿಮ್ಮ ಖಾಸಗಿ ಉಪಜಾಲವನ್ನು ಎಂದೂ ಕೇಳದ ದೂರದ ರೌಟರ್‌ನ್ನು ಒಪ್ಪಿಸಲಾರದು. ದೂರದ ಬದಿಗೆ ಮರಳು ದಾರಿ ಇಲ್ಲದಿದ್ದರೆ ಉತ್ತರಗಳು ಬಿಸಾಡಲ್ಪಡುತ್ತವೆ ಅಥವಾ ಅದರ ಪೂರ್ವನಿಗದಿ ಗೇಟ್‌ವೇಗೆ ರವಾನೆಯಾಗುತ್ತವೆ, ಮತ್ತು ನಿಯಮಗಳನ್ನು ಎಷ್ಟೇ ಸರಿಹೊಂದಿಸಿದರೂ ಅದು ಸರಿಯಾಗದು.

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

ನಿರ್ಧರಿಸುವ ಮೂರು ಷರತ್ತುಗಳು

ಮೂರು ಪ್ರಶ್ನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಕೇಳಿ, ವಿನ್ಯಾಸ ಸಾಮಾನ್ಯವಾಗಿ ತಾನೇ ಆಯ್ಕೆಯಾಗುತ್ತದೆ. ದೂರದ ಜಾಲಕ್ಕೆ 192.168.88.0/24 ಗಾಗಿ ಸುರಂಗ ವಿಳಾಸದ ಕಡೆ ತೋರಿಸುವ ಸ್ಥಿರ ಮಾರ್ಗ ಇದೆಯೇ, ಅಥವಾ ಅದರ ನಿರ್ವಾಹಕರು ಆ ದಾರಿಯ ರೌಟರ್‌ಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತಾರೆಯೇ? ಹೌದಾದರೆ LAN ವಿಳಾಸಗಳನ್ನು ಬದಲಾಗದೆ ಹೋಗಲು ಬಿಡಿ ಮತ್ತು ಅನುವಾದವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಟ್ಟುಬಿಡಿ. ದೂರದ ಬದಿಯಲ್ಲಿ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಗೋಚರತೆ ಬೇಕೇ, ಪ್ರವೇಶ ನೀತಿಗಾಗಿ ಅಥವಾ ಲೆಕ್ಕ ಪರಿಶೋಧನಾ ಜಾಡಿಗಾಗಿ? ಬೇಕಾದರೆ ಮೂಲವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದು ಮಾರ್ಗನಿರ್ದೇಶನದ ಶ್ರಮಕ್ಕೆ ಯೋಗ್ಯ. ಸುರಂಗ ವಿಳಾಸವು ದೂರದ ಮಾರ್ಗದಲ್ಲಿ ಬರೆಯಲು ಸಾಕಷ್ಟು ಸ್ಥಿರವಾಗಿದೆಯೇ, ಅಥವಾ ಮರುಸಂಪರ್ಕಗಳ ನಡುವೆ ಬದಲಾಗುತ್ತದೆಯೇ?

ಯಾವುದೇ ಉತ್ತರ ಇಲ್ಲ ಅಥವಾ ಅಜ್ಞಾತವಾಗಿದ್ದರೆ nat-to ಪ್ರಾಯೋಗಿಕ ಆಯ್ಕೆ, ಮತ್ತು ಅದನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು. ದೂರದ ಬದಿ ಸರಿಯಾದ ಮಾರ್ಗವನ್ನು ಸೇರಿಸಿದ ಕ್ಷಣ ಅನುವಾದ ನಿಯಮ ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಎಂದೂ ಸ್ಥಾಪಿಸದ ಮರಳು ಮಾರ್ಗವು ಸುರಂಗ ಒಂದೇ ದಿಕ್ಕಿನಲ್ಲಿ ಏಕೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಯಾರಾದರೂ ಕೇಳಿದಾಗಲೆಲ್ಲ ಒಂದು ಬೆಂಬಲ ಎಳೆಯನ್ನು ತಿನ್ನುತ್ತದೆ.

pf ನಿಜವಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವಂತೆ ತುಣುಕನ್ನು ಇರಿಸಿ

ಕೆಳಗಿನ ತುಣುಕು LAN 192.168.88.0/24, ದೂರದ ಜಾಲ 172.20.0.0/16 ಮತ್ತು ಸುರಂಗ ಇಂಟರ್‌ಫೇಸ್ tun0 ಎಂದು ಊಹಿಸುತ್ತದೆ. ಅದರಲ್ಲಿ ಮುಂದಿನ ಹೆಜ್ಜೆಯನ್ನು ಆಯ್ಕೆಮಾಡುವ ಯಾವುದೂ ಇಲ್ಲ. ಈಗಾಗಲೇ ಸುರಂಗದ ಮೂಲಕ ಹೊರಹೋಗುತ್ತಿರುವ ಪ್ಯಾಕೆಟ್‌ಗಳ ಮೂಲವನ್ನು ಮಾತ್ರ ಅದು ಮರುಬರೆಯುತ್ತದೆ.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

ಆ ಮೊದಲ ಸಾಲಿನ ಎರಡು ವಿವರಗಳು ಹೆಚ್ಚಿನ ಭಾರವನ್ನು ಹೊರುತ್ತವೆ. tun0 ಸುತ್ತಲಿನ ಆವರಣಗಳು ಸ್ಥಿತಿ ನಮೂದನ್ನು ನಿರ್ಮಿಸುವ ಪ್ರತಿ ಬಾರಿಯೂ ಇಂಟರ್‌ಫೇಸ್ ವಿಳಾಸವನ್ನು ಓದಲು pf ಗೆ ಹೇಳುತ್ತವೆ, ಮರುಸಂಪರ್ಕದ ನಂತರ ಸುರಂಗ ಮರುಸಂಖ್ಯೆಯಾದಾಗ ಇದು ಮುಖ್ಯ. match ಪದ ಎಂದರೆ ನಿಯಮವು ಮರುಬರೆದು ನಂತರ ಕೆಳಗೆ ಬೀಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತ್ಯೇಕ pass ನಿಯಮವು ಇನ್ನೂ ಹರಿವನ್ನು ಅನುಮತಿಸಬೇಕು. match ಸಾಲಿನಲ್ಲಿ ಹೆಸರಿಸಿದ ಇಂಟರ್‌ಫೇಸ್ ಕೂಡ ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕ ಆಯ್ಕೆಮಾಡುವುದೇ ಆಗಿರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ pf ಪ್ಯಾಕೆಟ್ ನಿಜವಾಗಿ ಹೋಗುವ ದಾರಿಗಿಂತ ಬೇರೆ ಹೊರಹೋಗುವ ದಾರಿಯಲ್ಲಿ ನಿಯಮವನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ.

ಕರ್ನಲ್ ಬದಿಯನ್ನು ಮರೆಯಬೇಡಿ. IPv4 ರವಾನೆ ಸಕ್ರಿಯವಾಗಿರಬೇಕು, ಮತ್ತು ಸುರಂಗ ಹಾಗೂ LAN ಗಾಗಿ ಸ್ಥಿತಿಯುಳ್ಳ pass ನಿಯಮಗಳು ಇರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಇದಕ್ಕೆ ಅರ್ಥವಿಲ್ಲ. ಇಲ್ಲಿ ಕೀವರ್ಡ್ ಕ್ರಮಕ್ಕೆ OpenBSD FAQ ನ PF NAT ವಿಭಾಗ ಸರಿಯಾದ ಉಲ್ಲೇಖ.

ಸಂಚಾರವನ್ನು ನಂಬುವ ಮೊದಲು ನಿಯಮ ಸಂಗ್ರಹವನ್ನು ಪರಿಶೀಲಿಸಿ

ಮೊದಲು pfctl -nf /etc/pf.conf ನಿಂದ ವಾಕ್ಯರಚನೆ ಪರೀಕ್ಷಿಸಿ, ಅದು ಕಡತವನ್ನು ಲೋಡ್ ಮಾಡದೆ ವಿಶ್ಲೇಷಿಸುತ್ತದೆ. ನಂತರ ನೀತಿಯನ್ನು ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಕರ್ನಲ್ ನಿಜವಾಗಿ ಏನನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಂಡಿದೆ ಎಂದು ಮತ್ತೆ ಓದಿ, ಏಕೆಂದರೆ ಸ್ವಚ್ಛವಾಗಿ ವಿಶ್ಲೇಷಣೆಯಾದ ನಿಯಮವೂ ಮರೆಯಾಗಿರಬಹುದು ಅಥವಾ ತಪ್ಪು ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಜೋಡಿಸಿಕೊಂಡಿರಬಹುದು. pfctl -sn ಅನುವಾದ ನಿಯಮಗಳನ್ನು ಅವು ಲೋಡ್ ಆದ ರೂಪದಲ್ಲಿ ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು pfctl -sr ಫಿಲ್ಟರ್ ನಿಯಮಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಕ್ರಮದಲ್ಲಿ ಮುದ್ರಿಸುತ್ತದೆ.

ಮುಂದೆ ತಂತಿಯನ್ನು ಗಮನಿಸಿ. ಗೇಟ್‌ವೇಯಲ್ಲಿ tcpdump -ni tun0 'host 172.20.0.10' ಸುರಂಗದಿಂದ ಹೊರಹೋಗುವ ಮೂಲ ವಿಳಾಸ ಸುರಂಗದ ವಿಳಾಸವೋ LAN ಹೋಸ್ಟ್‌ನದೋ ಎಂದು ತೋರಿಸುತ್ತದೆ. ತ್ವರಿತ netstat -rn -f inet ಗಮ್ಯವು ಯಾವ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಪರಿಹಾರವಾಗುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸುತ್ತದೆ. ಸಂಚಾರ ಹರಿಯಲು ಪ್ರಾರಂಭಿಸಿದಾಗ pfctl -ss ಸ್ಥಿತಿ ನಮೂದುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ; ಹರಿವು ಸ್ಥಿತಿಯನ್ನು ಸೃಷ್ಟಿಸದಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಸ್ಥಿತಿ ಸೃಷ್ಟಿಸುವ ನಿಯಮಕ್ಕೆ ಎಂದೂ ಸಿಕ್ಕಿಲ್ಲ.

ಸುರಂಗದ ಬದಿ ಸರಿಯಾಗಿ ಕಂಡರೂ ಉತ್ತರಗಳು ಬಾರದಿದ್ದರೆ pf ಸಂಪಾದನೆಯನ್ನು ನಿಲ್ಲಿಸಿ. ಉಳಿದ ವೈಫಲ್ಯ ದೂರದ ರೌಟರ್‌ನಲ್ಲಿದೆ, ಅಲ್ಲಿ ಉತ್ತರವು ಆ ಬದಿಗೆ ತಲುಪಲಾಗದ ಖಾಸಗಿ ವಿಳಾಸದ ಕಡೆ ಕಳುಹಿಸಲ್ಪಡುತ್ತಿದೆ.

ಅನುವಾದವು ಉಳಿತಾಯಕ್ಕಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚವಾದಾಗ

ಅನುವಾದವು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಮರೆಮಾಡುತ್ತದೆ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಅದೇ ತಪ್ಪು ವ್ಯವಹಾರ. ಒಂದರ ಮೇಲೊಂದು ಬರುವ ಉಪಜಾಲಗಳು ಒಂದು ಸಂದರ್ಭ: ದೂರದ ಬದಿಯೂ ಒಳಗೆ 192.168.88.0/24 ಬಳಸಿದರೆ, LAN ಹೋಸ್ಟ್‌ಗಳನ್ನು ಗೇಟ್‌ವೇ ಆಗಿ ತೋರಿಸುವುದು ಘರ್ಷಣೆಯನ್ನು ಸುಧಾರಿಸುವ ಬದಲು ಹದಗೆಡಿಸುತ್ತದೆ. ವಿಳಾಸ ಜೋಡಿಯಿಂದ ಸಂಚಾರವನ್ನು ಆಯ್ಕೆಮಾಡುವ IPsec ನೀತಿಗಳು ಇನ್ನೊಂದು ಸಂದರ್ಭ, ಏಕೆಂದರೆ ಭದ್ರತಾ ನೀತಿ ಡೇಟಾಬೇಸ್ ಅನುವಾದಕ್ಕೆ ಮೊದಲು ಹೋಲಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ನೀವು ಮರುಬರೆದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಎಂದೂ ನೋಡುವುದಿಲ್ಲ. ಪ್ರತಿ ಬಳಕೆದಾರನಿಗೆ ಬಿಲ್ ಮಾಡುವ, ಮಿತಿಗೊಳಿಸುವ ಅಥವಾ ಲೆಕ್ಕ ಪರಿಶೋಧಿಸುವ ಯಾವುದೇ ನಿಯೋಜನೆಯೂ ಮೂಲವು ಒಂದೇ ವಿಳಾಸಕ್ಕೆ ಕುಸಿಯುವ ಕ್ಷಣದಲ್ಲಿ ಬೇಕಾದ ಗುರುತನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.

ಸಾಗಿಸಬಹುದಾದ pf ಉತ್ಪನ್ನಗಳು ಪ್ರತ್ಯೇಕ ಬಲೆ. ತಮ್ಮದೇ ನಿಯಮ ಕಡತಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಉತ್ಪನ್ನಗಳು NAT ತಮ್ಮ ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ಸಂರಚಿಸಲ್ಪಡಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸುತ್ತವೆ, ಮತ್ತು ಕೈಯಿಂದ ಸಂಪಾದಿಸಿದ ತುಣುಕುಗಳು ಮುಂದಿನ ಮರುಲೋಡ್‌ನಲ್ಲಿ ಮೇಲೆ ಬರೆಯಲ್ಪಡುತ್ತವೆ. match ಕೀವರ್ಡ್ ಇರುವ ಮೊದಲೇ ಬರೆದ ಮಾರ್ಗದರ್ಶಿಗಳಿಂದ ನಕಲಿಸಿದ ನಿಯಮ ಸಂಗ್ರಹಗಳು ಈಗಿನ ಕರ್ನಲ್‌ನಲ್ಲಿ ಲೋಡ್ ಆಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ವಾಕ್ಯರಚನೆಯನ್ನು ಸಾಗಿಸಿ ಮತ್ತು ಊಹಿಸುವ ಬದಲು ದೋಷವನ್ನು ಓದಿ.

ನಿಜವಾದ ಜಾಲಗಳೊಂದಿಗೆ ಸಂಪರ್ಕದಲ್ಲೂ ಉಳಿಯುವ ನಿರ್ಧಾರ ನಿಯಮ ಚಿಕ್ಕದು: ಸಾಧ್ಯವಾದಾಗ ಮರಳು ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸಿ, ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ಅನುವಾದ ಮಾಡಿ, ಮತ್ತು ಮೂರು ಷರತ್ತುಗಳಲ್ಲಿ ಯಾವುದು ಆ ಆಯ್ಕೆ ಮಾಡಿಸಿತು ಎಂದು ಬರೆದಿಡಿ. ಆ ಟಿಪ್ಪಣಿ ಮುಂದಿನ ವ್ಯಕ್ತಿಯ ಅರ್ಧ ದಿನ ಉಳಿಸುತ್ತದೆ.