SNAT, DNAT ಮತ್ತು Masquerade: ಪ್ರತಿ VPN NAT ನಿಯಮ ಏನು ಮಾಡುತ್ತದೆ

ಮೂಲ NAT ಪ್ರವಾಹ ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ ಎಂದು ತೋರುವುದನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ; ಗಮ್ಯ NAT ಅದು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ. Masquerade ಎರವಲು ಪಡೆದ ವಿಳಾಸದೊಂದಿಗಿನ ಮೂಲ NAT ಆಗಿದೆ.

VPN ಗೇಟ್‌ವೇಯ ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಕ್ಯಾಪ್ಚರ್ ಇರಿಸಿ ಮತ್ತು ಒಂದು ಹರಿವು ನಾಲ್ಕು ವಿಭಿನ್ನ ವಿಳಾಸಗಳನ್ನು ತೋರಿಸಬಹುದು. ಮೂಲ NAT ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ ಎಂದು ಹೇಳಿಕೊಳ್ಳುತ್ತದೆಯೋ ಅದನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ; ಗಮ್ಯ NAT ಅದು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ. Masquerade ಮೂರನೇ ದಿಕ್ಕಲ್ಲ, ಸ್ಥಿರ ಮೌಲ್ಯದ ಬದಲು ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್‌ನ ವಿಳಾಸವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮೂಲ NAT ನಿಯಮವಾಗಿದೆ. ಮೂರರಲ್ಲಿ ನಿಮಗೆ ನಿಜವಾಗಿ ಯಾವುದು ಬೇಕು ಎಂದು ಹೆಸರಿಸಿ ಮತ್ತು ಬಹುಪಾಲು «VPN ಮುರಿದಿದೆ» ಟಿಕೆಟ್‌ಗಳು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ಪ್ರಶ್ನೆಯಾಗಿ ಮಾರ್ಪಡುತ್ತವೆ.

ಪ್ರತಿ ನಿಯಮ ಏನನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ

ಮೂಲ NAT, ಸಾಮಾನ್ಯವಾಗಿ SNAT ಎಂದು ಬರೆಯಲಾಗುತ್ತದೆ, ಹರಿವು ರೂಟರ್ ಅಥವಾ ಗೇಟ್‌ವೇ ಬಿಡುವಾಗ ಅದರ ಮೂಲ ವಿಳಾಸವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಸ್ವೀಕರಿಸುವ ಸೇವೆ ಅನುವಾದಿತ ವಿಳಾಸಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಅನುವಾದಿಸುವ ಪೆಟ್ಟಿಗೆ ಆ ಸಂಪರ್ಕಕ್ಕಾಗಿ ಇಟ್ಟುಕೊಂಡ ಸ್ಥಿತಿಯಿಂದ ಬದಲಾವಣೆಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. Linux ನಲ್ಲಿ ಆ ಸ್ಥಿತಿ conntrack ನಲ್ಲಿ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ conntrack -L ಮೂಲ ಮತ್ತು ಉತ್ತರ ಜೋಡಿಗಳನ್ನು ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ಮುದ್ರಿಸುತ್ತದೆ.

ಗಮ್ಯ NAT, DNAT, ಬದಲಿಗೆ ಗಮ್ಯವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. UDP 51820 ನಲ್ಲಿ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು 10.8.0.2:51820 ನಲ್ಲಿನ ಆಂತರಿಕ WireGuard ಸರ್ವರ್‌ಗೆ ಮತ್ತೆ ಬರೆಯಬಹುದು. ಮನೆಯ ರೂಟರ್ ಅಥವಾ ಕ್ಲೌಡ್ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ VPN ಶ್ರೋತೃವನ್ನು ಈ ರೀತಿ ಪ್ರಕಟಿಸುತ್ತದೆ ಮತ್ತು ಇದು ಟನೆಲ್ ಮುಂದೆ ಏನನ್ನು ಸಾಗಿಸಬಹುದು ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

Masquerade SNAT ಕುಟುಂಬಕ್ಕೆ ಸೇರಿದೆ. ನಿಯಮ ಯಾವುದೇ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುವುದಿಲ್ಲ; ಪ್ಯಾಕೆಟ್ ಹೊರಡುವಾಗ ಹೊರಹೋಗುವ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿರುವ ವಿಳಾಸವನ್ನು ಬಳಸುತ್ತದೆ. Linux ಅದಕ್ಕೆ ತನ್ನದೇ ಗುರಿಯನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು DHCP ಅಥವಾ PPPoE ಯಿಂದ ವಿಳಾಸ ಪಡೆಯುವ WAN ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಇದು ಸಾಮಾನ್ಯ ಆಯ್ಕೆ.

