ರೌಟರ್‌ನಲ್ಲಿ VPN ಅಥವಾ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್: ಯಾವುದು ಗೆಲ್ಲುತ್ತದೆ?

ರೌಟರ್ ಸ್ವತಃ VPN ಅನ್ನು ಮುಗಿಸುತ್ತದೆ, ಮತ್ತು ಹಳೆಯ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮವು ಇನ್ನೂ ಅದೇ UDP ಪೋರ್ಟ್ ಅನ್ನು LAN ನಲ್ಲಿನ ಯಂತ್ರಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಒಂದೇ ನಿಜವಾದ ಅಂತಿಮ ಬಿಂದುವಾಗಿರಬಹುದು, ಮತ್ತು ಕರ್ನೆಲ್ ಅವುಗಳ ನಡುವೆ ತೀರ್ಪು ನೀಡುವುದಿಲ್ಲ. ಗಮ್ಯಸ್ಥಾನದ ಅನುವಾದವು ಸ್ಥಳೀಯ ಸೇವೆಯನ್ನು ಕೇಳುವ ಮೊದಲೇ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ VPN ಪ್ರಕ್ರಿಯೆಯು ಈಗಾಗಲೇ ಬೇರೆಡೆಗೆ ಕಳುಹಿಸಲಾದ ಸಂಚಾರಕ್ಕಾಗಿ ಕಾಯುತ್ತದೆ. ಕೆಲಸವೆಂದರೆ ಪೋರ್ಟ್ ಯಾರಿಗೆ ಸೇರಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು, ನಂತರ ನಿಯಮಗಳನ್ನು ಹೊಂದಿಸುವುದು.

ಒಂದು ಪೋರ್ಟ್, ಇಬ್ಬರು ಹಕ್ಕು ಸಾಧಿಸುವ ಮಾಲೀಕರು

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

ಸಂಪಾದಿಸುವ ಮೊದಲು ಹಕ್ಕನ್ನು ಬರೆಯಿರಿ: ಕುಟುಂಬ, ಬಾಹ್ಯ ವಿಳಾಸ, ಸಾಗಣೆ, ಪೋರ್ಟ್ ಮತ್ತು ಅನುವಾದಿತ ಗುರಿ.

ಸ್ಥಳೀಯ ಪರಿಶೀಲನೆಗೆ ಮೊದಲು ಅನುವಾದ ನಡೆಯುತ್ತದೆ

ಗಮ್ಯಸ್ಥಾನ NAT ಕರ್ನೆಲ್ ಸ್ಥಳೀಯ ವಿತರಣೆ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು, ಪೂರ್ವ-ರೂಟಿಂಗ್ ಹಂತದಲ್ಲಿ ಪ್ಯಾಕೆಟ್ನ ಗುರಿಯನ್ನು ಬದಲಿಸುತ್ತದೆ. ಗುರಿಯು LAN ಹೋಸ್ಟ್ ಆದ ಕೂಡಲೇ ಪ್ಯಾಕೆಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ರೌಟರ್ನ ಸ್ವಂತ ಸಾಕೆಟ್ಗೆ ಇನ್ಪುಟ್ ನಿಯಮಗಳನ್ನು ಎಂದಿಗೂ ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಕಾಯುತ್ತಿರುವಾಗ VPN ಲಾಗ್ ಖಾಲಿಯಾಗಿರುತ್ತದೆ.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

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

LAN ಹೋಸ್ಟ್ ಉದ್ದೇಶಿತ ಅಂತಿಮ ಬಿಂದುವಾಗಿದ್ದರೆ, ಫಾರ್ವರ್ಡಿಂಗ್ ಸರಿಯಾಗಿದೆ ಮತ್ತು ರೌಟರ್ ಅದೇ ಪೋರ್ಟ್ನಲ್ಲಿ ಸಹ ಆಲಿಸಬಾರದು.

ಒಂದು ಮ್ಯಾಪಿಂಗ್ ಇಟ್ಟುಕೊಳ್ಳಿ ಮತ್ತು ಇನ್ನೊಂದನ್ನು ತೆಗೆದುಹಾಕಿ

ಆ ಪೋರ್ಟ್ ಮತ್ತು ಕುಟುಂಬಕ್ಕಾಗಿ NAT ನಮೂದುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು ಉಳಿಯುವವರನ್ನು ಆಯ್ಕೆಮಾಡಿ:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

