ಟನೆಲ್ ಮೂಲಕ ದೂರದ /24 ತಲುಪುವುದು: NETMAP, DNAT ಅಥವಾ ರೂಟ್?
NETMAP ನೊಂದಿಗೆ ಇಡೀ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಮ್ಯಾಪ್ ಮಾಡಿ, ಪ್ರತಿ ಹೋಸ್ಟ್ಗೆ DNAT ನಿಯಮಗಳನ್ನು ಸೇರಿಸಿ ಅಥವಾ ನಿಜವಾದ ಶ್ರೇಣಿಯನ್ನು ರೂಟ್ ಮಾಡಿ, ಮತ್ತು ದೂರದ ಬದಿ ಏನನ್ನು ನೋಡಬೇಕು ಹಾಗೂ ಯಾರು ಸಂಚಾರವನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು ಎಂಬುದರಿಂದ ನಿರ್ಧರಿಸಿ.
ಟನೆಲ್ ಎಂಡ್ಪಾಯಿಂಟ್ನ ಹಿಂದಿನ ಸಬ್ನೆಟ್ಗೆ ನೀವು ಮೂರು ರೀತಿಯಲ್ಲಿ ತಲುಪಬಹುದು, ಮತ್ತು ಒಂದು ನಿಮಿಷದ ವಾಸ್ತವಾಂಶ ಸಂಗ್ರಹ ಸಾಮಾನ್ಯವಾಗಿ ಎರಡನ್ನು ತಳ್ಳಿಹಾಕುತ್ತದೆ. ವಾಸ್ತವಾಂಶಗಳೆಂದರೆ ಅಲ್ಲಿನ ಸರ್ವರ್ಗಳು ಬಳಕೆದಾರರನ್ನು ಪ್ರತ್ಯೇಕಿಸಬೇಕೇ, ಅಲ್ಲಿನ ಯಾರಾದರೂ ನಿಮ್ಮ ಶ್ರೇಣಿಯ ಕಡೆಗೆ ಎಂದಾದರೂ ಸಂಪರ್ಕಿಸುತ್ತಾರೆಯೇ, ಮತ್ತು ದೂರದ ರೂಟರ್ ಅನ್ನು ಯಾರು ಸಂಪಾದಿಸಬಹುದು. ಈ ಮೂರಕ್ಕೆ ಉತ್ತರಿಸಿ, ವಿನ್ಯಾಸವೇ ಆಯ್ಕೆಯಾಗುತ್ತದೆ. ಉಳಿದದ್ದು ನೀವು ಎಂಡ್ಪಾಯಿಂಟ್ ನಡೆಸುತ್ತೀರಿ ಮತ್ತು ಅದರ ಫೈರ್ವಾಲ್ ಸಂಪಾದಿಸಬಹುದು ಎಂದು ಊಹಿಸುತ್ತದೆ.
ಮೂರು ಆಯ್ಕೆಗಳು, ಮತ್ತು ಪ್ರತಿಯೊಂದು ನಿಜವಾಗಿ ಏನನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ
ಪ್ರಿಫಿಕ್ಸ್ ಮ್ಯಾಪಿಂಗ್, ಪ್ರತಿ ಹೋಸ್ಟ್ಗೆ DNAT ಮತ್ತು ರೂಟ್ ಮಾಡಿದ ಪ್ರಿಫಿಕ್ಸ್ ಎಲ್ಲವೂ ಒಂದೇ ಎರಡು ಶ್ರೇಣಿಗಳ ನಡುವೆ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸಾಗಿಸುತ್ತವೆ, ಆದರೆ ಬೇರೆ ಬೇರೆ ವಿಷಯಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ. ಮ್ಯಾಪಿಂಗ್ ಒಂದು ಅಲಿಯಾಸ್ ಶ್ರೇಣಿಯನ್ನು ಸೃಷ್ಟಿಸಿ, ಹಾರಾಟದಲ್ಲಿ ವಿಳಾಸಗಳನ್ನು ಅಂಕಗಣಿತದಂತೆ ಮತ್ತೆ ಬರೆಯುತ್ತದೆ. ಪ್ರತಿ ಹೋಸ್ಟ್ ನಿಯಮಗಳೂ ಮತ್ತೆ ಬರೆಯುತ್ತವೆ, ಆದರೆ ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಕೈಯಿಂದ ಹೆಸರಿಸಲಾಗುತ್ತದೆ. ರೂಟ್ ಮಾಡಿದ ಪ್ರಿಫಿಕ್ಸ್ ಏನನ್ನೂ ಮತ್ತೆ ಬರೆಯುವುದಿಲ್ಲ: ಪ್ಯಾಕೆಟ್ಗಳು ನಿಜವಾದ ವಿಳಾಸಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಎರಡೂ ತುದಿಗಳು ಆ ವಿಳಾಸಗಳು ಎಲ್ಲಿವೆ ಎಂಬುದನ್ನು ಒಪ್ಪುತ್ತವೆ.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
ತೆಗೆದುಹಾಕುವಿಕೆಯನ್ನು ದೂರದ ಬದಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಅಲ್ಲಿ ನಿರ್ಬಂಧಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ಅತ್ಯಂತ ಕಷ್ಟ. ಅಲ್ಲಿನ ಸರ್ವರ್ ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳನ್ನು ಲಾಗ್ಗಳಲ್ಲಿ ಬರೆದರೆ, ಅನುಮತಿ ಪಟ್ಟಿಯೊಂದಿಗೆ ಹೋಲಿಸಿದರೆ, ಅಥವಾ ಇನ್ನೊಂದು ವ್ಯವಸ್ಥೆಗೆ ಒಪ್ಪಿಸಿದರೆ, ಮೂಲವನ್ನು ಭಾಷಾಂತರಿಸುವುದು ಅದರ ಏಕೈಕ ಗುರುತನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ. ದೂರದ ಬದಿಯೂ ಒಳಗೆ ಸಂಪರ್ಕಿಸಬೇಕಾದರೆ, ಭಾಷಾಂತರ ಸಂಪೂರ್ಣವಾಗಿ ಅಸಾಧ್ಯ, ಏಕೆಂದರೆ ಅಲ್ಲಿ ಅಲಿಯಾಸ್ ಇದೆ ಎಂದು ಯಾರಿಗೂ ಗೊತ್ತಿಲ್ಲ. ದೂರದ ಬದಿ ಕೇವಲ ವಿನಂತಿಗಳಿಗೆ ಉತ್ತರಿಸಿದಾಗ ಮಾತ್ರ ಅಗ್ಗದ ಆಯ್ಕೆಗಳು ಸುರಕ್ಷಿತವಾಗುತ್ತವೆ.
ಪ್ರಿಫಿಕ್ಸ್ ಜೋಡಿಗಳು, ಮತ್ತು ಗಾತ್ರಗಳು ಏಕೆ ಹೊಂದಬೇಕು
NETMAP ಎಂಬುದು ಒಂದೇ ಉದ್ದದ ಪ್ರಿಫಿಕ್ಸ್ಗಳ ಜೋಡಿಯ ಮೇಲೆ ಕೆಲಸ ಮಾಡುವ nat ಟೇಬಲ್ ಗುರಿ. ಅದರೊಳಗೆ ಪ್ರತಿ ವಿಳಾಸದ ಟೇಬಲ್ ಇಲ್ಲ: ಅದು ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ತೆಗೆದು, ಹೋಸ್ಟ್ ಬಿಟ್ಗಳನ್ನು ಉಳಿಸಿ, ಹೊಸ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಮತ್ತೆ ಜೋಡಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ /24 /24 ಮೇಲೆ ಮ್ಯಾಪ್ ಆಗುತ್ತದೆ ಮತ್ತು ಎಂದಿಗೂ /25 ಮೇಲೆ ಆಗುವುದಿಲ್ಲ. ಸ್ಥಾನವು ದಿಕ್ಕನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ: PREROUTING ನಲ್ಲಿ ಗಮ್ಯಸ್ಥಾನ ಹೊಂದಿಕೆಯು ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂಬುದನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ, ಮತ್ತು POSTROUTING ನಲ್ಲಿ ಮೂಲ ಹೊಂದಿಕೆಯು ಅದು ಎಲ್ಲಿಂದ ಬಂತು ಎಂಬುದನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ.
192.168.2.17 ನಲ್ಲಿರುವ ಹೋಸ್ಟ್ ನಿಮ್ಮ ಕ್ಲೈಂಟ್ಗಳಿಗೆ 10.50.1.17 ಆಗಿ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಕೊನೆಯ ಆಕ್ಟೆಟ್ ಅಲಂಕಾರವಲ್ಲ — ಅದು ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಒಂದೇ ಸಂಖ್ಯೆ. ನಾಳೆ 192.168.2.40 ನಲ್ಲಿ ಹೋಸ್ಟ್ ಸೇರಿಸಿ, ಅದರ ಅಲಿಯಾಸ್ 10.50.1.40 ಆಗಿರುತ್ತದೆ, ಸಂಪಾದಿಸಬೇಕಾದ ನಿಯಮವಿಲ್ಲ.
ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಅಲಿಯಾಸ್ ಶ್ರೇಣಿಗೆ ನಿಮ್ಮ ಬಾಕ್ಸ್ನ ಕಡೆಗೆ ತೋರಿಸುವ ರೂಟ್ ಇನ್ನೂ ಬೇಕು, ಅಲಿಯಾಸ್ ಅವರು ಈಗಾಗಲೇ ತಲುಪುವ ಸಬ್ನೆಟ್ ಒಳಗಿದ್ದರೆ ಹೊರತುಪಡಿಸಿ. ಗೇಟ್ವೇಗೆ ಅಲಿಯಾಸ್ಗೆ ರೂಟ್ ಬೇಕಿಲ್ಲ, ಏಕೆಂದರೆ ಗಮ್ಯಸ್ಥಾನ ಭಾಷಾಂತರವು ರೂಟ್ ಶೋಧನೆಗಿಂತ ಮೊದಲು PREROUTING ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ. ಫಾರ್ವರ್ಡಿಂಗ್ ಕೂಡ ಆನ್ ಆಗಿರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಮತ್ತೆ ಬರೆದ ನಂತರ ಕರ್ನಲ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಬಿಡುತ್ತದೆ. ಕೆಳಗಿನ ಮೂರು ಆಜ್ಞೆಗಳು ಕ್ಲೈಂಟ್ಗಳು br0 ನಲ್ಲಿ, ಅಲಿಯಾಸ್ 10.50.1.0/24 ನಲ್ಲಿ ಮತ್ತು ಟನೆಲ್ tun0 ನಲ್ಲಿರುವ Debian ಶೈಲಿಯ ಗೇಟ್ವೇನ ಸಂಪೂರ್ಣ ಸಂರಚನೆ.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEಪ್ರತಿಕ್ರಿಯೆ ತಾನೇ ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಕಂಡುಕೊಳ್ಳಬೇಕು
ಗಮ್ಯಸ್ಥಾನವನ್ನು ಮತ್ತೆ ಬರೆಯುವುದು ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿ ತಲುಪಿಸಲ್ಪಡುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತದೆ. ದೂರದ ಸರ್ವರ್ ತಾನು ತಲುಪಬಲ್ಲ ವಿಳಾಸಕ್ಕೆ ಉತ್ತರಿಸಬೇಕು, ಮತ್ತು ಅದನ್ನು ಏರ್ಪಡಿಸಲು ಎರಡು ದಾರಿಗಳಿವೆ. ಪ್ರತಿಕ್ರಿಯೆಗಳು ನಿಮ್ಮ ಬಾಕ್ಸ್ಗೆ ಮರಳಲು ಮೂಲವನ್ನು ಭಾಷಾಂತರಿಸಿ, ಅಥವಾ ಮೂಲವನ್ನು ಹಾಗೆಯೇ ಬಿಟ್ಟು ದೂರದ ಬದಿಗೆ ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿಯ ರೂಟ್ ನೀಡಿ.
ಹೊರಹೋಗುವ masquerade ಚಿಕ್ಕ ದಾರಿ: POSTROUTING ನಲ್ಲಿ ಒಂದು ನಿಯಮ ಮತ್ತು ದೂರದ ಬದಿ ನಿಮ್ಮ ಟನೆಲ್ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದಕ್ಕೆ ಸ್ವಂತ ರೂಟ್ ಬೇಕಿಲ್ಲ. ಬೆಲೆ ಎಂದರೆ ಪ್ರತಿ ಬಳಕೆದಾರರೂ ಒಂದೇ ವಿಳಾಸಕ್ಕೆ ಕುಸಿಯುತ್ತಾರೆ, ಮತ್ತು ಪ್ರತಿ ಬಳಕೆದಾರರ ಲಾಗ್ಗಳು ಅರ್ಥ ಕಳೆದುಕೊಳ್ಳುತ್ತವೆ. ಮೂಲವನ್ನು ಹಾಗೆಯೇ ಉಳಿಸಿದರೆ ಆ ಮಾಹಿತಿ ಉಳಿಯುತ್ತದೆ, ಆದರೆ ಆಗ ದೂರದ ಸೈಟ್ ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿಯ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಟನೆಲ್ ಮೂಲಕ ಹಿಂತಿರುಗಿಸಬೇಕು.OpenVPN ಸರ್ವರ್ನಲ್ಲಿ ಅದು push ಮಾಡಲಾದ push "route 10.50.9.0 255.255.255.0", ಜೊತೆಗೆ route 192.168.2.0 255.255.255.0 ಸಾಲು.
ದುಬಾರಿ ವೈಫಲ್ಯ ಎಂದರೆ ಪ್ರತಿಯೊಂದರ ಅರ್ಧ ಮಾಡುವುದು. ಕೆಲವು ಸಂಚಾರವನ್ನು masquerade ಮಾಡುತ್ತಾ ದೂರದ ಬದಿ ಇತರ ಸಂಚಾರಕ್ಕೆ ಹಿಂತಿರುಗುವ ರೂಟ್ ಅನ್ನೂ ಹೊತ್ತಿದ್ದರೆ, ಪ್ರತಿಕ್ರಿಯೆಗಳು ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್ ನಮೂದು ಎಂದಿಗೂ ಕಂಡಿರದ ಇಂಟರ್ಫೇಸ್ಗೆ ಬರುತ್ತವೆ. ಸರ್ವರ್ ಸೇವೆ ಮಾಡಿದೆ ಎಂದು ದಾಖಲಿಸಿದ ವಿನಂತಿಗೆ ಕ್ಲೈಂಟ್ ಟೈಮ್ಔಟ್ ವರದಿ ಮಾಡುತ್ತದೆ. ಹರಿವಿನ ಎರಡೂ ದಿಕ್ಕುಗಳು ಒಂದೇ netfilter ಇನ್ಸ್ಟೆನ್ಸ್ ಮೂಲಕ ಹಾದುಹೋಗಬೇಕು: ಒಂದು ಗೇಟ್ವೇ ಭಾಷಾಂತರಿಸುತ್ತದೆ, ಸರಣಿಯಲ್ಲಿ ಎರಡು ಫೈರ್ವಾಲ್ಗಳಲ್ಲ.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nನಮೂದನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಓದಿ: ಮೂಲ ಟ್ಯೂಪಲ್ ಗಮ್ಯಸ್ಥಾನದಲ್ಲಿ ನಿಮ್ಮ ಅಲಿಯಾಸ್ ಉಳಿಸುತ್ತದೆ, ಪ್ರತಿಕ್ರಿಯೆ ಟ್ಯೂಪಲ್ ನಿಜವಾದ ವಿಳಾಸವನ್ನು ಹೊರುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆ ಟ್ಯೂಪಲ್ ಇಲ್ಲದಿದ್ದರೆ, ಸಮಸ್ಯೆ ನಿಯಮವಲ್ಲ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗ. PREROUTING ಕೌಂಟರ್ಗಳು ಎಂದಿಗೂ ಚಲಿಸದಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಆ ಹುಕ್ ತಲುಪಲಿಲ್ಲ.
ಘರ್ಷಣೆಗಳು ಮತ್ತು ಮೊದಲು ಓಡುವ ಶೋಧನೆ
ಎರಡು ವಿಭಿನ್ನ ಶ್ರೇಣಿಗಳು ಘರ್ಷಿಸಬಹುದು, ಮತ್ತು ಎರಡೂ ವೈಫಲ್ಯಗಳು ಕೆಟ್ಟ ನಿಯಮಕ್ಕಿಂತ ಮುರಿದ ಟನೆಲ್ನಂತೆ ಕಾಣುತ್ತವೆ. ನೀವು ಸೃಷ್ಟಿಸುವ ಅಲಿಯಾಸ್ ಇಡೀ ಮಾರ್ಗದಲ್ಲಿ ಬಳಕೆಯಾಗದಿರಬೇಕು, ಮತ್ತು ನಿಜವಾದ ದೂರದ ಶ್ರೇಣಿ ನಿಮ್ಮ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಈಗಾಗಲೇ ಇರಬಾರದು. ನಕಲು ತುಣುಕು ತಡೆದು ಬರುವ ತಪ್ಪು ಹೋಸ್ಟ್ ಸಂಚಾರವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಅದನ್ನು ನಿರಾಕರಿಸಿದ ಸಂಪರ್ಕಕ್ಕಿಂತ ವಿಶ್ಲೇಷಿಸುವುದು ಕಷ್ಟ. ನಿಯಮ ಸೇರಿಸುವ ಮೊದಲು ರೂಟಿಂಗ್ ಟೇಬಲ್ಗೆ ಕೇಳಿ.
ಗೇಟ್ವೇನಲ್ಲಿ, ip route get 192.168.2.17 ಟನೆಲ್ ಸಾಧನವನ್ನು ಹೆಸರಿಸಬೇಕು; ಸ್ಥಳೀಯ ಬ್ರಿಡ್ಜ್ ಎಂದರೆ ದೂರದ ಶ್ರೇಣಿ ಮರೆಯಾಗಿದೆ ಮತ್ತು ಯಾವುದೇ nat ನಿಯಮ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ನೆಟ್ವರ್ಕ್ ಈಗಾಗಲೇ 192.168.2.0/24 ಬಳಸುತ್ತಿದ್ದರೆ, ಘರ್ಷಣೆಯ ಮೇಲೆ ಮ್ಯಾಪಿಂಗ್ ಜೋಡಿಸುವ ಬದಲು ದೂರದ ಸೈಟ್ ಅನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡಿ.
ನಿಜವಾದ ಕ್ಲೈಂಟ್ನಿಂದ ಪರೀಕ್ಷಿಸಿ, ನಂತರ ಉಳಿಸಿಕೊಳ್ಳಿ
ಅಲಿಯಾಸ್ ಅನ್ನು ನಿಜವಾಗಿ ಬಳಸುವ ಯಂತ್ರದಿಂದ ಪರೀಕ್ಷಿಸಿ, ಗೇಟ್ವೇನಿಂದ ಅಲ್ಲ, ಏಕೆಂದರೆ ಸ್ಥಳೀಯವಾಗಿ ಉತ್ಪಾದಿಸಿದ ಸಂಚಾರ PREROUTING ಅನ್ನು ಎಂದಿಗೂ ಅದೇ ರೀತಿ ದಾಟುವುದಿಲ್ಲ. ಅಲಿಯಾಸ್ ಇರುವ ಒಂದು ಹೋಸ್ಟ್ಗೆ ಸಂಪರ್ಕ ತೆರೆದು ಕೌಂಟರ್ಗಳು ಮತ್ತು conntrack ನಮೂದು ಒಟ್ಟಿಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುವುದನ್ನು ನೋಡಿ, ನಂತರ ಮುಚ್ಚಿ ನಮೂದು ಹೋಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಹಳೆಯ ನಮೂದು ಅರೆ-ತೆರೆದ ಸಂಪರ್ಕವನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಅಂದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿಕ್ರಿಯೆ ಹಿಂತಿರುಗಲಿಲ್ಲ.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17ಎರಡು ಅಥವಾ ಮೂರು ಯಶಸ್ವಿ ಸಂಪರ್ಕಗಳು ಅಂಕಗಣಿತವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ, ಆದರೆ ಸ್ಥಿರತೆ ಅಥವಾ ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ನಿಯಮಗಳನ್ನು ಬೂಟ್ ಪ್ರಕ್ರಿಯೆ ಓದುವ ಸ್ಥಳದಲ್ಲಿ ಉಳಿಸಿ, Debian ಮತ್ತು Ubuntu ನಲ್ಲಿ ಅದು iptables-save > /etc/iptables/rules.v4 ಅನ್ನು netfilter-persistent ಸಕ್ರಿಯಗೊಳಿಸಿ ಎಂದರ್ಥ. ಮರುಬೂಟ್ನಲ್ಲಿ ಮಾಯವಾಗುವ ಮ್ಯಾಪಿಂಗ್ ಇಲ್ಲದಿರುವುದಕ್ಕಿಂತ ಕೆಟ್ಟದು, ಏಕೆಂದರೆ ಅಡಚಣೆ ದೂಷಿಸಲು ಇತ್ತೀಚಿನ ಬದಲಾವಣೆಯಿಲ್ಲದೆ ಬರುತ್ತದೆ.
ನಿಯಮಗಳ ಪಕ್ಕದಲ್ಲಿ ಟಿಪ್ಪಣಿ ಬಿಡಿ: ಅಲಿಯಾಸ್ ಶ್ರೇಣಿ, ನಿಜವಾದ ಶ್ರೇಣಿ, ಜೋಡಿಯ ಕಾರಣ ಮತ್ತು ಯಾವ ಬದಿ ಪ್ರಾರಂಭಿಸಬಹುದು. ಆ ಟಿಪ್ಪಣಿ ವಿನ್ಯಾಸವನ್ನು ಯಾರೂ ಅಳಿಸಲು ಧೈರ್ಯಪಡದ ನಿಯಮಗಳ ರಾಶಿಯಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಅದು ನಂತರದ ಪ್ರಶ್ನೆಯನ್ನೂ ಬಗೆಹರಿಸುತ್ತದೆ, ದೂರದ ಸೈಟ್ ಹೋಸ್ಟ್ ಸೇರಿಸಿದಾಗ ಮತ್ತು ಯಾರೂ ಸಂರಚಿಸದ ವಿಳಾಸ ಈಗಾಗಲೇ ಉತ್ತರಿಸಿದಾಗ. ಟಿಪ್ಪಣಿ ದೂರದ ಬದಿಗೆ ಹಿಂತಿರುಗುವ ರೂಟ್ ಬೇಕು ಎಂದು ಹೇಳಿದರೆ, ಮುಂದಿನ ವ್ಯಕ್ತಿ masquerade ನಿಯಮ ತೆಗೆದರೆ ಸಂಪರ್ಕ ಮುರಿಯುತ್ತದೆ ಎಂದು ತಿಳಿಯುತ್ತಾರೆ. ಇಲ್ಲಿ ದಾಖಲೀಕರಣ ಅಗ್ಗ; ರಾತ್ರಿ ಮೂರಕ್ಕೆ NAT ಅವಲಂಬನೆಯನ್ನು ಮತ್ತೆ ಕಂಡುಹಿಡಿಯುವುದು ಅಗ್ಗವಲ್ಲ.