ಮ್ಯಾಪಿಂಗ್ ಎಲ್ಲಿದೆ ಎಂಬುದು ವೈಫಲ್ಯವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ

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

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

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

Masquerade ಅಥವಾ ಸ್ಪಷ್ಟ SNAT

ಎರಡನ್ನೂ ಅವು ಭರವಸೆ ನೀಡುವುದರ ಮೂಲಕ ಹೋಲಿಸಿ. Masquerade ನಿರ್ಗಮನ ವಿಳಾಸವನ್ನು ಆರಿಸುತ್ತದೆ, ಸ್ಪಷ್ಟ SNAT ಅದನ್ನು ಪಿನ್ ಮಾಡುತ್ತದೆ. ಸ್ಥಿರ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವಿರುವ ಗೇಟ್‌ವೇಯಲ್ಲಿ ಪಿನಿಂಗ್ ಲಾಗ್‌ಗಳಿಗೆ ಮತ್ತು ಪಾಲುದಾರರ ಅನುಮತಿ ಪಟ್ಟಿಗಳಿಗೆ ಒಂದು ಊಹಿಸಬಹುದಾದ ಮೌಲ್ಯವನ್ನು ನೀಡುತ್ತದೆ. ಕ್ರಿಯಾಶೀಲ WAN ಲಿಂಕ್‌ನಲ್ಲಿ ಪಿನ್ ಮಾಡಿದ SNAT ವಿಳಾಸವು ಲೀಸ್ ಬದಲಾದ ಕ್ಷಣ ತಪ್ಪಾಗುತ್ತದೆ ಮತ್ತು Masquerade ನಿಖರವಾಗಿ ಆ ಸಂದರ್ಭಕ್ಕಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ.

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

ನೀತಿ ಆಧಾರಿತ IPsec ನಲ್ಲಿ ಇದು ಹೆಚ್ಚು ಕಚ್ಚುತ್ತದೆ. strongSwan ನ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಮಾರ್ಗದರ್ಶಿ IP ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಮೂಲ NAT ನಿಯಮ ಸೇರಿಸುವುದನ್ನು ಹಂತ ಹಂತವಾಗಿ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ದಾಖಲೆ ತನ್ನ ಮೂಲ ವಿಳಾಸವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬೇಕಾದ ಸಂಚಾರವನ್ನು ಹೊರಗಿಡುವುದನ್ನೂ ಒಳಗೊಳ್ಳುತ್ತದೆ. ಭದ್ರತಾ ನೀತಿ ಅದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ ಮೊದಲೇ ಮೂಲವನ್ನು ಅನುವಾದಿಸಿ ಮತ್ತು ಟನೆಲ್ ಮೇಲೆ ಬರಬಹುದು, ಆದರೆ ಸಂಚಾರ ಇನ್ನೂ ಬೀಳುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ಯಾಕೆಟ್ ಇನ್ನು ಮುಂದೆ ಸಮಾಲೋಚಿಸಿದ ಆಯ್ಕೆದಾರನಂತೆ ಕಾಣುವುದಿಲ್ಲ.

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

Linux ಗೇಟ್‌ವೇಯಲ್ಲಿ ನಿಯಮಗಳನ್ನು ಓದುವುದು

10.8.0.0/24 ನಲ್ಲಿ ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು eth0 ಎಂಬ ಹೆಸರಿನ WAN ಇಂಟರ್ಫೇಸ್ ಇರುವ ದೂರಸ್ಥ ಪ್ರವೇಶ ಗೇಟ್‌ವೇಗೆ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವಿಕೆ ಸಕ್ರಿಯವಾಗಿರಬೇಕು ಮತ್ತು ಹರಿವಿಗೆ ಅನುಮತಿ ನೀಡುವ ಫಿಲ್ಟರ್ ನೀತಿ ಬೇಕು, ಆಗ ಮಾತ್ರ ಯಾವುದೇ NAT ನಿಯಮ ಸಹಾಯ ಮಾಡಬಹುದು. iptables ಆವೃತ್ತಿ ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು nat ಕೋಷ್ಟಕದಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables ರೂಪವು ಅದೇ ಎರಡು ಕೊಕ್ಕೆಗಳನ್ನು ಹೆಸರಿಸಿದ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಸ್ಪಷ್ಟ ಸರಪಳಿಯೊಂದಿಗೆ ಬಳಸುತ್ತದೆ:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

