VPN ಸಬ್ನೆಟ್ಗೆ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡ್ನಲ್ಲಿ SNAT ಅನ್ವಯಿಸಬೇಕೇ?

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

ಪ್ರತ್ಯುತ್ತರ ಏಕೆ ಬೇರೆ ದಾರಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ

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

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

ನಂಬಲು ಸಾಕಷ್ಟು ಸಂಕುಚಿತವಾದ ಮೂಲ ನಿಯಮ

ರೌಟರ್ ಅನ್ನು ದೂರದ ಹೋಸ್ಟ್ ಉತ್ತರಿಸುವ ಮೂಲವನ್ನಾಗಿ ಮಾಡಿ. ಈ ಜೋಡಣೆಯಲ್ಲಿ WAN ವಿಳಾಸ 203.0.113.24, LAN 192.168.88.0/24, ರೌಟರ್ನ ಟನೆಲ್ ವಿಳಾಸ 172.20.5.1, ಮತ್ತು ಸೇವೆ 172.20.5.40:8443 ನಲ್ಲಿ ಉತ್ತರಿಸುತ್ತದೆ. ಕೆಳಗಿನ ನಿಯಮವು ಗಮ್ಯಸ್ಥಾನ ಅನುವಾದದ ನಂತರದ ಪ್ಯಾಕೆಟ್ಗೆ ಹೊಂದುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಸಾರ್ವಜನಿಕ ಬದಲು ಅನುವಾದಿತ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಅದರಲ್ಲಿ ಯಾವುದೂ ಕ್ಲೈಂಟ್ನ ವಿಳಾಸವನ್ನು ಅವಲಂಬಿಸಿಲ್ಲ, ಮತ್ತು ಅದೇ ಮುಖ್ಯ ಅಂಶ.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

ಯಾವಾಗ ಸರ್ವವ್ಯಾಪಿ ಮಸ್ಕರೇಡ್ ಪ್ರಾಮಾಣಿಕ ಆಯ್ಕೆಯಾಗಿದೆ

ರೌಟರ್ ಅನೇಕ ಸೇವೆಗಳನ್ನು ಅದೇ VPN ಸಬ್ನೆಟ್ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದರೆ, ಪ್ರತಿ ಸೇವೆಯ ನಿಯಮವು ಯಾರೂ ನಿರ್ವಹಿಸದ ಪಟ್ಟಿಯಾಗುತ್ತದೆ. ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಹೊರಹೋಗುವ ಎಲ್ಲವನ್ನೂ ಮಸ್ಕ್ ಮಾಡುವುದು ಸರಳ ಮತ್ತು ಊಹಿಸಬಹುದಾದದ್ದು, ಆದರೆ ಅದರ ಬೆಲೆ ಎಂದರೆ ಮೂಲ ಕ್ಲೈಂಟ್ ಎದುರು ಭಾಗದ ಪ್ರತಿ ಹೋಸ್ಟ್ನಿಂದ ಮರೆಯಾಗುತ್ತದೆ. ಅಲ್ಲಿನ ಲಾಗ್ಗಳನ್ನು ಆರೋಪಣೆಗೆ ಬಳಸದಿದ್ದಾಗ ಅದನ್ನು ಆರಿಸಿ; ಬಳಸಿದಾಗ ಸಂಕುಚಿತ ನಿಯಮವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ.

ಎರಡೂ ಆಯ್ಕೆಗಳು ವಿಭಿನ್ನವಾಗಿಯೂ ವಿಫಲವಾಗುತ್ತವೆ. ಕಾಣೆಯಾದ ಸಂಕುಚಿತ ನಿಯಮ ಒಂದು ಸೇವೆಯನ್ನು ಮುರಿಯುತ್ತದೆ; ಹೆಚ್ಚು ಹೊಂದುವ ವಿಶಾಲ ಮಸ್ಕರೇಡ್ ಈಗಾಗಲೇ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ಸಂಚಾರವನ್ನು, ರೌಟರ್ನ ಸ್ವಂತ ಹೊರಹೋಗುವ ಸಂಪರ್ಕಗಳೂ ಸೇರಿದಂತೆ, ಮೌನವಾಗಿ ಮರುಬರೆಯಬಹುದು.

ಪ್ರಕಟಿಸುವ ಮೊದಲು ಕೌಂಟರ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

ಎಂದಿಗೂ ಹೊಂದದ ನಿಯಮಗಳು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಎಣಿಸುವವರೆಗೆ ಕೆಲಸ ಮಾಡುವ ನಿಯಮಗಳಂತೆಯೇ ಕಾಣುತ್ತವೆ. ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸುವ ಮೊದಲು ಬೈಟ್ ಕೌಂಟರ್ಗಳೊಂದಿಗೆ ಕೋಷ್ಟಕವನ್ನು ಮತ್ತೆ ಓದಿ, ನಂತರ LAN ಅಲ್ಲದ ನೆಟ್ವರ್ಕ್ನಿಂದ ಸಂಪರ್ಕಿಸಿ ಮತ್ತೆ ಓದಿ. ಎರಡು ಓದುವಿಕೆಗಳೇ ಊಹೆಯನ್ನು ಸತ್ಯವಾಗಿ ಬದಲಿಸುತ್ತವೆ. ಎರಡನೆಯದು ಚಲಿಸಿದ ನಂತರವೇ ಫಾರ್ವರ್ಡ್ ಪ್ರಕಟಿಸಿ.

iptables -t nat -L POSTROUTING -v -n --line-numbers

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