ਰਾਊਟਰ ਦਾ ਆਪਣਾ DNS VPN ਟਨਲ ਨੂੰ ਕਿਉਂ ਬਾਈਪਾਸ ਕਰਦਾ ਹੈ?

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

ਪੈਕੇਟ ਕੈਪਚਰ ਅਸਲ ਵਿੱਚ ਕਿਸ ਪ੍ਰਵਾਹ ਦਾ ਹੈ

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

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

ਵਿਵਹਾਰਕ ਜਾਂਚ ਇਹ ਹੈ ਕਿ ਦੋਵੇਂ ਪਾਸੇ ਇਕੱਠੇ ਵੇਖੋ। ਰਾਊਟਰ ਉੱਤੇ ਰਿਜ਼ੋਲਵਰ ਦਾ ਸਾਕਟ ਸੂਚੀਬੱਧ ਕਰੋ, ਉਸ ਨੂੰ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਪੁੱਛੋ ਅਤੇ WAN ਇੰਟਰਫੇਸ ਕੈਪਚਰ ਕਰੋ:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

ਜੇ ਸਾਕਟ ਸੂਚੀ loopback ਜਾਂ LAN ਪਤੇ ਨਾਲ ਬੱਝਾ ਸਰੋਤਾ ਦਿਖਾਵੇ, ਤਾਂ ਰਾਊਟਰ ਕਿਸੇ ਹੋਰ ਹੋਸਟ ਵੱਲ ਫਾਰਵਰਡ ਕਰਨ ਦੀ ਬਜਾਏ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਫਿਰ ਕੈਪਚਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਨਤੀਜੇ ਵਜੋਂ ਬਣੀ ਅਪਸਟ੍ਰੀਮ ਕੁਐਰੀ ਟਨਲ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ ਜਾਂ WAN ਰਾਹੀਂ, ਅਤੇ ਇਹੀ ਉਹ ਜਵਾਬ ਹੈ ਜੋ ਨੀਤੀ-ਮਾਰਗ ਨਿਯਮ ਕਦੇ ਨਹੀਂ ਸੀ ਦੇਣਾ।

ਨੀਤੀ-ਮਾਰਗ ਦੂਜੀ ਕੁਐਰੀ ਕਿਉਂ ਕਦੇ ਨਹੀਂ ਵੇਖਦਾ

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

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

pfSense ਰਿਜ਼ੋਲਵਰ ਆਪਣਾ ਅਪਸਟ੍ਰੀਮ ਮਾਰਗ ਕਿੱਥੇ ਤੈਅ ਕਰਦਾ ਹੈ

pfSense ਇਸ ਵੰਡ ਨੂੰ ਦਿੱਸਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਕਲਾਇੰਟ ਟ੍ਰੈਫਿਕ ਨੀਤੀ-ਮਾਰਗ ਰਾਹੀਂ VPN ਗੇਟਵੇ ਵਿੱਚੋਂ ਲੰਘ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਫਾਇਰਵਾਲ ਦਾ ਆਪਣਾ ਟ੍ਰੈਫਿਕ LAN ਨਿਯਮਾਂ ਦੀ ਬਜਾਏ ਰਿਜ਼ੋਲਵਰ ਦੀ ਆਉਟਗੋਇੰਗ ਸੈਟਿੰਗ ਦੀ ਪੈਰਵੀ ਕਰਦਾ ਹੈ। ਵੈੱਬ ਇੰਟਰਫੇਸ ਵਿੱਚ ਉਹ ਸੈਟਿੰਗ Services > DNS Resolver > Outgoing Network Interfaces ਅਧੀਨ ਹੈ, ਅਤੇ ਉਸ ਦਾ ਮੁੱਲ ਉਹਨਾਂ ਇੰਟਰਫੇਸਾਂ ਦੀ ਸੂਚੀ ਹੈ ਜੋ ਰਿਜ਼ੋਲਵਰ ਅਪਸਟ੍ਰੀਮ ਕੁਐਰੀਆਂ ਲਈ ਵਰਤ ਸਕਦਾ ਹੈ।