ಎರಡೂ ತುಣುಕುಗಳು ಫಿಲ್ಟರ್ ಸರಪಳಿ ಈಗಾಗಲೇ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿದ ಹರಿವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದು ಊಹಿಸುತ್ತವೆ. NAT ಅನುಮತಿ ನಿಯಮವಲ್ಲ, ಮತ್ತು ಸರಿಯಾಗಿ ಅನುವಾದಿತ ಪ್ಯಾಕೆಟ್ ಸಹ ಒಂದು ಕೋಷ್ಟಕದ ನಂತರ ತಿರಸ್ಕರಿಸಲ್ಪಡಬಹುದು. ಜೀವಂತ ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು conntrack -L ನಿಂದ ದೃಢೀಕರಿಸಿ, ಏನು ಲೋಡ್ ಆಗಿದೆ ಎಂಬುದನ್ನು nft list ruleset ಅಥವಾ iptables-save -t nat ನಿಂದ ದೃಢೀಕರಿಸಿ, ನಂತರ ವಿಳಾಸ ನಿಜವಾಗಿ ಬದಲಾಗುವುದನ್ನು ನೋಡಲು ಎರಡೂ ಇಂಟರ್ಫೇಸ್‌ಗಳಲ್ಲಿ ಕ್ಯಾಪ್ಚರ್ ಮಾಡಿ.

ಕೆಟ್ಟ ನಿಯಮದಂತೆ ಕಾಣುವ ವೈಫಲ್ಯ ಮಾದರಿಗಳು

ಹೇರ್‌ಪಿನ್ ಸಂಚಾರ ಕ್ಲಾಸಿಕ್. ಸರ್ವರ್‌ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ಮೂಲಕ ಆಂತರಿಕ ಸರ್ವರ್‌ಗೆ ತಲುಪುವ ಆಂತರಿಕ ಕ್ಲೈಂಟ್‌ಗೆ ಒಳಬರುವ ದಾರಿಯಲ್ಲಿ DNAT ಮತ್ತು ಹಿಂತಿರುಗಿ ಹೊರಹೋಗುವ ದಾರಿಯಲ್ಲಿ ಮೂಲ ಅನುವಾದ ಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಸರ್ವರ್ ನೇರವಾಗಿ ಕ್ಲೈಂಟ್‌ಗೆ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಉತ್ತರ ತಿರಸ್ಕೃತವಾಗುತ್ತದೆ. ಪರಿಹಾರ ಆ ಆಂತರಿಕ-ದಿಂದ-ಸಾರ್ವಜನಿಕ ಸಂದರ್ಭಕ್ಕೆ ಎರಡನೇ, ಸಣ್ಣ ನಿಯಮ, ಎಲ್ಲದಕ್ಕೂ ಅಗಲವಾದ Masquerade ನಿಯಮವಲ್ಲ.

ಎರಡು ಪಟ್ಟು ಅನುವಾದ ನಿಶ್ಶಬ್ದವಾದದ್ದು. ಈಗಾಗಲೇ ವಾಹಕ-ಶ್ರೇಣಿಯ NAT ಹಿಂದೆ ಇರುವ ಕ್ಲೈಂಟ್ ನಿಮ್ಮ ಗೇಟ್‌ವೇಗೆ ಹಿಂತಿರುಗಿ ಮಾರ್ಗನಿರ್ದೇಶಿಸಲಾಗದ ವಿಳಾಸದೊಂದಿಗೆ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ಮತ್ತೆ ಅನುವಾದಿಸುತ್ತೀರಿ. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಲಾಗ್‌ಗಳು ಈಗ ಖಾಸಗಿ ವಿಳಾಸೀಕರಣದ ಎರಡು ಜಿಗಿತಗಳನ್ನು ಹೊತ್ತಿರುತ್ತವೆ ಮತ್ತು ಯಾವುದೇ ತನಿಖೆಗೆ ಎರಡೂ ಮ್ಯಾಪಿಂಗ್‌ಗಳು ಬೇಕು. ನೀತಿ ಆಧಾರಿತ IPsec ಮೂರನೇ ತಿರುವು ಸೇರಿಸುತ್ತದೆ: ನೀತಿ ಹೊಂದಿಕೆಗಿಂತ ಮೊದಲು ಅನುವಾದಿಸಿ ಮತ್ತು ಸಂಚಾರ ಹಾದುಹೋಗದೆಯೇ ಮೇಲೆದ್ದ SA ಸಿಗುತ್ತದೆ, ಇದು NAT ನದಲ್ಲ, ಫೈರ್‌ವಾಲ್‌ನ ದೋಷದಂತೆ ಓದಲ್ಪಡುತ್ತದೆ.

