CGNAT ಪೋರ್ಟ್‌ಗಳನ್ನು ನಿರ್ಬಂಧಿಸಿದಾಗ VPS ಮೂಲಕ ಮನೆಯ ಸರ್ವರ್ ಪ್ರಕಟಿಸುವುದು

ನಾನು ಹೊರಗಿನಿಂದ ಪ್ರಾರಂಭಿಸಿದೆ, ಒಬ್ಬ ಬಳಕೆದಾರ ಮಾಡುವಂತೆ: ಹೆಸರನ್ನು ಮೊಬೈಲ್ ಡೇಟಾದಲ್ಲಿ ಫೋನ್ ಬ್ರೌಸರ್ನಲ್ಲಿ ಟೈಪ್ ಮಾಡಿ, ಸಂಪರ್ಕ ಸಮಯ ಮುಗಿಯುವವರೆಗೆ ನೇತಾಡುತ್ತಿರುವುದನ್ನು ನೋಡಿದೆ. ಹೆಸರು ಪರಿಹಾರವಾಗುತ್ತಿತ್ತು, ಅಂದರೆ DNS ಸರಿಯಾಗಿತ್ತು. ಮನೆಯ ರೂಟರ್ನ ಪೋರ್ಟ್-ಫಾರ್ವರ್ಡಿಂಗ್ ಪುಟವೂ ಬಂದ ಗಲ್ಲಿ, ಏಕೆಂದರೆ ಅದರ WAN ವಿಳಾಸ 100.64.31.42 ತೋರಿಸಿತು, ಮತ್ತು ಇದು ಯಾವುದೇ ಪೂರೈಕೆದಾರ ನನ್ನನ್ನು ಇಂಟರ್ನೆಟ್ನಿಂದ ಕಳುಹಿಸುವ ವಿಳಾಸವಲ್ಲ. ಈ ಸಂಖ್ಯೆ ಇಡೀ ವೈಫಲ್ಯವನ್ನು ವಿವರಿಸುತ್ತದೆ: ಸಾಲು carrier-grade NAT ಹಿಂದೆ ಇದೆ, ಆದ್ದರಿಂದ ಸುರಂಗದ ನನ್ನ ಬದಿಯ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಪೂರೈಕೆದಾರರದ್ದು. ಮುಂದೆ ನಾನು ಆ ಸಿಕ್ಕಿಹಾಕಿಕೊಂಡ ಟ್ಯಾಬ್ನಿಂದ ಉತ್ತರಿಸುವ ಸೇವೆಯವರೆಗೆ ನಡೆದ ದಾರಿ ಇದೆ.

ಕ್ಲೈಂಟ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಒಳಗೆ ಹೋಗಿ

ಯಾವುದೇ ನಿಯಮವನ್ನು ಬದಲಿಸುವ ಮೊದಲು ಸರಪಳಿ ಎಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ. ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ನಾನು dig +short files.example.net ಚಲಾಯಿಸಿ VPS ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿ ಪಡೆದೆ, ಇದು ನನ್ನ ಯಂತ್ರದಲ್ಲಿನ ಹಳೆಯ DNS ಅನ್ನು ಹೊರಗಿಟ್ಟಿತು. ನಂತರ curl -v --connect-timeout 5 files.example.net:5022 ನಿರಾಕರಿಸಲ್ಪಡುವ ಬದಲು ಸಮಯ ಮುಗಿದು ನಿಂತಿತು. ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ: ಸಮಯ ಮುಗಿಯುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ಯಾಕೆಟ್ಗಳು ದಾರಿಯಲ್ಲಿ ಎಸೆಯಲ್ಪಡುತ್ತಿವೆ ಎಂದರ್ಥ, ಆದರೆ ನಿರಾಕರಣೆ ಎಂದರೆ ಏನೋ ಉತ್ತರಿಸಿ ಇಲ್ಲ ಎಂದಿತು.

ಒಳಗೆ ಮುಂದಿನ ಹೆಜ್ಜೆ VPS ಸ್ವತಃ. ss -ltnp 5022 ನಲ್ಲಿ ಕೇಳಿಸುವ ಯಾವುದನ್ನೂ ತೋರಿಸಲಿಲ್ಲ, ಇದು DNAT ನಿಯಮ ರೂಪುಗೊಳ್ಳುವ ಮೊದಲು ನಿರೀಕ್ಷಿತವಾಗಿತ್ತು. ಅದೇ ಯಂತ್ರದಲ್ಲಿ wg show (ಅಥವಾ OpenVPN ಗಾಗಿ ip -br a show tun0) ಮನೆಯ peer ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಮತ್ತು ಅದಕ್ಕೆ ಹೊಸ handshake ಇದೆ ಎಂದು ಖಚಿತಪಡಿಸಿತು. peer ಕೆಲಸ ಮಾಡದಿದ್ದರೆ ಯಾವ NAT ನಿಯಮವೂ ಸಹಾಯ ಮಾಡದು, ಮತ್ತು ಮನೆಯ ರೂಟರ್ನ VPN ಪುಟದಲ್ಲಿನ ಹಸಿರು ಬೆಳಕು ಏನನ್ನೂ ಅರ್ಥೈಸುವುದಿಲ್ಲ.

