SNAT, DNAT ਅਤੇ Masquerade: ਹਰ VPN 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 ਪਤਾ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਦੁਹਰਾਓ।