NAT ಹಿಂದಿನ WireGuard ಪೀರ್ಗೆ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್: DNAT ಮತ್ತು SNAT

ಒಂದು ಬ್ರೌಸರ್ https://203.0.113.10:8443 ಅನ್ನು ವಿನಂತಿಸುತ್ತದೆ, ಪ್ರಾಕ್ಸಿ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು WireGuard ಪೀರ್ನಲ್ಲಿನ ಸೇವೆ ಎಂದಿಗೂ ಪ್ರತ್ಯುತ್ತರ ನೀಡುವುದಿಲ್ಲ. DNAT ನಿಯಮ ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ; ವಿಫಲವಾಗುವ ಭಾಗ ಪ್ರತ್ಯುತ್ತರ. ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಎರಡೂ ಅನುವಾದಗಳ ಮೂಲಕ ಅನುಸರಿಸಿ ಮತ್ತು ಕಾಣೆಯಾದ ನಿಯಮ ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಪರಿಹಾರ ಸರಿಯಾದ ಹುಕ್ನಲ್ಲಿ ಇನ್ನೊಂದು NAT ಹೇಳಿಕೆ, ಹೊಸ ಟನೆಲ್ ಅಲ್ಲ.

ಒಂದು ವಿನಂತಿಯನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಅನುಸರಿಸಿ

ವಿನಂತಿ ಪ್ರಾಕ್ಸಿಯ ಸಾರ್ವಜನಿಕ ಇಂಟರ್ಫೇಸ್ಗೆ ಬರುತ್ತದೆ, ಮೂಲದಲ್ಲಿ ಕ್ಲೈಂಟ್ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದಲ್ಲಿ ಪ್ರಾಕ್ಸಿಯ ವಿಳಾಸ ಇರುತ್ತದೆ. nat PREROUTING ನಲ್ಲಿ DNAT ನಿಯಮ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪೀರ್ನ ಟನೆಲ್ ವಿಳಾಸ 10.90.0.2 ಗೆ ಮರುಬರೆಯುತ್ತದೆ. ನಂತರ ರೌಟಿಂಗ್ ನಿರ್ಧಾರ ಪ್ಯಾಕೆಟ್ ಅನ್ನು wg0 ಮೂಲಕ ಹೊರಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾರ್ಗ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ.

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

ಅಸಮಮಿತಿಯೇ ಇಡೀ ಸಮಸ್ಯೆ: ವಿನಂತಿ ಪ್ರಾಕ್ಸಿಯ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಪ್ರತ್ಯುತ್ತರ ನೇರವಾಗಿ ಹೋಗಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಪ್ರಾಕ್ಸಿಯ ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್ ಪ್ರತ್ಯುತ್ತರ ಪ್ರಾಕ್ಸಿಯ ಮೂಲಕ ಹಿಂತಿರುಗಿದಾಗ ಮಾತ್ರ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಮೂಲ ವಿಳಾಸ ಇನ್ನೂ ಮೂಲ ಕ್ಲೈಂಟ್ ಕಡೆ ತೋರಿಸುತ್ತಿರುವಾಗ ಅದು ಅಲ್ಲಿಗೆ ಹಿಂತಿರುಗಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಹಿಂತಿರುಗುವ ಅನುವಾದ ಸೇರಿಸಿ

ಫಾರ್ವರ್ಡ್ ಆದ ಹರಿವಿನ ಮೂಲವನ್ನು ಪೀರ್ ಕಡೆ ಹೊರಡುವ ಮೊದಲು ಪ್ರಾಕ್ಸಿಯ ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಮರುಬರೆಯಿರಿ. ನಂತರ ಸೇವೆ 10.90.0.1 ಗೆ ಪ್ರತ್ಯುತ್ತರಿಸುತ್ತದೆ, ಪ್ರಾಕ್ಸಿ ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಕ್ಲೈಂಟ್ಗೆ ಹಿಂತಿರುಗುವ ಮೊದಲು ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್ ಎರಡೂ ಅನುವಾದಗಳನ್ನು ತಿರುಗಿಸುತ್ತದೆ.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

POSTROUTING ನಿಯಮ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಂಕುಚಿತವಾಗಿದೆ: ಅದು ಅನುವಾದಿತ ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ಗೆ ಹೊಂದುತ್ತದೆ, ಆದ್ದರಿಂದ wg0 ಮೂಲಕ ಆಕಸ್ಮಿಕವಾಗಿ ಹೊರಡುವ ಅಸಂಬಂಧಿತ ಸಂಚಾರವನ್ನು ಮರುಬರೆಯುವುದಿಲ್ಲ. ವಿಶಾಲ masquerade ನಿಯಮ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನೂ ಮರೆಮಾಡುತ್ತಿತ್ತು, ಆದರೆ ಅದನ್ನು ಪ್ರತಿ ಹರಿವಿಗೂ ಮಾಡುತ್ತಿತ್ತು ಮತ್ತು NAT ಕೋಷ್ಟಕದ ಪರಿಶೀಲನೆಯನ್ನು ಕಷ್ಟಕರಗೊಳಿಸುತ್ತಿತ್ತು.

ಟನೆಲ್ ಇರುವಲ್ಲೇ ನಿಯಮಗಳನ್ನು ಇರಿಸಿ