ಅದೇ ಸಂಖ್ಯೆಯ TCP ನಮೂದು UDP ವೈಫಲ್ಯಕ್ಕೆ ಅಪ್ರಸ್ತುತವಾಗಿದೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಒಂದೇ ವಸ್ತುವಾಗಿ ಪರಿಗಣಿಸುವುದು ತಪ್ಪು ನಿಯಮವನ್ನು ಅಳಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ. ಸ್ಥಳೀಯ ಸಾಕೆಟ್ ಗೆಲ್ಲಬೇಕಾದಾಗ, ಸಂಘರ್ಷದ ಮ್ಯಾಪಿಂಗ್ನ ಮಾಲೀಕರು ಆ ಒಂದು ನಮೂದನ್ನು ತೆಗೆದುಹಾಕುತ್ತಾರೆ ಅಥವಾ ಮತ್ತೆ ಬರೆಯುತ್ತಾರೆ, ಮತ್ತು ರೌಟರ್ನ ಸ್ವಂತ ಪೋರ್ಟ್ಗೆ ಒಳಬರುವ ಅನುಮತಿ ಅದರ ಸ್ಥಳದಲ್ಲೇ ಇರುತ್ತದೆ. ಸಂಬಂಧವಿಲ್ಲದ ಫಾರ್ವರ್ಡಿಂಗ್ಗಳು, ನಿರ್ವಹಣಾ ಮಾರ್ಗ ಮತ್ತು ನಿಯಮಗಳ ಗುಂಪಿನ ಪ್ರತಿ—ಎಲ್ಲವೂ ಈ ಬದಲಾವಣೆಯನ್ನು ಉಳಿದುಕೊಳ್ಳಬೇಕು.

VPN ಪ್ರತ್ಯೇಕ ಹೋಸ್ಟ್ನಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದರೆ, ಫಾರ್ವರ್ಡಿಂಗ್ ಸರಿಯಾದ ವಸ್ತು. ಕಂಟೇನರ್ ಅಥವಾ ವರ್ಚುವಲ್ ಯಂತ್ರದಲ್ಲಿನ ಸೇವೆಗೆ ಪೆಟ್ಟಿಗೆಯನ್ನು ರೌಟರ್ ಎಂದು ಕರೆದರೂ ಪ್ರಕಟಿತ ಪೋರ್ಟ್ ಬೇಕಾಗಬಹುದು, ಆದ್ದರಿಂದ ಕೇಸ್ನ ಮೇಲಿನ ಲೇಬಲ್ ಅಲ್ಲ, ಸಾಕೆಟ್ ಮತ್ತು ಅದರ ನೇಮ್ಸ್ಪೇಸ್ ಅನ್ನು ಅನುಸರಿಸಿ.

ಹೊರಗಿನಿಂದ ಮಾಲೀಕರನ್ನು ದೃಢೀಕರಿಸಿ

ಪ್ರತಿ ಕುಟುಂಬವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ರೌಟರ್ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವ IPv6 ಸಂಪರ್ಕವು ಹಳೆಯ ನಿಯಮವು ಮರುನಿರ್ದೇಶಿಸುವ IPv4 ಸಂಪರ್ಕದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಯಾವ ಅಂತಿಮ ಬಿಂದು ಉತ್ತರಿಸಿತು ಎಂಬುದನ್ನು ನೋಡಲು ಸ್ವೀಕರಿಸುವ ಸೇವೆಯ ಲಾಗ್ ಓದಿ, ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಯಶಸ್ಸಿನ ಸಂದೇಶವನ್ನು ದುರ್ಬಲ ಸಾಕ್ಷ್ಯವೆಂದು ಪರಿಗಣಿಸಿ. ಅರ್ಥಪೂರ್ಣ ಪರೀಕ್ಷೆಗೆ ಹೊಸ ಹರಿವು ಬೇಕು. ಹೊರಗಿನ ಹೋಸ್ಟ್ನಿಂದ nc -zvu 203.0.113.7 1194 ಬಳಸಿ ಪ್ರೋಬ್ ಕಳುಹಿಸಿ ಮತ್ತು ವಿಜೇತರ ಲಾಗ್ ಅನ್ನು journalctl -u openvpn@server -n 20 ಬಳಸಿ ಓದಿ. ರೌಟರ್ನ ಆಲಿಸುವವನು ಸಂಪರ್ಕವನ್ನು ಸ್ವತಃ ದಾಖಲಿಸುತ್ತಾನೆ, ಆದರೆ LAN ಹೋಸ್ಟ್ ಅದನ್ನು ತನ್ನದೇ ಸೇವೆಯಲ್ಲಿ ದಾಖಲಿಸುತ್ತದೆ.

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

ಉದ್ದೇಶಿತ ಅಂತಿಮ ಬಿಂದುವು ತನ್ನ ಸಾಮಾನ್ಯ ಗುರುತು ಪರಿಶೀಲನೆಗಳೊಂದಿಗೆ ಉತ್ತರಿಸಿದ ನಂತರ, ಸುರಂಗದ ಹಿಂದಿನ ಖಾಸಗಿ ಸಂಪನ್ಮೂಲವನ್ನು ಪರೀಕ್ಷಿಸಿ. ಹೊರಗಿನ ಆಲಿಸುವವನನ್ನು ತಲುಪುವುದು ಕೇವಲ ಮೊದಲ ಹೆಜ್ಜೆ; ಒಳಗಿನ ರೂಟಿಂಗ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅಧಿಕಾರ ಪ್ರತ್ಯೇಕ ಫಲಿತಾಂಶಗಳು.