VPN ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ವಿಳಾಸದಲ್ಲಿ LAN ಸೇವೆಯನ್ನು ಪ್ರಕಟಿಸಿ

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

ಕ್ಲೈಂಟ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಈ ಉದಾಹರಣೆಯಲ್ಲಿ ಕ್ಲೈಂಟ್ VPN ಪೂಲ್ 10.62.0.0/24 ನಲ್ಲಿ ಇದ್ದು, ಪೋರ್ಟ್ 8080 ನಲ್ಲಿ 10.62.0.1 ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ. ಆ ವಿಳಾಸವು ಗೇಟ್‌ವೇಯದೇ ಆಗಿದೆ, ಆದ್ದರಿಂದ ಪ್ಯಾಕೆಟ್ ಇನ್ನೊಬ್ಬ ಪೀರ್ ಬಳಿಗೆ ಅಲ್ಲ, ಗೇಟ್‌ವೇಯ ಕರ್ನೆಲ್‌ಗೆ ತಲುಪುತ್ತದೆ. ಗೇಟ್‌ವೇಯ ಹಿಂದೆ LAN 172.21.4.0/24 ಆಗಿದೆ. ಗೇಟ್‌ವೇ ಬಳಿ 172.21.4.10 ಇದೆ ಮತ್ತು HTTP ಅನ್ನು ನಿಜವಾಗಿ ಒದಗಿಸುವ ಸಾಧನ 172.21.4.40 ಆಗಿದೆ.

ಬೇರೆ VPN ಪೀರ್‌ಗೆ ಸೇರಿದ ವಿಳಾಸವನ್ನು ಗೇಟ್‌ವೇಯ ಸೇವಾ ವಿಳಾಸದೊಂದಿಗೆ ಬದಲಾಯಿಸಲಾಗದು. ಕ್ಲೈಂಟ್ ಪೀರ್‌ನ ವಿಳಾಸಕ್ಕೆ ಸಂಪರ್ಕಿಸುತ್ತಿದ್ದರೆ, ಯಾವುದೇ ಗೇಟ್‌ವೇ ನಿಯಮವೂ ಸಂಬಂಧಿಸಿಲ್ಲ, ಮತ್ತು ಈ ಇಡೀ ಸುತ್ತಾಟವು ತಪ್ಪು ಪ್ರಕರಣವಾಗಿದೆ.

ಗಮ್ಯಸ್ಥಾನ ಅನುವಾದದ ವ್ಯಾಪ್ತಿಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸೀಮಿತಗೊಳಿಸಿ

ಸಂಕುಚಿತ ಆವೃತ್ತಿ ಒಂದು ಪೋರ್ಟ್ ಅನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಮಾತ್ರ ಮರುಬರೆಯುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ತನ್ನ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಮೂಲವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಅದೇ ಉಳಿದ ಸುತ್ತಾಟವನ್ನು ಆಸಕ್ತಿಕರಗೊಳಿಸುತ್ತದೆ.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

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

ಫಾರ್ವರ್ಡಿಂಗ್ ಗಡಿ ಒಪ್ಪಿಕೊಳ್ಳಲಿ

ಅನುವಾದವು ಹೆಡರ್ ಬದಲಾಯಿಸುತ್ತದೆ, ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ. ಡೀಫಾಲ್ಟ್ ಡ್ರಾಪ್ ನೀತಿಯೊಂದಿಗೆ ಫಾರ್ವರ್ಡ್ ಆದ ಹರಿವಿಗೆ ತನ್ನದೇ ಅನುಮೋದನೆ ಬೇಕು, ಮತ್ತು ಹಿಂತಿರುಗುವ ದಿಕ್ಕಿಗೆ ನಿಮ್ಮ ನೀತಿಯಲ್ಲಿ ಬಹುಶಃ ಈಗಾಗಲೇ ಇರುವ ಸ್ಥಾಪಿತ ನಿಯಮ ಬೇಕು.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ಪ್ರತಿ DNAT ಹರಿವಿಗೂ ಬಿನ್‌ಶರತ್ತು ಅನುಮೋದನೆ ಈ ವಿನ್ಯಾಸಕ್ಕಿಂತ ವಿಶಾಲವಾಗಿದೆ ಮತ್ತು ನಂತರ ಬೇರೆಯವರು ಸೇರಿಸುವ ಮ್ಯಾಪಿಂಗ್‌ಗಳಿಗೂ ಅನುಮತಿ ನೀಡುತ್ತದೆ. ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಹೆಸರಿಸಿ, ಉಳಿದದ್ದನ್ನು ಮುಚ್ಚಿಡಿ. ಫಾರ್ವರ್ಡ್ ನಿಯಮದ ಕೌಂಟರ್‌ಗಳು ಶೂನ್ಯದಲ್ಲೇ ಇದ್ದು NAT ಕೌಂಟರ್‌ಗಳು ಏರಿದರೆ, ಪ್ಯಾಕೆಟ್ ನಿಮ್ಮ ನಿಯಮಕ್ಕಿಂತ ಮೊದಲೇ ಬಿಸಾಡಲ್ಪಡುತ್ತಿದೆ. ಎರಡನೇ ಪ್ರತಿ ಸೇರಿಸುವ ಬದಲು ಸರಣಿಯ ಕ್ರಮವನ್ನು ಓದಿ.