ಟನೆಲ್ ವಿಳಾಸ ಅಥವಾ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುವ ನಿಯಮಗಳು wg-quick ಅದನ್ನು ಸಂರಚಿಸಿದ ನಂತರ ಚಲಿಸಬೇಕು. ಇಂಟರ್ಫೇಸ್ PreUp ಮೊದಲು ರಚನೆಯಾಗುತ್ತದೆ, ಆದರೆ ವಿಳಾಸಗಳು, MTU, DNS ಮತ್ತು ಮಾರ್ಗಗಳು ನಂತರ ಅನ್ವಯವಾಗುತ್ತವೆ, ಮತ್ತು ಅವೆಲ್ಲವೂ ಸ್ಥಳದಲ್ಲಿದ್ದಾಗ PostUp ಚಲಿಸುತ್ತದೆ. ಸೇರಿಸುವಿಕೆಗಳನ್ನು PostUp ನಲ್ಲಿ ಮತ್ತು ತೆಗೆಯುವಿಕೆಗಳನ್ನು PreDown ನಲ್ಲಿ ಇರಿಸಿ.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

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

ಫಲಿತಾಂಶವನ್ನು iptables -t nat -S ಬಳಸಿ ಮರುಸಂಪರ್ಕದ ನಂತರ ಪರಿಶೀಲಿಸಿ. ಅದೇ ನಿಯಮ ಎರಡು ಬಾರಿ ಕಾಣಿಸಿಕೊಂಡರೆ PreDown ಸಾಲು ಹೊಂದುತ್ತಿಲ್ಲ ಮತ್ತು ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ ಮೌನವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ.

ಫಾರ್ವರ್ಡಿಂಗ್, ಫಿಲ್ಟರಿಂಗ್ ಮತ್ತು ಇನ್ನೊಂದು NAT

IPv4 ಫಾರ್ವರ್ಡಿಂಗ್ ಅನ್ನು ಶಾಶ್ವತವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಿ, ನಂತರ ಫಿಲ್ಟರ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಫಾರ್ವರ್ಡ್ ಆದ ಹರಿವಿಗೆ ಅನುಮತಿ ನೀಡಿ. DNAT FORWARD ಸರಪಳಿಗಿಂತ ಮೊದಲು ಸಂಭವಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಫಿಲ್ಟರ್ ನಿಯಮ ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ಬದಲು ಅನುವಾದಿತ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಹೊಂದುತ್ತದೆ. UFW ಫೈರ್ವಾಲ್ ನಿರ್ವಹಿಸಿದರೆ, ಅನುಮತಿಯನ್ನು ರೂಟ್ ನಿಯಮವಾಗಿ ವ್ಯಕ್ತಪಡಿಸಿ; ಸಾಮಾನ್ಯ ಹೋಸ್ಟ್ ನಿಯಮ ಫಾರ್ವರ್ಡ್ ಆದ ಸಂಚಾರವನ್ನು ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ.

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

NAT VPS ನಲ್ಲಿ ಪೂರೈಕೆದಾರರು ಸಾರ್ವಜನಿಕ ಪೋರ್ಟ್ ಅನ್ನು ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಮ್ಯಾಪ್ ಮಾಡುತ್ತಾರೆ. ಮ್ಯಾಪಿಂಗ್ ನೀವು ಘೋಷಿಸುವ ಪೋರ್ಟ್ಗೆ ಹೊಂದಿರಬೇಕು, ಮತ್ತು ಅಸಾಮರಸ್ಯ ಮುರಿದ ಟನೆಲ್ನಂತೆಯೇ ಕಾಣುತ್ತದೆ. WireGuard ಸಂರಚನೆ ಬದಲಿಸುವ ಮೊದಲು ಪೂರೈಕೆದಾರರ ಮ್ಯಾಪಿಂಗ್ ದೃಢೀಕರಿಸಿ.

ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ವೆಚ್ಚ ಒಪ್ಪಿಕೊಳ್ಳಿ

ಪ್ರಾಕ್ಸಿಯ LAN ಅಲ್ಲದ ನೆಟ್ವರ್ಕ್ನಿಂದ ಸಂಪರ್ಕಿಸಿ, ನಂತರ ಸಂಪರ್ಕ ತೆರೆದಿರುವಾಗ ಅನುವಾದ ಜೋಡಿಯನ್ನು ಪರಿಶೀಲಿಸಿ:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

conntrack ನಮೂದು ಮೂಲ tuple, ಅನುವಾದಿತ tuple ಮತ್ತು ಪ್ರತ್ಯುತ್ತರದ ದಿಕ್ಕನ್ನು ತೋರಿಸಬೇಕು. ಪ್ರತ್ಯುತ್ತರ ಇಲ್ಲದಿದ್ದರೆ ಪೀರ್ ಟನೆಲ್ ಮೂಲಕ ಕಳುಹಿಸುತ್ತಿಲ್ಲ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ SNAT ನಿಯಮ ಅನ್ವಯವಾಗಿಲ್ಲ ಅಥವಾ ಪೀರ್ನ ಸ್ವಂತ ಫೈರ್ವಾಲ್ ಹರಿವನ್ನು ಎಸೆದಿದೆ ಎಂದರ್ಥ.

PostUp ನಿಯಮಗಳನ್ನು ಮತ್ತೆ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಲು ಒಮ್ಮೆ ಮರುಬೂಟ್ ಮಾಡಿ, ನಂತರ ಟನೆಲ್ ನಿಲ್ಲಿಸಿ ಮತ್ತು PreDown ಅವುಗಳನ್ನು ತೆಗೆದಿದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ಸಂಪರ್ಕ ಕಡಿತದ ನಂತರ ಉಳಿಯುವ ಸತ್ತ ನಿಯಮಗಳೇ ನಂತರದ ಬದಲಾವಣೆ ಅನಿರೀಕ್ಷಿತವಾಗಿ ವರ್ತಿಸಲು ಕಾರಣ.

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