ಮನೆಯ ಸಾಲು ನಿಜವಾಗಿಯೂ CGNAT ಹಿಂದೆ ಇದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ

ರೂಟರ್ ತನ್ನ WAN ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ವರದಿ ಮಾಡುವ ವಿಳಾಸವನ್ನು ಹೊರಗಿನ ಸೇವೆ ನೋಡುವುದರೊಂದಿಗೆ ಹೋಲಿಸಿ. 100.64.0.0/10 ನಲ್ಲಿರುವ ಎಲ್ಲವೂ, ಅಂದರೆ 100.64.x.x ನಿಂದ 100.127.x.x ವರೆಗೆ, RFC 6598 ನ ಹಂಚಿಕೆಯ ವಿಳಾಸ ಶ್ರೇಣಿ ಮತ್ತು ಇಂಟರ್ನೆಟ್ನಿಂದ ತಲುಪಲಾಗದು. ರೂಟರ್ ಸಾಮಾನ್ಯ ಖಾಸಗಿ ವಿಳಾಸ ಇದೆ ಎಂದು ಹೇಳಿ, ಸಾರ್ವಜನಿಕ ಹುಡುಕಾಟ ಸಂಬಂಧವಿಲ್ಲದ್ದನ್ನು ಹಿಂತಿರುಗಿಸಿದಾಗಲೂ ನೀವು ಅದೇ ತೀರ್ಮಾನಕ್ಕೆ ಬರುತ್ತೀರಿ. CGNAT ಸಾಲಿನಲ್ಲಿ ಮುಂದಿನ lease ವರೆಗೆ ಮಾತ್ರ ಇರುವ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವೂ ಇರಬಹುದು, ಆದ್ದರಿಂದ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಒಂದು ಗಂಟೆ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಂತೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ನಂತರ ಸದ್ದಿಲ್ಲದೆ ಸಾಯುತ್ತದೆ.

ಕೆಲವು ಪೂರೈಕೆದಾರರು ನಿಜವಾದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ನೀಡುತ್ತಾರೆ, ಆದರೆ ವಸತಿ ಖಾತೆಗಳಲ್ಲಿ ಒಳಬರುವ 80 ಮತ್ತು 443 ಪೋರ್ಟ್ಗಳನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತಾರೆ. ನಿಮ್ಮ ಸೇವೆ ವೆಬ್ ಮಾತ್ರವೇ ಆಗಿದ್ದರೆ ಮತ್ತು WAN ವಿಳಾಸ ನಿಜವಾಗಿ ಸಾರ್ವಜನಿಕವಾಗಿದ್ದರೆ, relay ನಿರ್ಮಿಸುವ ಮೊದಲು ಬೆಂಬಲವನ್ನು ಕೇಳಿ. ಇಲ್ಲದಿದ್ದರೆ, ಕೆಳಗಿನ ವಿನ್ಯಾಸ ಪ್ರತಿ ಪೋರ್ಟ್ಗೂ ಸಮಾನವಾಗಿ ಅನ್ವಯಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರಯೋಗವನ್ನು ರೂಟರ್ ಬದಿಯಲ್ಲಿ ನಿಲ್ಲಿಸುವುದು ಒಳ್ಳೆಯದು: ಪೂರೈಕೆದಾರರ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿರುವ ಅನುವಾದಕ ಸಂಪರ್ಕವು ನಿಮ್ಮ WAN ಇಂಟರ್ಫೇಸ್ ತಲುಪುವ ಮೊದಲೇ ಅದನ್ನು ಮುಗಿಸುತ್ತದೆ.

ಹೆಸರನ್ನು VPS ವಿಳಾಸದ ಕಡೆಗೆ ತೋರಿಸಿ