ಸಾಧನವು ಹೇಗಾದರೂ ಉತ್ತರಿಸಬೇಕು

ಅನುವಾದದ ನಂತರ ಸಾಧನವು 10.62.0.0/24 ಒಳಗೆ ಮೂಲವನ್ನು ನೋಡುತ್ತದೆ. ಅದರ ಉತ್ತರವು ಅದರ ಡೀಫಾಲ್ಟ್ ಗೇಟ್‌ವೇಗೆ ಹೋಗುತ್ತದೆ, ಅದು LAN ರೌಟರ್, VPN ಗೇಟ್‌ವೇ ಅಲ್ಲ, ಬೇರೆ ಯಾವುದಾದರೂ ಬೇರೆ ಹೇಳದಿದ್ದರೆ. ಎರಡು ವ್ಯವಸ್ಥೆಗಳು ಇದನ್ನು ಸರಿಪಡಿಸುತ್ತವೆ ಮತ್ತು ಅವು ಸಮಾನವಲ್ಲ. ಸಾಧನದಲ್ಲಿ ಅಥವಾ LAN ರೌಟರ್‌ನಲ್ಲಿ ಇರುವ ರೂಟ್ 10.62.0.0/24 ಅನ್ನು 172.21.4.10 ಗೆ ಕಳುಹಿಸಿ ಕ್ಲೈಂಟ್ ಮೂಲವನ್ನು ಉಳಿಸುತ್ತದೆ. ಸೀಮಿತ ಮೂಲ ಅನುವಾದವು ಬದಲಿಗೆ ಕ್ಲೈಂಟ್ ಅನ್ನು ಗೇಟ್‌ವೇಯ LAN ವಿಳಾಸದ ಹಿಂದೆ ಮರೆಮಾಡುತ್ತದೆ.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

ಸೇವೆಗೆ ಏನು ಬೇಕು ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಆಯ್ಕೆಮಾಡಿ. ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ನೀತಿ ಮತ್ತು ಅರ್ಥಪೂರ್ಣ ಲಾಗ್‌ಗಳು ರೂಟ್ ಮಾಡಿದ ರೂಪವನ್ನು ಬಯಸುತ್ತವೆ; ರೂಟ್ ನೀಡಲಾಗದ ಸಾಧನ ಅಥವಾ ಕಡ್ಡಾಯವಾಗಿ LAN ವಿಳಾಸವನ್ನು ನೋಡಬೇಕಾದ ಸೇವೆ ಅನುವಾದಿತ ರೂಪವನ್ನು ಸೂಚಿಸುತ್ತವೆ. ಒಂದು ಉತ್ತರವನ್ನು ಕೆಲಸ ಮಾಡಿಸಲು ಜಾಗತಿಕ masquerade ನಿಯಮದ ಕಡೆಗೆ ಕೈ ಚಾಚಬೇಡಿ. ಅದು ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಅನ್ನು ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನದಿಂದ ಮರೆಮಾಡುತ್ತದೆ ಮತ್ತು ಮೂಲ ವಿಳಾಸಗಳನ್ನು ಅವಲಂಬಿಸಿರುವ ನೀತಿಗಳನ್ನು ಸದ್ದಿಲ್ಲದೆ ಮುರಿಯುತ್ತದೆ.

ಗೇಟ್‌ವೇಯಿಂದಲೇ ಪರೀಕ್ಷಿಸಬೇಡಿ

ಗೇಟ್‌ವೇಯಲ್ಲಿ 10.62.0.1 ಕಡೆಗೆ ರಚಿಸಿದ ವಿನಂತಿ ಒಳಬರುವ PREROUTING ಮೂಲಕವಲ್ಲ, OUTPUT ಸರಣಿಯ ಮೂಲಕ ಹೊರಡುತ್ತದೆ. ಅದರ ವೈಫಲ್ಯ ಅಥವಾ ಯಶಸ್ಸು ಕ್ಲೈಂಟ್‌ನ ಕಡೆಗಿನ ನಿಯಮದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಹೀಗೆಯೇ ಜನರು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ನಿಯಮ ಮುರಿದಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುತ್ತಾರೆ.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

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