ਵੱਖਰੀ ਇਗ੍ਰੈਸ: usb0 'ਤੇ VPN ਪੂਲ, eth0 'ਤੇ ਗੇਟਵੇ ਟ੍ਰੈਫਿਕ

ਕਲਾਇੰਟ ਜੁੜਦੇ ਹਨ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦੇ ਹਨ, ਫਿਰ ਉਨ੍ਹਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਗਲਤ ਉੱਪਰਲੀ ਲਿੰਕ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਮਸ਼ੀਨ 'ਤੇ ਇੱਕੋ ਇੱਕ ਡਿਫਾਲਟ ਰੂਟ ਗੇਟਵੇ ਦਾ ਆਪਣਾ ਹੈ। ਉਹ ਡਿਫਾਲਟ ਬਦਲਣ ਨਾਲ ਮਸ਼ੀਨ ਦੇ ਆਪਣੇ ਅਪਡੇਟ ਅਤੇ ਪ੍ਰਬੰਧਨ ਪਹੁੰਚ ਟੁੱਟ ਜਾਵੇਗੀ, ਇਸ ਲਈ ਚੋਣ «ਸਾਰੇ ਟ੍ਰੈਫਿਕ» ਤੋਂ ਸੰਕਰੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਕੰਮ ਕਰਨ ਵਾਲਾ ਰੂਪ ਇੱਕ ਨੀਤੀ ਨਿਯਮ ਹੈ ਜੋ ਕਲਾਇੰਟ ਪੂਲ ਦੇ ਅੰਦਰਲੇ ਸਰੋਤ ਪਤੇ 'ਤੇ ਆਧਾਰਿਤ ਹੈ ਅਤੇ ਵੈਕਲਪਿਕ WAN ਵਾਲੀ ਦੂਜੀ ਰਾਊਟਿੰਗ ਟੇਬਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਉੱਥੋਂ ਅੱਗੇ ਚੈੱਕਲਿਸਟ ਨਿਯਮ ਬਾਰੇ ਨਹੀਂ, ਪੂਰਨਤਾ ਅਤੇ ਅਸਫਲਤਾ ਵੇਲੇ ਵਿਵਹਾਰ ਬਾਰੇ ਹੈ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰੋਤ ਪਤਾ ਰਾਊਟਿੰਗ ਫੈਸਲੇ ਤੱਕ ਰਹਿੰਦਾ ਹੈ

ਸਰੋਤ ਰੇਂਜ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਨੀਤੀ ਨਿਯਮ ਤਦ ਹੀ ਸਰਗਰਮ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਪੈਕਟ ਖੋਜ ਵੇਲੇ ਅਜੇ ਵੀ ਉਹ ਸਰੋਤ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ। ਫਾਰਵਰਡ ਕੀਤਾ ਕਲਾਇੰਟ ਟ੍ਰੈਫਿਕ ਇੰਝ ਕਰਦਾ ਹੈ, ਜਿੰਨਾ ਚਿਰ ਰਾਊਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਉੱਪਰ ਕਿਸੇ ਨੇ ਇਸਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖਿਆ। ਗੇਟਵੇ ਆਪ ਬਣਾਉਂਦਾ ਟ੍ਰੈਫਿਕ ਇੰਝ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਸੇ ਲਈ ਗੇਟਵੇ ਦਾ ਆਪਣਾ ਡਿਫਾਲਟ ਆਪਣੀ ਥਾਂ 'ਤੇ ਰਹਿ ਸਕਦਾ ਹੈ।

ਇੱਥੇ ਹੀ ਸਥਾਨਕ ਟੈਸਟ ਭਰਮ ਵਿੱਚ ਪਾਉਂਦੇ ਹਨ। ਗੇਟਵੇ 'ਤੇ ਚਲਾਇਆ curl ਗੇਟਵੇ ਦੇ ਪਤੇ ਨਾਲ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਬਣਾਇਆ ਪ੍ਰਵਾਹ ਹੈ, ਇਸ ਲਈ ਇਹ ਮੁੱਖ ਟੇਬਲ ਲੈਂਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਰਾਹ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਜੁੜੇ ਕਲਾਇੰਟ ਤੋਂ ਟੈਸਟ ਕਰੋ, ਜਾਂ ਅਜਿਹੇ ਸਰੋਤ ਨਾਲ ਟ੍ਰੈਫਿਕ ਬਣਾਓ ਜੋ ਸੱਚਮੁੱਚ ਪੂਲ ਦਾ ਹੋਵੇ।