DNS ಸಂಚಾರವನ್ನು ಮುಂದೆ ಕಳುಹಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸೇವೆಯ A ದಾಖಲೆಯಲ್ಲಿ VPS ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಇರಬೇಕು. 192.168.1.20 ಕಡೆಗಿನ A ದಾಖಲೆ ಈಗಾಗಲೇ VPN ಒಳಗಿರುವ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಮಾತ್ರ ಉಪಯುಕ್ತವಾಗಿ ಪರಿಹಾರವಾಗುತ್ತದೆ; ಇಂಟರ್ನೆಟ್ನಿಂದ ಅದು ಯಾರೂ ರೂಟ್ ಮಾಡಲಾಗದ ವಿಳಾಸಕ್ಕೆ ಪರಿಹಾರವಾಗುತ್ತದೆ. VPS ನ ಸ್ವಂತ ಆಡಳಿತ ಪ್ರವೇಶಕ್ಕೆ ನಾನು ಪ್ರತ್ಯೇಕ ಹೆಸರನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತೇನೆ, ಒಂದು ದಾಖಲೆ ಯಾವ ಹೋಸ್ಟ್ಗೆ ಸಂಬಂಧಿಸಿದೆ ಎಂದು ಎಂದಿಗೂ ಗೊಂದಲ ಮಾಡಿಕೊಳ್ಳದಂತೆ.

VPS ಮತ್ತು ಮನೆಯ ಯಂತ್ರ ಎರಡೂ HTTP ನೀಡಿದರೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ಅದರದೇ ಹೆಸರು ಕೊಡಿ ಮತ್ತು ಯಾರು ಉತ್ತರಿಸುತ್ತಾರೆ ಎಂದು VPS ನಿರ್ಧರಿಸಲಿ. ಎರಡನ್ನೂ ಒಂದೇ ಹೆಸರಿನಲ್ಲಿ ಸೇರಿಸಿ, ಪ್ರಾಕ್ಸಿ ಸರಿಯಾದ backend ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂದು ನಂಬುವುದು, ತಪ್ಪು ಹೋಸ್ಟ್ನಲ್ಲಿ ಅರ್ಧ ದಿನ ದೋಷ ಹುಡುಕುವ ನಿಖರ ದಾರಿ.

ಒಂದು ಪೋರ್ಟ್ DNAT ನಲ್ಲಿ, SSH 22 ನಲ್ಲಿ ಉಳಿಯಲಿ

ನೇರ ಆಯ್ಕೆ VPS ನಲ್ಲಿ ಗಮ್ಯಸ್ಥಾನ NAT. ಚಾಲನೆಯಲ್ಲಿರುವ ಕರ್ನೆಲ್ಗೆ forwarding ಸಕ್ರಿಯಗೊಳಿಸಿ ಮತ್ತು ನಿಯಮದಲ್ಲಿ ಮನೆಯ ಸರ್ವರ್ನ ಸುರಂಗ ವಿಳಾಸವನ್ನು ಇರಿಸಿ, ಅದರ LAN ವಿಳಾಸವನ್ನಲ್ಲ:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

VPS ಗೆ SSH ಅನ್ನು 22 ನಲ್ಲಿ ಬಿಡಿ ಮತ್ತು ಇನ್ನೊಂದು ಪೋರ್ಟ್, ಉದಾಹರಣೆಗೆ 5022, ಮನೆಯ ಯಂತ್ರಕ್ಕೆ ಕಳುಹಿಸಿ. 22 ಅನ್ನು ಆಫ್ ಆದ ಯಂತ್ರಕ್ಕೆ ಕಳುಹಿಸಿದರೆ ಅದನ್ನು ಸರಿಪಡಿಸಬಹುದಾದ ಏಕೈಕ ದಾರಿಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ಅದೇ ತರ್ಕ ಪ್ರಾಕ್ಸಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ: VPS ನ ನಿರ್ವಹಣಾ ಪೋರ್ಟ್ ಅನ್ನು relay ನಿಯಮಗಳ ಹೊರಗೆ ಇರಿಸಿ.

ನಿಯಮಗಳು ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಅವುಗಳನ್ನು ಶಾಶ್ವತಗೊಳಿಸಿ. Debian ಅಥವಾ Ubuntu ನಲ್ಲಿ apt install iptables-persistent ಮತ್ತು ನಂತರ netfilter-persistent save ಅವುಗಳನ್ನು /etc/iptables/rules.v4 ಗೆ ಬರೆಯುತ್ತವೆ. firewalld ಇರುವ ಹೋಸ್ಟ್ನಲ್ಲಿ ಅದರ ಸಮಾನಾಂತರ ವಲಯದಲ್ಲಿ ಶಾಶ್ವತ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್, ಅದು ಜಾರಿಗೆ ಬರುವ ಮೊದಲು firewall-cmd --reload ಬೇಕು. ಸ್ಮೃತಿಯಲ್ಲಿ ಮಾತ್ರ ಜೀವಿಸುವ ನಿಯಮಗಳು ಪೂರೈಕೆದಾರರ ಮೊದಲ ನಿರ್ವಹಣಾ ಮರುಪ್ರಾರಂಭದಲ್ಲಿ ಮಾಯವಾಗುತ್ತವೆ, ಸಾಮಾನ್ಯವಾಗಿ ಕೆಟ್ಟ ಸಮಯದಲ್ಲಿ.

ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಸರಿಪಡಿಸಿ ಅಥವಾ ಅದರ ಅಗತ್ಯವನ್ನು ತಪ್ಪಿಸಿ

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

