ਟਨਲ ਰਾਹੀਂ ਦੂਰ ਦੇ /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ਐਂਟਰੀ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਪੜ੍ਹੋ: ਅਸਲ tuple ਮੰਜ਼ਿਲ ਉੱਤੇ ਤੁਹਾਡਾ ਅਲਿਆਸ ਰੱਖਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਜਵਾਬ tuple ਅਸਲ ਪਤਾ ਚੁੱਕਦੀ ਹੈ। ਜੇ ਜਵਾਬ tuple ਨਹੀਂ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਨਿਯਮ ਨਹੀਂ, ਵਾਪਸੀ ਰਾਹ ਹੈ। ਜੇ PREROUTING ਕਾਊਂਟਰ ਕਦੇ ਨਹੀਂ ਹਿਲੇ, ਤਾਂ ਪੈਕਟ ਉਸ hook ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਿਆ।
ਟਕਰਾਅ ਅਤੇ ਪਹਿਲਾਂ ਚੱਲਣ ਵਾਲੀ ਖੋਜ
ਦੋ ਵੱਖਰੀਆਂ ਰੇਂਜਾਂ ਟਕਰਾ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਅਸਫਲਤਾਵਾਂ ਮਾੜੇ ਨਿਯਮ ਦੀ ਬਜਾਏ ਟੁੱਟੇ ਟਨਲ ਵਰਗੀਆਂ ਦਿਸਦੀਆਂ ਹਨ। ਤੁਹਾਡਾ ਬਣਾਇਆ ਅਲਿਆਸ ਪੂਰੇ ਰਾਹ ਵਿੱਚ ਵਰਤਿਆ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ, ਅਤੇ ਅਸਲ ਦੂਰ ਵਾਲੀ ਰੇਂਜ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਉੱਤੇ ਪਹਿਲਾਂ ਹੀ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਦੁਹਰਾਅ ਕਦੇ-ਕਦੇ ਗਲਤ ਹੋਸਟ ਵੱਲ ਟ੍ਰੈਫਿਕ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਜਿਸਨੂੰ ਰੱਦ ਕੀਤੇ ਕਨੈਕਸ਼ਨ ਨਾਲੋਂ ਜਾਂਚਣਾ ਔਖਾ ਹੈ। ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਰੂਟਿੰਗ ਟੇਬਲ ਨੂੰ ਪੁੱਛੋ।
ਗੇਟਵੇ ਉੱਤੇ, ip route get 192.168.2.17 ਨੂੰ ਟਨਲ ਡਿਵਾਈਸ ਦਾ ਨਾਮ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ; ਸਥਾਨਕ bridge ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਦੂਰ ਵਾਲੀ ਰੇਂਜ ਢਕੀ ਹੋਈ ਹੈ ਅਤੇ ਕੋਈ 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 ਨਿਰਭਰਤਾ ਮੁੜ ਲੱਭਣਾ ਨਹੀਂ।