WireGuard ਪੂਰਾ ਟਨਲ: AllowedIPs 0.0.0.0/0 ਕਾਫ਼ੀ ਨਹੀਂ

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

ਪੀਅਰ ਪ੍ਰੀਲਿਕਸ ਕੀ ਚੁਣਦਾ ਹੈ, ਅਤੇ ਕੀ ਨਹੀਂ

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

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

ਕਲਾਇੰਟ ਨੂੰ ਰੂਟ ਕਰਨਾ, ਸਿਰਫ਼ ਪੀਅਰ ਸੂਚੀ ਨਹੀਂ

ਜਿਵੇਂ ਕਿ wg-quick ਵਰਗੇ ਮੈਨੇਜਰ ਹੋਸਟ ਦੀ ਰੂਟਿੰਗ ਸਾਰਣੀ ਤੁਹਾਡੀ ਤਰਫ਼ੋਂ ਪ੍ਰੋਗਰਾਮ ਕਰਦੇ ਹਨ, ਇਸੇ ਲਈ ਦੋ ਇੱਕੋ ਜਿਹੀਆਂ ਕੌਨਫਿਗਰੇਸ਼ਨ ਫ਼ਾਈਲਾਂ ਇੰਟਰਫ਼ੇਸ ਕਿਵੇਂ ਉੱਪਰ ਆਇਆ ਇਸ ਆਧਾਰ ’ਤੇ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੀਆਂ ਹਨ। ਘੱਟੋ-ਘੱਟ ਪ੍ਰੋਫ਼ਾਈਲ ਇੱਕੋ ਸਾਹে ਪੜ੍ਹਨ ਜੋਗੀ ਛੋਟੀ ਹੈ:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

ਕੰਮ ਦੋ ਵੇਰਵੇ ਚੁੱਕਦੇ ਹਨ। Address ਖੇਤਰ ਕਲਾਇੰਟ ਆਪਣਾ ਸਮਝਦਾ ਹੈ ਅਜਿਹਾ ਸਬਨੈੱਟ ਨਹੀਂ, ਇੱਕੋ ਹੋਸਟ ਪ੍ਰੀਲਿਕਸ ਹੈ, ਅਤੇ ਮੈਨੇਜਰ ਹੀ ਡਿਫ਼ਾਲਟ AllowedIPs ਨੂੰ ਅਸਲ ਡਿਫ਼ਾਲਟ ਰੂਟ ਵਿੱਚ ਬਦਲਦਾ ਹੈ। ਉਹੀ ਫ਼ਾਈਲ ip link ਅਤੇ wg setconf ਨਾਲ ਉੱਪਰ ਲਿਆਓ ਅਤੇ ਕੋਈ ਵੀ ਰੂਟ ਨਹੀਂ ਦਿਸੇਗਾ, ਜੋ ਟੁੱਟੇ ਟਨਲ ਵਾਂਗ ਲੱਗਦਾ ਹੈ ਪਰ ਅਸਲ ਵਿੱਚ ਰੂਟਿੰਗ ਕਦਮ ਛੱਡਿਆ ਹੋਇਆ ਸਿਹਤਮੰਦ ਟਨਲ ਹੈ। wg-quick ਪੁਸਤਿਕਾ ਰੂਟਿੰਗ ਅਤੇ Table ਵਿਵਹਾਰ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦੀ ਹੈ, ਜੋ ਉਹ ਮੈਨੇਜਰ ਜੋੜਦੇ ਹਨ।

ਫ਼ਾਈਲ ਨਹੀਂ, ਨਤੀਜਾ ਪੜ੍ਹੋ: ip route get 1.1.1.1 ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ wg show ਚੱਲਦੇ ਟ੍ਰਾਂਸਫ਼ਰ ਕਾਊਂਟਰ ਨਾਲ ਹਾਲੀਆ ਹੈਂਡਸ਼ੇਕ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ। ਰੂਟ ਤੋਂ ਬਿਨਾਂ ਹੈਂਡਸ਼ੇਕ ਦਾ ਮਤਲਬ ਹੈ ਮੈਨੇਜਰ ਕਦੇ ਨਹੀਂ ਚੱਲਿਆ, ਅਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਦੁਬਾਰਾ ਸੋਧਣ ਨਾਲ ਇਹ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗਾ। ਇੰਟਰਫ਼ੇਸ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਸ਼ੁਰੂ ਕਰੋ ਜਿਵੇਂ ਵਰਤੋਂਕਾਰ ਕਰੇਗਾ, ਨਹੀਂ ਤਾਂ ਟੈਸਟ ਤੈਨਾਤੀ ਦੀ ਥਾਂ ਤੁਹਾਡਾ ਸ਼ੈੱਲ ਮਾਪੇਗਾ।

ਐਂਡਪੌਇੰਟ ਨੂੰ ਟਨਲ ਤੋਂ ਬਾਹਰ ਰੱਖਣਾ

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

ਜੇ ਐਂਡਪੌਇੰਟ ਕਈ ਪਤਿਆਂ ’ਤੇ, ਜਾਂ ਤੁਸੀਂ ਨਾ ਢੋਣ ਵਾਲੇ ਪਰਿਵਾਰ ’ਤੇ ਹੱਲ ਹੋਣ ਵਾਲਾ ਹੋਸਟਨਾਮ ਹੈ, ਤਾਂ ਅਪਵਾਦ ਬੁਰੀ ਤਰ੍ਹਾਂ ਪੁਰਾਣਾ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਰੁਟੀਨ ਜਿਹੀ ਲੱਗੀ ਮੁੜ-ਜੁੜਾਈ ਤੋਂ ਬਾਅਦ ਟਨਲ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ। ਐਂਡਪੌਇੰਟ ਨੂੰ ਤੁਹਾਡੇ ਕਾਬੂ ਵਾਲੇ ਪਤੇ ’ਤੇ ਪਿੰਨ ਕਰੋ, ਜਾਂ ਮੈਨੇਜਰ ਇਸ ਦਾ ਮੁੜ-ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ ਇਹ ਪੱਕਾ ਕਰੋ, ਅਤੇ ਹਰ ਨੈੱਟਵਰਕ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਹੋਸਟ ਰੂਟ ਦੁਬਾਰਾ ਪੜ੍ਹੋ।

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

ਗੇਟਵੇ ’ਤੇ ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਵਾਪਸੀ ਦਾ ਰਾਹ

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

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

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

DNS ਅਤੇ ਅਸਫਲਤਾ ਅਵਸਥਾ, ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਜਾਂਚੀ

ਪ੍ਰੋਟੋਕਾਲ ਆਪ ਕਿਸੇ ਵੀ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਰਿਜ਼ਾਲਵਰ ਕੌਨਫਿਗਰ ਨਹੀਂ ਕਰਦਾ। wg-quick ਵੰਡ ਦੇ ਰਿਜ਼ਾਲਵਰ ਏਕੀਕਰਨ ਰਾਹੀਂ DNS ਲਾਈਨ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਆਪਣੇ ਸਟੈਕ ਵਾਲੇ ਕੰਟੇਨਰ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਇਸ ਨੂੰ ਅਣਡਿੱਠ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਸ ਲਈ ਟਨਲ ਦੇ ਪੈਕਟ ਨੂੰ ਬਿਲਕੁਲ ਠੀਕ ਢੋਂਦਿਆਂ ਵੀ ਨਾਮ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ। ਪਤੇ ਦੀ ਥਾਂ ਹੋਸਟਨਾਮ ਨਾਲ ਟੈਸਟ ਕਰੋ, ਅਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਵਾਲੇ ਸਰਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਮੰਨਣ ਦੀ ਥਾਂ ਲਿਖੋ ਕਿ ਕਿਹੜੇ ਸਰਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ।

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

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