ਅਸਲ ਮੁੱਲ ਲਿਖ ਕੇ ਸ਼ੁਰੂ ਕਰੋ: ਪੂਲ ਪ੍ਰੀਫਿਕਸ, ਇਸਨੂੰ ਢੋਣ ਵਾਲਾ ਟਨਲ ਇੰਟਰਫੇਸ, ਦੂਜੇ WAN ਦਾ ਪਤਾ ਅਤੇ ਅਗਲਾ ਹੌਪ, ਅਤੇ ਉਹ ਟੇਬਲ ਨੰਬਰ ਜੋ ਤੁਸੀਂ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਨਵੇਂ ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਵੀ ਪਿਛਲੀ ਕੋਸ਼ਿਸ਼ ਦੇ ਪੁਰਾਣੇ ਨਿਯਮ ਸਾਫ਼ ਕਰੋ, ਕਿਉਂਕਿ ਵੱਖ ਵੱਖ ਤਰਜੀਹਾਂ 'ਤੇ ਦੁਹਰਾਏ ਨਿਯਮ ਅਜਿਹੀਆਂ ਅਸਫਲਤਾਵਾਂ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜੋ ਬੇਤਰਤੀਬ ਲੱਗਦੀਆਂ ਹਨ।

ਪੂਰੀ ਹੋਣ ਵਾਲੀ ਚੁਣੀ ਟੇਬਲ ਬਣਾਓ

ਟੇਬਲ ਦੋਸਤ ਵਾਲਾ ਡਿਫਾਲਟ ਰੂਟ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ ਲੋੜੀਂਦੇ ਰੂਟ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਜੋ ਹਰ ਖੋਜ ਇਸਦੇ ਅੰਦਰ ਹੱਲ ਹੋਵੇ, ਜਿਸ ਵਿੱਚ WAN ਸਬਨੈੱਟ ਦਾ ਜੁੜਿਆ ਰੂਟ ਵੀ ਸ਼ਾਮਲ ਹੈ ਤਾਂ ਜੋ ਅਗਲਾ ਹੌਪ ਪਹੁੰਚਯੋਗ ਹੋਵੇ। tun1 'ਤੇ 10.77.0.0/24 ਪੂਲ, ਅਗਲਾ ਹੌਪ 203.0.113.1 ਵਾਲਾ WAN ਪਤਾ 203.0.113.20/24, ਅਤੇ ਟੇਬਲ 600 ਲਈ:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

ਨਿਯਮ ਕਿਸੇ ਵੀ ਮੌਜੂਦਾ ਸਭ-ਫੜਨ ਵਾਲੇ ਨਿਯਮ ਤੋਂ ਹੇਠਲੀ ਤਰਜੀਹ 'ਤੇ ਬੈਠਦਾ ਹੈ, ਇਸ ਲਈ ਮੇਲ ਖਾਂਦੇ ਕਲਾਇੰਟ ਪਹਿਲਾਂ ਟੇਬਲ 600 'ਤੇ ਪਹੁੰਚਦੇ ਹਨ ਅਤੇ ਬਾਕੀ ਸਭ ਮੁੱਖ ਟੇਬਲ ਵਿੱਚ ਡਿੱਗਦਾ ਹੈ। ip-rule ਸੰਦਰਭ ਕ੍ਰਮਬੱਧ ਖੋਜ ਮਾਡਲ ਅਤੇ ਚੋਣਕਰਤਾ ਵਾਕ ਰਚਨਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਿਆਨ ਕਰਦਾ ਹੈ।