ਉੱਥੇ ਟਨਲ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ ਦੇਣਾ, ਅਤੇ ਸਿਰਫ ਉਸੇ ਇੰਟਰਫੇਸ ਦਾ, ਇਹੀ ਰਾਊਟਰ ਦੀਆਂ ਆਪਣੀਆਂ ਲੁੱਕਅੱਪ ਨੂੰ ਟਨਲ ਦੀ ਪੈਰਵੀ ਕਰਵਾਉਂਦਾ ਹੈ। ਡਿਫਾਲਟ ’ਤੇ ਛੱਡਣ ਨਾਲ ਰਿਜ਼ੋਲਵਰ ਰਾਊਟਿੰਗ ਟੇਬਲ ਵਿੱਚੋਂ ਐਗਰੇਸ ਚੁਣਦਾ ਹੈ, ਜੋ ਦੋਹਰੇ WAN ਜਾਂ VPN ਹੋਸਟ ’ਤੇ ਅਕਸਰ WAN ਹੁੰਦਾ ਹੈ।

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

ਸੈਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਅਸਫਲਤਾ ਦਾ ਵਿਵਹਾਰ ਚੁਣੋ

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

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

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

ਦੋਵੇਂ ਮਾਰਗ ਜਾਂਚੋ ਅਤੇ ਨਤੀਜੇ ਵੱਖਰੇ ਰੱਖੋ

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

LAN ਕਲਾਇੰਟ ਤੋਂ ਰਾਊਟਰ ਨੂੰ ਪਹਿਲਾਂ ਜਨਤਕ ਨਾਮ ਪੁੱਛੋ ਅਤੇ ਫਿਰ ਨਿੱਜੀ ਨਾਮ, ਜਿਸ ਦਾ ਜਵਾਬ ਸਿਰਫ ਤੁਹਾਡੇ ਅੰਦਰੂਨੀ ਜ਼ੋਨ ਨੇ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਿਰਫ ਦੂਜੀ ਕੁਐਰੀ ਵਿੱਚ ਅਸਫਲਤਾ ਟਨਲ ਵੱਲ ਨਹੀਂ, ਨਾਮ-ਫਾਰਵਰਡਿੰਗ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

ਫਿਰ ਟਨਲ ਹੇਠਾਂ ਲਾਹੋ ਅਤੇ ਦੋਵੇਂ ਕੁਐਰੀਆਂ ਦੁਹਰਾਓ। ਰੱਦ ਕੀਤੇ ਜਵਾਬਾਂ ਦਾ ਅਰਥ ਹੈ ਰਿਜ਼ੋਲਵਰ ਅਸਫਲਤਾ ’ਤੇ ਬੰਦ ਹੁੰਦਾ ਹੈ; ਸਫਲ ਜਵਾਬ ਫਾਲਬੈਕ ਰਿਜ਼ੋਲਵਰ ਅਤੇ ਉਸ ਦੇ ਵਰਤੇ ਮਾਰਗ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਇਸ ਦੀ ਤੁਲਨਾ ਆਪਣੇ ਲਿਖੇ ਨੋਟ ਅਤੇ ਉਸੇ ਮਿੰਟ WAN ਇੰਟਰਫੇਸ ’ਤੇ ਲਏ ਕੈਪਚਰ ਨਾਲ ਕਰੋ।

ਰਿਕਾਰਡ ਵਿੱਚ ਨਿਰੀਖਣ ਵੱਖਰੇ ਰੱਖੋ: ਕਲਾਇੰਟ-ਤੋਂ-ਰਾਊਟਰ ਅਦਾਨ-ਪ੍ਰਦਾਨ, ਰਾਊਟਰ-ਤੋਂ-ਅਪਸਟ੍ਰੀਮ ਅਦਾਨ-ਪ੍ਰਦਾਨ, ਅਤੇ ਦੂਜੇ ਨੂੰ ਤੈਅ ਕਰਨ ਵਾਲਾ ਕਨਫਿਗਰੇਸ਼ਨ। ਬਾਅਦ ਦਾ ਰਾਊਟਿੰਗ ਬਦਲਾਅ ਉਸ ਦੂਜੇ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਨੂੰ ਬਿਨਾਂ ਚੇਤਾਵਨੀ ਚਲਾਏਗਾ। VPN ਐਂਡਪੌਇੰਟ ਤੋਂ ਇਲਾਵਾ ਕਿਤੇ ਹੋਰੋਂ ਆਉਣ ਵਾਲਾ ਜਵਾਬ ਆਪਣੇ ਆਪ ਵਿੱਚ ਲੀਕ ਨਹੀਂ ਹੈ; ਇਹ ਲੀਕ ਤਦੋਂ ਹੀ ਬਣਦਾ ਹੈ ਜਦੋਂ ਕਨਫਿਗਰੇਸ਼ਨ ਨੇ ਉਹ ਮਾਰਗ ਹਾਦਸੇ ਨਾਲ ਚੁਣਿਆ ਹੋਵੇ।