ਜਦੋਂ VPN ਰਾਊਟਰ ’ਤੇ ਚੱਲਦਾ ਹੈ ਤਾਂ STUN ਜਵਾਬ ਕੀ ਪਰਗਟ ਕਰਦਾ ਹੈ
ਰਾਊਟਰ ਦਾ ਟਨਲ ਪਤਾ ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਸਥਾਨਕ ਪਤਾ ਨਹੀਂ ਹੈ। ਰਿਫਲੈਕਟਰ ਕੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਵੇਖੋ ਕਿ ਹਰ ਬੇਨਤੀ ਕਿਵੇਂ ਰੂਟ ਅਤੇ ਅਨੁਵਾਦ ਹੁੰਦੀ ਹੈ।
ਜਦੋਂ ਟਨਲ ਰਾਊਟਰ ’ਤੇ ਹੁੰਦਾ ਹੈ, ਬ੍ਰਾਊਜ਼ਰ ਚਲਾਉਣ ਵਾਲੀ ਮਸ਼ੀਨ ਵਿੱਚ ਕੋਈ ਟਨਲ ਇੰਟਰਫੇਸ ਨਹੀਂ ਹੁੰਦਾ। ਉਸ ਮਸ਼ੀਨ ਨੂੰ ਉਸ ਦੇ ਸਥਾਨਕ ਪਤੇ ਪੁੱਛੋ ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਨਿੱਜੀ LAN ਪਤਾ ਅਤੇ ਇੱਕ ਲੂਪਬੈਕ ਮਿਲੇਗਾ, VPN ਪਤੇ ਵਰਗਾ ਕੁਝ ਨਹੀਂ। ਫਿਰ ਵੀ ਪਾਰਲੇ ਪਾਸੇ ਦਾ STUN ਸਰਵਰ ਰਾਹ ਬਾਰੇ ਕੁਝ ਅਰਥਪੂਰਨ ਦੱਸ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹ ਕੀ ਦੱਸਦਾ ਹੈ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਇਸ ਗੱਲ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਖ਼ਾਸ ਬੇਨਤੀ ਕਿਵੇਂ ਰੂਟ ਅਤੇ ਅਨੁਵਾਦ ਹੋਈ।
ਇਹੀ ਉਹ ਹਿੱਸਾ ਹੈ ਜਿਸ ’ਤੇ ਹੌਲੀ ਹੋਣਾ ਬਣਦਾ ਹੈ। “ਬ੍ਰਾਊਜ਼ਰ VPN ਪਤੇ ਦਾ ਮਾਲਕ ਨਹੀਂ” ਇਹ ਇੰਟਰਫੇਸ ਬਾਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਹੈ, ਜਦਕਿ ਪਰਾਵਰਤਿਤ ਪਤਾ ਅਨੁਵਾਦ ਰਾਹੀਂ ਜਾਂਦੇ ਰਾਹ ਦਾ ਜਵਾਬ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣ ਨਾਲ ਪਰਗਟਾਵੇ ਬਾਰੇ ਭਰੋਸੇਵਾਨ ਸਿੱਟੇ ਨਿਕਲਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਬੂਤ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦੇ।
ਦੋ ਡਿਵਾਈਸ, ਇੰਟਰਫੇਸ ਦੇ ਦੋ ਸੈੱਟ
ਰਾਊਟਰ-ਆਧਾਰਿਤ ਸੈੱਟਅੱਪ ਵਿੱਚ ਟਨਲ ਰਾਊਟਰ ’ਤੇ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ ਅਤੇ LAN ਕਲਾਇੰਟ ਆਮ ਟ੍ਰੈਫਿਕ ਆਪਣੇ ਡਿਫੌਲਟ ਗੇਟਵੇ ਨੂੰ ਭੇਜਦਾ ਹੈ। ਕਲਾਇੰਟ ਦੀ ਇੰਟਰਫੇਸ ਸੂਚੀ ਛੋਟੀ ਹੀ ਰਹਿੰਦੀ ਹੈ: ਇੱਕ ਨਿੱਜੀ ਪਤਾ, ਸ਼ਾਇਦ ਦੂਜੇ ਨੈੱਟਵਰਕ ਲਈ ਦੂਜਾ, ਅਤੇ ਲੂਪਬੈਕ। ਖ਼ਤਰਾ ਇਹ ਨਹੀਂ ਕਿ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਸੰਜੋਗ ਨਾਲ ਟਨਲ ਪਤਾ ਹੋਵੇ; ਖ਼ਤਰਾ ਇਹ ਹੈ ਕਿ ਬੇਨਤੀ ਉਸ ਰਾਹ ਤੋਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਚੁਣਿਆ।
ਕਿਹੜੇ ਇੰਟਰਫੇਸ ਹਨ ਇਹ ਪੁੱਛਣ ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਨੂੰ ਕੋਈ ਖ਼ਾਸ ਮੰਜ਼ਿਲ ਕਿਹੜਾ ਰਾਹ ਲਵੇਗੀ ਇਹ ਪੁੱਛੋ। ਜਵਾਬ ਇੱਕ ਗੇਟਵੇ ਅਤੇ ਉਹ ਸਰੋਤ ਪਤਾ ਦੱਸਦਾ ਹੈ ਜੋ ਕਰਨਲ ਵਰਤੇਗਾ, ਅਤੇ ਇਹ ਕਿਸੇ ਵੀ ਪਤਾ-ਸੂਚੀ ਨਾਲੋਂ ਵੱਧ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਹੈ।
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsਦਸਤਾਵੇਜ਼ੀ ਰੇਂਜਾਂ ਜਾਂਚ ਲਈ ਚੰਗੀਆਂ ਮੰਜ਼ਿਲਾਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਕਦੇ ਕਿਸੇ ਅਸਲ ਸੇਵਾ ਵਿੱਚ ਹੱਲ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਕਲਾਇੰਟ ਕੀ ਕਹਿੰਦਾ ਹੈ ਦੀ ਰਾਊਟਰ ਕੀ ਕਹਿੰਦਾ ਹੈ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਕਿਸੇ ਵੀ ਮਤਭੇਦ ਨੂੰ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਮੰਨੋ ਕਿ ਨੀਤੀ ਰੂਟਿੰਗ, ਸਪਲਿਟ-ਟਨਲ ਨਿਯਮ ਜਾਂ ਦੂਜਾ ਡਿਫੌਲਟ ਰਾਹ ਕੁਝ ਅਜਿਹਾ ਕਰ ਰਿਹਾ ਹੈ ਜਿਸਦਾ ਤੁਸੀਂ ਹਿਸਾਬ ਨਹੀਂ ਲਾਇਆ।
Binding ਜਵਾਬ ਕੀ ਕਹਿ ਸਕਦਾ ਹੈ
RFC 8489 Binding ਬੇਨਤੀ ਅਤੇ ਜਵਾਬ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਰਵਰ ਉਸ ਬੇਨਤੀ ਲਈ ਦੇਖਿਆ ਗਿਆ ਸਰੋਤ ਟਰਾਂਸਪੋਰਟ ਪਤਾ ਦੱਸਦਾ ਹੈ। ਇਹ ਇੱਕ ਪਲ ’ਤੇ ਇੱਕ ਪੰਚਕ ਬਾਰੇ ਬਿਆਨ ਹੈ, ਕਲਾਇੰਟ ਦੇ ਇੰਟਰਫੇਸ ਦੀ ਗਿਣਤੀ ਨਹੀਂ। ਇਸ ਲਈ ਦਿਲਚਸਪ ਹਰ ਗੱਲ ਕਲਾਇੰਟ ਅਤੇ ਨਿਰੀਖਣ ਬਿੰਦੂ ਵਿਚਕਾਰ ਹੁੰਦੀ ਹੈ।
ਉਹ ਖਾਲੀ ਥਾਂ ਰੂਟਿੰਗ ਅਤੇ ਅਨੁਵਾਦ ਭਰਦੇ ਹਨ। ਜੋ ਰਾਊਟਰ ਬਾਹਰ ਜਾਂਦੇ ਟ੍ਰੈਫਿਕ ’ਤੇ ਸਰੋਤ NAT ਕਰਦਾ ਹੈ, ਉਹ ਕਲਾਇੰਟ ਦੇ ਨਿੱਜੀ ਸਰੋਤ ਨੂੰ ਬਾਹਰ ਜਾਂਦੇ ਇੰਟਰਫੇਸ ’ਤੇ ਆਪਣੇ ਪਤੇ ਨਾਲ ਬਦਲਦਾ ਹੈ। ਜੇ ਉਹ ਇੰਟਰਫੇਸ ਟਨਲ ਹੈ, ਰਿਫਲੈਕਟਰ ਟਨਲ ਪਤਾ ਵੇਖਦਾ ਹੈ। ਜੇ ਪੈਕਟ ਟਨਲ ਤੋਂ ਬਾਹਰ ਰੱਖਿਆ ਗਿਆ ਸੀ, ਰਿਫਲੈਕਟਰ ਉਹ ਵੇਖਦਾ ਹੈ ਜੋ WAN ਅਨੁਵਾਦ ਨੇ ਬਣਾਇਆ। ਉਹੀ ਕਲਾਇੰਟ, ਉਹੀ ਰਿਫਲੈਕਟਰ, ਵੱਖਰਾ ਜਵਾਬ।
ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਪਰ ਨਾ ਹੋਣ ਵਾਲੇ ਤਿੰਨ ਕੇਸ
ਲਾਭਦਾਇਕ ਫ਼ਰਕ ਜਨਤਕ ਬਨਾਮ ਨਿੱਜੀ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਕਿਹੜੇ ਲਾਗੂਕਰਨ ਬਿੰਦੂ ਨੇ ਪੈਕਟ ਸੰਭਾਲਿਆ। ਰਾਊਟਰ ਦੀਆਂ ਆਪਣੀਆਂ ਸਾਰਣੀਆਂ ਖੁੱਲ੍ਹੀਆਂ ਰੱਖ ਕੇ ਕੇਸ ਵੇਖੋ, ਕਿਉਂਕਿ ਇੱਕੋ ਬ੍ਰਾਊਜ਼ਰ ਤਿੰਨੇ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਤੁਸੀਂ ਲਿਖਣਾ ਭੁੱਲ ਗਏ ਨਿਯਮ ਅਨੁਸਾਰ।
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
ਸਿਰਫ਼ ਦੂਜਾ ਕੇਸ ਹੀ ਇਸ ਸ਼ਰਤ ਦੀ ਉਲੰਘਣਾ ਕਰਦਾ ਹੈ ਕਿ ਕੁਝ ਟ੍ਰੈਫਿਕ ਕਦੇ ਸਿੱਧਾ ਬਾਹਰ ਨਾ ਜਾਵੇ, ਅਤੇ ਸਿਰਫ਼ ਪਹਿਲਾ ਤੇ ਤੀਜਾ ਹੀ ਟਨਲ ਪਾਸੇ ਦੀ ਪਛਾਣ ਪਰਗਟ ਕਰਦੇ ਹਨ। ਤਿੰਨਾਂ ਕਤਾਰਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕਿਸੇ ਖ਼ਾਸ ਪ੍ਰਦਾਤਾ ਦੇ ਵਿਵਹਾਰ ਬਾਰੇ ਦਾਅਵਾ ਨਹੀਂ ਹੈ: ਨਿੱਜੀ ਰਿਫਲੈਕਟਰ ਤੱਕ ਪਹੁੰਚ ਸੰਭਵ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਰੂਟਿੰਗ, ਦੂਜੇ ਪਾਸੇ ਦੇ ਮਨਜ਼ੂਰ IP ਪਤੇ ਅਤੇ ਦੋਵਾਂ ਸਿਰਿਆਂ ਦੀ ਫਾਇਰਵਾਲ ਨੀਤੀ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
ਇੱਕੋ ਪ੍ਰਦਾਤਾ ਕੋਲ ਖਾਤਾ ਹੋਣਾ ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਵੀ ਯਾਦ ਰੱਖਣ ਯੋਗ ਹੈ ਕਿ ਰੂਟ ਕੀਤੀ ਬੇਨਤੀ ਕਲਾਇੰਟ ਦਾ LAN ਸਰੋਤ ਬਰਕਰਾਰ ਰੱਖ ਸਕਦੀ ਹੈ ਜੇ ਕੋਈ ਇਸਦਾ ਅਨੁਵਾਦ ਨਾ ਕਰੇ, ਇਸ ਲਈ ਸਰੋਤ ਖੇਤਰ ਨੂੰ ਟੋਪੋਲੋਜੀ ਚਿੱਤਰ ਤੋਂ ਮੰਨਣ ਦੀ ਥਾਂ ਲੱਭਣਾ ਪੈਂਦਾ ਹੈ।
ਇਕੱਠਾ ਕਰਨਾ ਚੁਣਨਾ ਨਹੀਂ ਹੈ
WebRTC ਕੋਸ਼ਿਸ਼ ਲਈ ਉਮੀਦਵਾਰ ਪਤੇ ਇਕੱਠੇ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਿਦਾਨ ਸੂਚੀ ਵਿੱਚ ਦਿਸਣ ਵਾਲਾ ਉਮੀਦਵਾਰ ਕਦੇ ਮੀਡੀਆ ਨਹੀਂ ਢੋ ਸਕਦਾ। ਸੂਚੀ ਨੂੰ “ਦੂਜੇ ਪਾਸੇ ਨੇ ਇਹੀ ਸਿੱਖਿਆ” ਵਜੋਂ ਪੜ੍ਹਨਾ ਸਬੂਤ ਨੂੰ ਵਧਾ-ਚੜ੍ਹਾ ਕੇ ਪੇਸ਼ ਕਰਨਾ ਹੈ। ਚੁਣੀ ਗਈ ਜੋੜੀ ਹੀ ਉਹ ਹੈ ਜਿਸਨੇ ਅਸਲ ਵਿੱਚ ਸੈਸ਼ਨ ਢੋਇਆ, ਅਤੇ ਉਹ ਦੂਜੇ ਖੇਤਰ ਵਿੱਚ ਹੈ।
HTTPS ਨਿਕਾਸ ਜਾਂਚਕਰਤਾ ਇੱਕ ਹੋਰ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਉਹ ਸਰੋਤ ਪਤਾ ਜੋ ਕਿਸੇ ਵੈੱਬ ਸਰਵਰ ਨੇ ਉਸ ਬੇਨਤੀ ਲਈ ਵੇਖਿਆ। ਇਹ ਲਾਭਦਾਇਕ ਕ੍ਰਾਸ-ਜਾਂਚ ਹੈ ਕਿਉਂਕਿ ਇਹ UDP ਰਿਫਲੈਕਟਰ ਨਾਲੋਂ ਵੱਖਰਾ ਪ੍ਰੋਟੋਕਾਲ ਅਤੇ ਅਕਸਰ ਵੱਖਰੀ ਮੰਜ਼ਿਲ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਵਿਚਕਾਰ ਅਸਹਿਮਤੀ ਆਮ ਤੌਰ ’ਤੇ ਬੱਗ ਨਹੀਂ ਸਗੋਂ ਰੂਟਿੰਗ ਨਿਯਮ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ।
ਨੀਤੀ ਤੈਅ ਕਰੋ, ਫਿਰ ਜਵਾਬ ਪੜ੍ਹੋ
ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਇਰਾਦਾ ਲਿਖੋ: ਕਿਹੜਾ ਟ੍ਰੈਫਿਕ ਟਨਲ ਵਰਤੇ, ਕਿਹੜਾ ਸਿੱਧਾ ਬਾਹਰ ਜਾ ਸਕਦਾ ਹੈ, ਕਿਹੜੇ ਪਤਾ-ਪਰਿਵਾਰ ਦਾਇਰੇ ਵਿੱਚ ਹਨ, ਅਤੇ ਟਨਲ ਬੰਦ ਹੋਣ ’ਤੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਸ ਆਧਾਰ-ਰੇਖਾ ਤੋਂ ਬਿਨਾਂ ਹਰ ਨਿਰੀਖਣ ਅਸਪਸ਼ਟ ਹੈ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਮਨਜ਼ੂਰ ਕੀਤੇ ਰਾਹ ਤੋਂ ਲੀਕ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦੇ।
ਫਿਰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਸਵਾਲ ਪੁੱਛੋ। ਇਹ ਮੰਜ਼ਿਲ ਕਿਹੜਾ ਰਾਹ ਲੈਂਦੀ ਹੈ। ਇਹ ਰਿਫਲੈਕਟਰ ਕਿਹੜਾ ਪਤਾ ਦੱਸਦਾ ਹੈ। ਸੈਸ਼ਨ ਨੇ ਕਿਹੜੀ ਉਮੀਦਵਾਰ ਜੋੜੀ ਚੁਣੀ। ਜਵਾਬ ਨੀਤੀ ਦੇ ਕੋਲ ਰੱਖੋ ਅਤੇ ਤਾਰੀਖ਼ ਲਾਓ, ਕਿਉਂਕਿ ਫਰਮਵੇਅਰ ਅੱਪਡੇਟ ਡਿਫੌਲਟ ਵਿਵਹਾਰ ਇਸ ਤਰ੍ਹਾਂ ਬਦਲ ਸਕਦਾ ਹੈ ਜੋ ਪਿਛਲੇ ਸਾਲ ਦੇ ਸਿੱਟੇ ਨੂੰ ਚੁੱਪਚਾਪ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ।
ਰਾਊਟਰ ਅਜੇ ਵੀ ਮਜ਼ਬੂਤ ਲਾਗੂਕਰਨ ਬਿੰਦੂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਉਹ ਟ੍ਰੈਫਿਕ ਵੇਖਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਆਪਣੇ ਆਪ ਨੂੰ ਮੁੜ ਸੰਰਚਿਤ ਕੀਤੇ ਬਿਨਾਂ ਟਾਲ ਨਹੀਂ ਸਕਦਾ। ਇਹ ਇਸ ਗੱਲ ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਕਿ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕਾਲ ਦਾ ਹਰ ਖੇਤਰ ਕੁਝ ਵੀ ਪਰਗਟ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਹ ਮਨਜ਼ੂਰ ਕਰਨ ਲਈ ਚੁਣੇ ਰਾਹਾਂ ਨੂੰ ਲਿਖਣ ਦਾ ਬਦਲ ਵੀ ਨਹੀਂ ਹੈ।