ನಂತರ ಉತ್ತೀರ್ಣವಾಗುವ ಪರೀಕ್ಷೆ ಮತ್ತು ವಿಫಲವಾಗುವ ನಿಯೋಜನೆ ಇದೆ. NAT ಆಜ್ಞೆಯನ್ನು ಕೈಯಿಂದ ಓಡಿಸುವುದು ಕಾರ್ಯವಿಧಾನವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಸಂರಚನೆಯನ್ನಲ್ಲ. ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಸೇರಿಸಿದ ನಿಯಮ ಮರುಬೂಟ್‌ನಲ್ಲಿ ಅಥವಾ ಮುಂದಿನ ಇಂಟರ್ಫೇಸ್ ಘಟನೆಯಲ್ಲಿ ಮಾಯವಾಗುತ್ತದೆ, ಮತ್ತು ಸಂಖ್ಯೆ ಬದಲಾಗುವ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಬಂಧಿಸಿದ Masquerade ನಿಯಮ ದೂರದ ತುದಿ ನೋಡುವ ವಿಳಾಸವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬದಲಾಯಿಸಬಹುದು. ನಿಯಮವನ್ನು ಅದನ್ನು ಹೊಂದಿರುವ ಫೈರ್‌ವಾಲ್‌ನ ಸಂರಚನೆಯಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಪುನಃ ಪರೀಕ್ಷಿಸಿ.

ನಿಯಮ ಉಳಿಸುವ ಮೊದಲು ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

ಮೊದಲು ದಿಕ್ಕನ್ನು ಹೆಸರಿಸಿ: ಮೂಲ, ಗಮ್ಯ ಅಥವಾ ಎರಡೂ. ನಂತರ ಸ್ಥಿತಿಯನ್ನು ಯಾರು ಇಟ್ಟುಕೊಳ್ಳಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ — ಗೇಟ್‌ವೇ, ಮೇಲಿನ ರೂಟರ್ ಅಥವಾ IPsec ಸಹಚರ — ಮತ್ತು ಉತ್ತರ ಮಾರ್ಗ ಅದರ ಮೂಲಕ ಹಿಂತಿರುಗುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ನಿಯಮವನ್ನು ನೀವು ನಿಜವಾಗಿ ಉದ್ದೇಶಿಸಿದ ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿ, ಗಮ್ಯ ಮತ್ತು ಇಂಟರ್ಫೇಸ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ಮತ್ತು ದೂರದ ತುದಿ ಗೇಟ್‌ವೇಯನ್ನು ನೋಡಬೇಕೋ ಮೂಲ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ನೋಡಬೇಕೋ ಮೊದಲೇ ನಿರ್ಧರಿಸಿ.

ಗೇಟ್‌ವೇಯಿಂದಲ್ಲ, ಕ್ಲೈಂಟ್‌ನಿಂದ ಪರೀಕ್ಷಿಸಿ. ಗೇಟ್‌ವೇಯಲ್ಲಿನ ಬ್ರೌಸರ್ ಕ್ಲೈಂಟ್ ಅನುವಾದ ನಿಯಮವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸದೆ ಇರಬಹುದು, ಆದ್ದರಿಂದ ಅಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಪುಟ ಟನೆಲ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್‌ನಿಂದ ಹೊರಟ ಒಂದು ವಿನಂತಿ ಕಳುಹಿಸಿ, ಕೌಂಟರ್‌ಗಳು ಮತ್ತು conntrack ಕೋಷ್ಟಕವನ್ನು ಗಮನಿಸಿ, ಮತ್ತು ನೀವು ಕೆಲಸ ಮಾಡುವಲ್ಲಿ ಒಂದಾದರೂ ಸಾಧ್ಯವಿದ್ದರೆ ಟನೆಲ್ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಂಡ ನಂತರ ಮತ್ತು WAN ವಿಳಾಸ ಬದಲಾದ ನಂತರ ಪುನರಾವರ್ತಿಸಿ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು