VPN ਕਲਾਇੰਟਾਂ ਨੂੰ ਟਨਲ ਉੱਤੇ ਇੱਕ ਦੂਜੇ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਰੋਕੋ

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

ਸਾਂਝੀ ਸੇਵਾ ਤੱਕ ਦਾ ਰਸਤਾ ਪੀਅਰਾਂ ਵਿਚਕਾਰ ਇਜਾਜ਼ਤ ਨਹੀਂ

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

ਇਸ ਲਈ ਸਿਰਫ਼ ਰਸਤੇ ਪੜ੍ਹਨ ਵਾਲੀ ਅਲੱਗਾਉਣ ਜਾਂਚ ਕੁਝ ਵੀ ਸਿੱਧ ਨਹੀਂ ਕਰਦੀ। /24 ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਪੀਅਰਾਂ ਵਿਚਕਾਰ ਹਰ ਪੈਕੇਟ ਫਾਰਵਰਡ ਹੁੱਕ ਉੱਤੇ ਸੁੱਟਿਆ ਜਾਂਦਾ ਹੈ। ਖ਼ਤਰਨਾਕ ਹਾਲਤ ਉਲਟੀ ਹੈ: ਕੋਈ ਸਪੱਸ਼ਟ ਨਿਯਮ ਨਹੀਂ, ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਡਿਫ਼ਾਲਟ ਹੈ, ਅਤੇ ਅਲੱਗਾਉਣ ਸਿਰਫ਼ ਇਸ ਲਈ ਮੌਜੂਦ ਹੈ ਕਿਉਂਕਿ ਕਿਸੇ ਨੇ ਇਸਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ।

ਟਰਮੀਨਲ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਲਿਖੋ। ਸੇਵਾ ਬਲਾਕ ਅਤੇ ਜੰਪ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚੋ, ਕਲਾਇੰਟ ਬਲਾਕ ਅੰਦਰ ਕਿਤੇ ਹੋਰ ਨਾ ਪਹੁੰਚੋ।

ਪਤਾ ਲਗਾਓ ਕਿ ਪੀਅਰ ਪੈਕੇਟ ਅਸਲ ਵਿੱਚ ਕੌਣ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ

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

WireGuard ਪਹਿਲੇ ਸਮੂਹ ਵਿੱਚ ਹੈ: ਇਸ ਵਿੱਚ ਪੀਅਰ-ਤੋਂ-ਪੀਅਰ ਸਵਿੱਚ ਨਹੀਂ, ਇਸ ਲਈ 10.8.0.4 ਤੋਂ 10.8.0.5 ਤੱਕ ਪੈਕੇਟ wg0 ਉੱਤੇ ਆਉਂਦਾ ਹੈ, ਫਾਰਵਰਡ ਹੁੱਕ ਨੂੰ ਲੱਗਦਾ ਹੈ ਅਤੇ ਜਦੋਂ AllowedIPs ਦੋਵੇਂ ਪਤੇ ਢੱਕਦਾ ਹੈ ਤਾਂ ਦੁਬਾਰਾ wg0 ਤੋਂ ਰਸਤਾ ਬਣਦਾ ਹੈ। OpenVPN ਦੂਜਾ ਸਮੂਹ ਹੈ, ਸਰਵਰ ਸੰਰਚਨਾ ਵਿੱਚ client-to-client ਸੈੱਟ ਹੋਣ ਉੱਤੇ, ਕਿਉਂਕਿ ਉਹ ਨਿਰਦੇਸ਼ ਪੈਕੇਟ ਨੂੰ ਵਰਤੋਂਕਾਰ ਥਾਂ ਵਿੱਚ ਸੈਸ਼ਨਾਂ ਵਿਚਕਾਰ ਸੌਂਪਦਾ ਹੈ। ਕੁਝ ਵੀ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਲੋਡ ਹੋਈ ਸੰਰਚਨਾ ਵਿੱਚ ਉਹ ਨਿਰਦੇਸ਼ ਜਾਂਚੋ। ਜੋ ਕਰਨਲ ਨਿਯਮ ਕਦੇ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਦੇਖਦਾ, ਉਸਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਨਿਯਮ ਤੋਂ ਵੱਖ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਅਤੇ ਇਸੇ ਤਰ੍ਹਾਂ ਇੱਕ ਤੈਨਾਤੀ ਬਿਨਾਂ ਕਿਸੇ ਅਲੱਗਾਉਣ ਦੇ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ।