ಎರಡು ತಿದ್ದುಪಡಿಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಮನೆಯ ಯಂತ್ರಕ್ಕೆ ನೀತಿ-ಮಾರ್ಗ ಕೊಡಿ, ಸುರಂಗದಿಂದ ಬರುವ ಸಂಚಾರ ಸುರಂಗದ ಮೂಲಕವೇ ಹಿಂತಿರುಗಲಿ:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

ಅಥವಾ VPS ಮೂಲವನ್ನು ಮತ್ತೆ ಬರೆಯಲಿ, ಉತ್ತರಕ್ಕೆ ಅದು ತಲುಪಬಹುದಾದ ವಿಳಾಸ ಇರಲಿ, conntrack ಅದನ್ನು ಹೊರಹೋಗುವಾಗ ತಿರುಗಿಸಲಿ:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

SNAT ಆವೃತ್ತಿ ನಿಜವಾದ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ಮನೆಯ ಸರ್ವರ್ನಿಂದ ಮರೆಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಲಾಗ್ಗಳು peer ಆಗಿ 10.8.0.1 ತೋರಿಸುತ್ತವೆ. ಮೂಲ ವಿಳಾಸವನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಪದರದಲ್ಲಿ ಕಳುಹಿಸಿ, ಅಥವಾ ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೆ ಲಾಗಿಂಗ್ ನಷ್ಟವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಿ, ಆದರೆ ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ಕಂಡುಹಿಡಿಯುವ ಬದಲು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ಧರಿಸಿ.

ಇಡೀ ಮಾರ್ಗವನ್ನು ಹೊರಗಿನಿಂದ ಪರಿಶೀಲಿಸಿ

VPS ಅಲ್ಲದ, ಮನೆಯೂ ಅಲ್ಲದ ನೆಟ್ವರ್ಕ್ನಿಂದ ಪರಿಶೀಲಿಸಿ: ಮೊಬೈಲ್ ಡೇಟಾದಲ್ಲಿ ಫೋನ್, ಅಥವಾ ಬೇರೆಡೆ ಅಗ್ಗದ shell. nc -vz files.example.net 5022 ಯಶಸ್ವಿ ಸಂಪರ್ಕವನ್ನು ವರದಿ ಮಾಡಬೇಕು, openssl s_client -connect files.example.net:443 -servername files.example.net ಸಾರ್ವಜನಿಕ ಹೆಸರಿಗೆ ಪ್ರಮಾಣಪತ್ರ ತೋರಿಸಬೇಕು. ನಂತರ ಪೂರೈಕೆದಾರರ ಭದ್ರತಾ ಗುಂಪು ಅಥವಾ ಕ್ಲೌಡ್ ಫೈರ್ವಾಲ್ ಪರಿಶೀಲಿಸಿ. ಎಂದಿಗೂ ಪ್ಯಾಕೆಟ್ ನೋಡದ DNAT ನಿಯಮ ಸಾಮಾನ್ಯವಾಗಿ ಹೋಸ್ಟ್ನ ಒಂದು ಪದರ ಮೇಲೆ ನಿರ್ಬಂಧಿಸಲ್ಪಡುತ್ತದೆ.

ಕೊನೆಯದಾಗಿ, ಸುರಂಗ ಬಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ. DNAT ನಿಯಮ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಲೇ ಇರುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಸದ್ದಿಲ್ಲದೆ ಸತ್ತ ಸುರಂಗಕ್ಕೆ ತಳ್ಳುತ್ತದೆ, ಇದು ಹಾಳಾದ ಸೇವೆಯಂತೆಯೇ ಕಾಣುತ್ತದೆ. VPS ನಲ್ಲಿ peer ಕೆಲಸ ಮಾಡುವವರೆಗೆ ಪೋರ್ಟ್ ನಿರಾಕರಿಸುವ ಆರೋಗ್ಯ ಪರಿಶೀಲನೆ ಕೆಲವು ಸಾಲಿನ ವೆಚ್ಚ, ಒಂದು ಗಂಟೆಯ ಊಹೆಯನ್ನು ಉಳಿಸುತ್ತದೆ. ನಂತರ ನಿಯಮಗಳನ್ನು ಸಂಪಾದಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಅದನ್ನು ನಂಬುವ ಮೊದಲು ಒಂದು ದಿನ ಗಮನಿಸಿ.