ਫਿਰ ਸੋਚੋ ਕਿ ਟੇਬਲ ਵਿੱਚ ਕੀ ਨਹੀਂ ਹੈ। ਜਿਸ ਮੰਜ਼ਿਲ ਦਾ ਰੂਟ ਸਿਰਫ਼ ਮੁੱਖ ਵਿੱਚ ਹੈ, ਜਿਵੇਂ eth0 ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਪ੍ਰਬੰਧਨ ਸਬਨੈੱਟ, ਉਹ ਟੇਬਲ 600 ਵਿੱਚ ਨਹੀਂ ਮਿਲੇਗਾ ਅਤੇ ਉੱਥੇ ਡਿਫਾਲਟ ਹੋਣ 'ਤੇ ਮੁੱਖ ਵਿੱਚ ਵਾਪਸ ਨਹੀਂ ਜਾਵੇਗਾ। ਜੇ ਉਹ ਰਾਹ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਚੁਣੀ ਟੇਬਲ ਵਿੱਚ ਜੋੜੋ, ਜੋ VPN ਇਗ੍ਰੈਸ ਟੇਬਲ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਸਹੀ ਜਵਾਬ ਹੈ।

ਸਰੋਤੇ ਦਾ ਆਪਣਾ ਟ੍ਰੈਫਿਕ ਨੀਤੀ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

OpenVPN ਸਰੋਤੇ ਦਾ ਆਪਣਾ ਬਾਹਰੀ ਕਨੈਕਸ਼ਨ ਹੁੰਦਾ ਹੈ, ਜੋ ਕਲਾਇੰਟ ਜਿਸ ਉੱਪਰਲੀ ਲਿੰਕ ਰਾਹੀਂ ਪਹੁੰਚਿਆ ਉਸ ਰਾਹੀਂ ਢੋਇਆ ਜਾਂਦਾ ਹੈ। ਉਸ ਟ੍ਰੈਫਿਕ ਨੂੰ ਆਉਣ ਵਾਲਾ ਵਾਪਸੀ ਰਾਹ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਦੇ ਜਨਤਕ ਪਤੇ ਜਾਂ ਪੂਰੇ ਟਨਲ ਇੰਟਰਫੇਸ ਨੂੰ ਢਕਣ ਵਾਲਾ ਖੁੱਲ੍ਹਾ ਨਿਯਮ ਇਸਨੂੰ ਵੈਕਲਪਿਕ ਟੇਬਲ ਵਿੱਚ ਖਿੱਚ ਸਕਦਾ ਹੈ। ਨਿਯਮ ਨੂੰ ਅੰਦਰਲੇ ਪੂਲ ਤੱਕ ਸੀਮਤ ਰੱਖੋ, ਕਿਸੇ ਹੋਰ ਤੱਕ ਨਹੀਂ।

ਉਲਟ ਰਾਹ ਫਿਲਟਰਿੰਗ ਵੀ ਇਸੇ ਕਾਰਨ ਵੇਖਣ ਯੋਗ ਹੈ। ਜਦੋਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਜਵਾਬ usb0 ਰਾਹੀਂ ਜਾਂਦੇ ਹਨ ਪਰ ਬੇਨਤੀ ਕਿਸੇ ਹੋਰ ਲਿੰਕ ਰਾਹੀਂ ਆਈ ਸੀ, ਤਾਂ ਸਖ਼ਤ rp_filter ਸੈਟਿੰਗ ਉਹ ਪੈਕਟ ਸੁੱਟ ਸਕਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਰਾਊਟਿੰਗ ਨੀਤੀ ਵੈਧ ਮੰਨਦੀ ਹੈ। ਨਿਯਮ ਅਸਫਲ ਹੋਇਆ ਅਜਿਹਾ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਇੰਟਰਫੇਸਾਂ 'ਤੇ ਪ੍ਰਭਾਵੀ sysctl ਮੁੱਲ ਜਾਂਚੋ।

ਮਸ਼ੀਨ ਦੀ ਹਰ ਹੋਰ ਚੀਜ਼ ਦੇ ਮੁਕਾਬਲੇ ਕ੍ਰਮ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। Docker ਪੁਲ, ਦੂਜਾ VPN ਅਤੇ ਪ੍ਰਦਾਤਾ ਦੀ ਇਮੇਜ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਕੋਈ ਵੀ ਨਿਯਮ ਸਾਰੇ ਤਰਜੀਹਾਂ ਜੋੜਦੇ ਹਨ, ਇਸ ਲਈ ਤਰਜੀਹ 100 ਇਕੱਲੀ ਹੈ ਮੰਨਣ ਦੀ ਥਾਂ ਪੂਰੀ ਨਿਯਮ ਸੂਚੀ ਪੜ੍ਹੋ।

ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਅਨੁਵਾਦ ਨੂੰ ਰੂਟ ਨਾਲ ਮਿਲਾਓ