ਜਿਸ ਫਾਈਲ ਨੂੰ ਤੁਸੀਂ ਲੋਡ ਹੋਇਆ ਮੰਨਦੇ ਹੋ, ਉਸ ਦੀ ਥਾਂ ਪ੍ਰਭਾਵੀ ਸੰਰਚਨਾ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਡਿਸਟਰੋ ਪੈਕੇਜ ਆਪਣੇ ਸਮਾਵੇਸ਼ ਲਿਆਉਂਦੇ ਹਨ। ਜੇ ਡੈਮਨ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ, ਤਾਂ ਵਰਜਨ ਉਸਦੇ ਆਪਣੇ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਨਿਯੰਤਰਣਾਂ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਹੋਸਟ ਫਾਇਰਵਾਲ ਸਿਰਫ਼ ਹੋਸਟ ਵੱਲ ਭੇਜੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਛਾਂਟਦਾ ਹੈ। ਜੇ ਕਰਨਲ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ, ਤਾਂ ਫਾਰਵਰਡ ਹੁੱਕ ਹੀ ਇੱਕੋ ਮਹੱਤਵਪੂਰਨ ਥਾਂ ਹੈ।

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

ਹਰ ਪਤੇ ਨੂੰ ਆਪਣੇ ਆਪ ਰੱਦ ਹੋ ਸਕਣ ਵਾਲੀ ਪਛਾਣ ਦਿਓ

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

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

ਵਰਜਨ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਪੈਕੇਟ ਟਨਲ ਪਾਰ ਕਰਦਾ ਹੈ

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

nftables ਨਾਲ ਜੋੜੀ ਮੌਜੂਦਾ inet filter ਸਾਰਣੀ ਵਿੱਚ ਜਾਂਦੀ ਹੈ, ਪਹਿਲਾਂ ਇਜਾਜ਼ਤ ਅਤੇ ਫਿਰ ਸੁੱਟਣਾ। ਦੋਵੇਂ ਮੇਲ ਪਤਿਆਂ ਦੇ ਨਾਲ ਇੰਟਰਫ਼ੇਸ ਜੋੜੀ ਵੀ ਪਿੰਨ ਕਰਦੇ ਹਨ।

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

ਲੋਡ ਕਰਨ ਤੋਂ ਬਾਅਦ ਐਗਜ਼ਿਟ ਸਥਿਤੀ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਲੜੀ ਦੁਬਾਰਾ ਪੜ੍ਹੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਦੋਵੇਂ ਨਿਯਮ ਤੁਹਾਡੇ ਚਾਹੇ ਕ੍ਰਮ ਵਿੱਚ ਹਨ। IPv6 ਪੂਲ ਲਈ ਮੇਲ ਖਾਂਦੇ ip6 ਨਿਯਮ ਜੋੜੋ, ਨਹੀਂ ਤਾਂ ਦੋਹਰੇ ਸਟੈਕ ਟਨਲ ਉੱਤੇ v4 ਜੋੜੀ ਸਿਰਫ਼ ਸਜਾਵਟ ਹੈ। ਜੇ ਸਰਵਰ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲੀ ਫਾਰਵਰਡ ਨੀਤੀ ਹੈ, ਤਾਂ ਲੜੀ ਪੂਰੀ ਬਦਲਣ ਦੀ ਥਾਂ ਸੁੱਟਣਾ ਜੋੜੋ।

OpenVPN ਉੱਤੇ client-to-client ਸਮਰੱਥ ਹੋਣ ਵੇਲੇ, ਇਹ ਫਾਰਵਰਡ ਨਿਯਮ ਪੀਅਰ ਟ੍ਰੈਫਿਕ ਨਾਲ ਕਦੇ ਨਹੀਂ ਮਿਲਦੇ ਅਤੇ ਵਰਜਨ ਡੈਮਨ ਦੇ ਆਪਣੇ ਨਿਯੰਤਰਣਾਂ ਵਿੱਚ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਹੋਸਟ ਵੱਲ ਭੇਜੇ ਟ੍ਰੈਫਿਕ ਲਈ ਕਰਨਲ ਨਿਯਮ ਰੱਖੋ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਅਲੱਗਾਉਣ ਨਿਯੰਤਰਣ ਨਾ ਗਿਣੋ।

ਵਰਜਨ ਸਰਵਰ ਤੋਂ ਨਹੀਂ, ਕਲਾਇੰਟ ਤੋਂ ਸਿੱਧ ਕਰੋ

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

ਇਜਾਜ਼ਤ ਵਾਲੇ ਕਲਾਇੰਟ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੇਵਾ ਆਪਣੇ ਪੋਰਟ ਉੱਤੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਉਸੇ ਕਲਾਇੰਟ ਤੋਂ ਪੀਅਰ ਦਾ ਪਤਾ ਅਜ਼ਮਾਓ ਅਤੇ ਨਕਾਰ ਦੀ ਥਾਂ ਚੁੱਪ ਸੁੱਟਣ ਦੀ ਉਮੀਦ ਰੱਖੋ:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

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