ਰਾਊਟਿੰਗ ਇੱਕ ਉੱਪਰਲੀ ਲਿੰਕ ਚੁਣਦੀ ਹੈ; ਇਹ ਫਾਰਵਰਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੀ। ਕਰਨਲ ਵਿੱਚ IPv4 ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਫਾਇਰਵਾਲ ਨੂੰ ਕਲਾਇੰਟ ਤੋਂ WAN ਦਿਸ਼ਾ ਅਤੇ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਪ੍ਰਵਾਹ ਸੁੱਟਣ ਵਾਲੀ FORWARD ਚੇਨ ਨਾਲ ਸਹੀ ਟੇਬਲ ਗੁੰਮ ਰੂਟ ਵਰਗੇ ਹੀ ਲੱਛਣ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਦੋਵੇਂ ਇੱਕੋ ਪਾਸ ਵਿੱਚ ਜਾਂਚੇ ਜਾਂਦੇ ਹਨ।

ਜੇ ਦੂਜਾ WAN ਨਿੱਜੀ ਪੂਲ ਨੂੰ ਤੁਹਾਡੇ ਵੱਲ ਵਾਪਸ ਰਾਊਟ ਨਹੀਂ ਕਰੇਗਾ, ਤਾਂ ਉਸ ਇਗ੍ਰੈਸ 'ਤੇ ਸਰੋਤ ਦਾ ਅਨੁਵਾਦ ਕਰੋ। ਗਤੀਸ਼ੀਲ ਪਤੇ ਵਾਲੇ ਇੰਟਰਫੇਸ ਲਈ ਪੂਲ ਅਤੇ ਇੰਟਰਫੇਸ ਤੱਕ ਸੀਮਤ ਸੰਕਰਾ masquerade ਨਿਯਮ ਆਮ ਚੋਣ ਹੈ:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

ਇੱਥੇ ਨਿਸ਼ਾਨੇ ਨਾਲੋਂ ਦਾਇਰਾ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਕਿਸੇ ਵੀ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ masquerade ਨਿਯਮ eth0 ਰਾਹੀਂ ਸਹੀ ਜਾਂਦਾ ਟ੍ਰੈਫਿਕ ਵੀ ਦੁਬਾਰਾ ਲਿਖੇਗਾ, ਅਤੇ ਇਹ ਰਾਊਟਿੰਗ ਗਲਤੀਆਂ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਥਾਂ ਲੁਕਾਉਂਦਾ ਹੈ। ਅਨੁਵਾਦ ਰਾਊਟਿੰਗ ਫੈਸਲੇ ਮਗਰੋਂ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਗਲਤ ਉੱਪਰਲੀ ਲਿੰਕ 'ਤੇ ਭੇਜੇ ਪੈਕਟ ਨੂੰ ਇਹ ਕਦੇ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਰਾਹ ਵੱਖਰੇ ਹੋਣ 'ਤੇ ਟਨਲ ਓਵਰਹੈੱਡ ਵੀ ਧਿਆਨ ਮੰਗਦਾ ਹੈ। ਜੇ ਕਲਾਇੰਟ ਵੱਡਾ TCP MSS ਤੈਅ ਕਰਦੇ ਹਨ ਅਤੇ ਵੈਕਲਪਿਕ WAN ਦਾ MTU ਘੱਟ ਹੈ ਜਾਂ ਇਸਦੇ ਅੰਦਰ ਟਨਲ ਹੈ, ਤਾਂ ਵੱਡੇ ਖੰਡ ਅਟਕਦੇ ਹਨ ਅਤੇ ਛੋਟੇ ਕੰਮ ਕਰਦੇ ਹਨ। ਫਾਰਵਰਡਿੰਗ ਰਾਹ 'ਤੇ MSS ਕਲੈਂਪ ਕਰਨ ਨਾਲ ਇਹ ਕਦੇ ਕਦੇ ਅਟਕਣ ਦੀ ਥਾਂ ਅੰਦਾਜ਼ੇਯੋਗ ਵਿਵਹਾਰ ਬਣ ਜਾਂਦਾ ਹੈ।

usb0 ਗਾਇਬ ਹੋਣ 'ਤੇ ਕੀ ਹੋਵੇਗਾ ਇਹ ਤੈਅ ਕਰੋ

ਖਾਲੀ ਟੇਬਲ ਅਸਫਲਤਾ 'ਤੇ ਬੰਦ ਹੋਣ ਵਾਲੀ ਹਾਲਤ ਨਹੀਂ ਹੈ। ਜੇ ਮੇਲ ਖਾਂਦਾ ਰੂਟ ਗਾਇਬ ਹੋ ਜਾਵੇ, ਤਾਂ ਖੋਜ ਅਗਲੇ ਨਿਯਮ ਵੱਲ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ, ਮੁੱਖ ਟੇਬਲ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ ਅਤੇ eth0 ਦਾ ਡਿਫਾਲਟ ਲੈ ਲੈਂਦੀ ਹੈ। ਜਿਹੜਾ ਟ੍ਰੈਫਿਕ ਦੂਜੇ WAN ਰਾਹੀਂ ਜਾਣਾ ਸੀ ਉਹ ਚੁੱਪਚਾਪ ਪਹਿਲੇ ਰਾਹੀਂ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਨੀਤੀ-ਰਾਊਟਿਡ ਤੈਨਾਤੀ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਇਹੀ ਸਭ ਤੋਂ ਘੱਟ ਚਾਹਿਆ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ।

ਜਿੱਥੇ ਇਹ ਵਾਪਸ ਡਿੱਗਣਾ ਸਵੀਕਾਰਯੋਗ ਨਹੀਂ, ਉੱਥੇ ਟੇਬਲ 600 ਵਿੱਚ ਸਪਸ਼ਟ ਟਰਮਿਨਲ ਰੂਟ ਜੋੜੋ, ਜਿਵੇਂ blackhole ਡਿਫਾਲਟ, ਜਾਂ ਇੰਟਰਫੇਸ ਬੰਦ ਹੁੰਦਿਆਂ ਫਾਇਰਵਾਲ ਵਿੱਚ ਪੂਲ ਸੁੱਟ ਦਿਓ। ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਹੋ ਜਿਹਾ ਫੈਸਲਾ ਹੈ ਜੋ ਤੁਸੀਂ ਲਿਖ ਸਕਦੇ ਹੋ; ਚੁੱਪ ਨਹੀਂ।

ਟਿਕਾਊਪਣ ਆਖਰੀ ਨੁਕਤਾ ਹੈ। ਦੋਵੇਂ ਲਿੰਕਾਂ ਦਾ ਮਾਲਕ ਜੋ ਵੀ ਹੋਵੇ, ਭਾਵੇਂ ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਹੋਵੇ, ਡਿਸਪੈਚਰ ਸਕ੍ਰਿਪਟ ਹੋਵੇ ਜਾਂ ਕਨੈਕਸ਼ਨ ਦਾ ਜੀਵਨ ਚੱਕਰ, ਉਸਨੂੰ ਹਰ ਦੁਬਾਰਾ ਜੁੜਨ 'ਤੇ ਨਕਲ ਜੋੜੇ ਬਿਨਾਂ ਰੂਟ ਅਤੇ ਨਿਯਮ ਮੁੜ ਬਣਾਉਣੇ ਪੈਣਗੇ। ਅਸਲ ਕਲਾਇੰਟ ਤੋਂ ਬੇਨਤੀ ਅਤੇ ਗੇਟਵੇ ਤੋਂ ਵੱਖਰੀ ਬੇਨਤੀ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ, ਦੋਹਾਂ ਵਿੱਚ ਵੇਖਿਆ ਇਗ੍ਰੈਸ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਦੂਜਾ WAN ਖਿੱਚੋ ਅਤੇ ਵੇਖੋ ਕਿ ਤੁਸੀਂ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਦੋ ਨਤੀਜਿਆਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਸੱਚਮੁੱਚ ਹੁੰਦਾ ਹੈ। IPv6 ਨੂੰ ਆਪਣੀ ਟੇਬਲ, ਨਿਯਮ ਅਤੇ ਅਨੁਵਾਦ ਚਾਹੀਦਾ ਹੈ; ਉੱਪਰਲਾ IPv4 ਨਿਯਮ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।