WireGuard ਮੋਬਾਈਲ ਡੇਟਾ ਉੱਤੇ ਚੱਲਦਾ ਹੈ, ਪਰ ਉਸੇ Wi-Fi ਉੱਤੇ ਨਹੀਂ
LAN ਦੇ ਅੰਦਰੋਂ ਰਾਊਟਰ ਦੇ ਜਨਤਕ ਪਤੇ ਉੱਤੇ ਜਾਣ ਵਾਲੀ ਬੇਨਤੀ ਮੋਬਾਈਲ ਡੇਟਾ ਵਾਲੀ ਬੇਨਤੀ ਨਾਲੋਂ ਵੱਖਰਾ ਰਾਹ ਲੈਂਦੀ ਹੈ। ਪਹਿਲਾਂ ਬਾਹਰੋਂ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਸਥਾਨਕ ਰਾਹ ਚੁਣੋ।
ਮੋਬਾਈਲ ਡੇਟਾ ਉੱਤੇ ਟਨਲ ਉੱਪਰ ਆਉਂਦੀ ਹੈ ਅਤੇ ਫਿਰ ਘਰ ਵਿੱਚ ਉਹੀ ਪ੍ਰੋਫਾਈਲ, ਉਹੀ ਪੀਅਰ ਕੁੰਜੀ ਅਤੇ ਵਿਚਕਾਰ ਕੋਈ ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲਾਅ ਤੋਂ ਬਿਨਾਂ ਉਹ ਜੁੜ ਰਿਹਾ ਹੈ ਦੀ ਹਾਲਤ ਵਿੱਚ ਬੈਠੀ ਰਹਿੰਦੀ ਹੈ। ਫ਼ਰਕ ਸਫ਼ਰ ਵਿੱਚ ਹੈ: LAN ਦੇ ਅੰਦਰੋਂ ਰਾਊਟਰ ਦੇ ਜਨਤਕ ਪਤੇ ਉੱਤੇ ਜਾਣ ਵਾਲੀ ਬੇਨਤੀ ਇੰਟਰਨੈੱਟ ਤੋਂ ਆਉਣ ਵਾਲੀ ਬੇਨਤੀ ਦਾ ਉਹੀ ਸਫ਼ਰ ਨਹੀਂ ਹੈ। ਬਹੁਤੇ ਘਰੇਲੂ ਗੇਟਵੇ ਜਾਂ ਤਾਂ ਵਾਪਸੀ ਦਾ ਰਾਹ ਲਾਗੂ ਨਹੀਂ ਕਰਦੇ, ਜਾਂ ਸਿਰਫ਼ ਕੁਝ ਪ੍ਰੋਟੋਕੋਲਾਂ ਲਈ ਲਾਗੂ ਕਰਦੇ ਹਨ। ਇਸ ਨਾਲ ਕੁੰਜੀ ਬਾਰੇ ਕੁਝ ਵੀ ਨਾ ਬਦਲਿਆ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਲੱਛਣ ਟੁੱਟੀ ਕੁੰਜੀ ਵਰਗਾ ਦਿਸਦਾ ਹੈ। ਕੁੰਜੀ, ਪੋਰਟ ਫਾਰਵਰਡ ਜਾਂ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜਾ ਰਾਹ ਫੇਲ੍ਹ ਹੋਇਆ।
ਇੱਕ ਪਤਾ, ਦੋ ਵੱਖਰੇ ਰਾਹ
ਬਾਹਰੋਂ ਇੱਕ ਪੈਕਟ ਰਾਊਟਰ ਦੇ ਜਨਤਕ ਪਤੇ ਉੱਤੇ ਪਹੁੰਚਦਾ ਹੈ ਅਤੇ ਪੋਰਟ-ਫਾਰਵਰਡ ਨਿਯਮ ਉਸਨੂੰ ਅੰਦਰੂਨੀ ਹੋਸਟ ਦੇ WireGuard ਸਰੋਤੇ ਨੂੰ ਸੌਂਪ ਦਿੰਦਾ ਹੈ। ਅੰਦਰੋਂ ਕਲਾਇੰਟ ਉਹੀ ਜਨਤਕ ਪਤਾ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪੈਕਟ ਕਲਾਇੰਟ ਤੋਂ ਨਿਕਲਦਾ ਹੈ, ਰਾਊਟਰ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਅਤੇ ਮੁੜ LAN ਵੱਲ ਮੋੜਨਾ ਪੈਂਦਾ ਹੈ। ਉਸ ਮੁੜ-ਮੋੜ ਉੱਤੇ ਹੀ ਦੋਵੇਂ ਰਾਹ ਵੱਖ ਹੁੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਰਾਊਟਰ ਨੂੰ ਉਹ ਫਲੋ ਅਨੁਵਾਦ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਜੋ ਇੱਕੋ ਇੰਟਰਫ਼ੇਸ ਤੋਂ ਨਿਕਲ ਕੇ ਮੁੜ ਉਸੇ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੀ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਅਮਲ ਇਸਨੂੰ ਅਨੁਵਾਦ ਕਰਨ ਦੀ ਥਾਂ ਸੁੱਟ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਕਲਾਇੰਟ ਉਸ ਹੈਂਡਸ਼ੇਕ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ ਜੋ ਕਦੇ ਭੇਜਿਆ ਹੀ ਨਹੀਂ ਗਿਆ।
ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਆਮ ਤੌਰ ਉੱਤੇ NAT ਲੂਪਬੈਕ ਜਾਂ ਹੇਅਰਪਿਨਿੰਗ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ WireGuard ਦਾ ਨਹੀਂ, ਰਾਊਟਰ ਦਾ ਗੁਣ ਹੈ; RFC 4787 ਉਹ ਅਨੁਵਾਦ ਕੇਸ ਗਿਣਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਗੇਟਵੇ ਇਸਨੂੰ ਸਮਰਥਨ ਦੇ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। WireGuard ਆਪ ਰਾਹ ਬਾਰੇ ਕੋਈ ਰਾਏ ਨਹੀਂ ਰੱਖਦਾ, ਕਿਉਂਕਿ ਇਹ ਸਿਰਫ਼ ਉਹ ਪੈਕਟ ਦੇਖਦਾ ਹੈ ਜੋ ਇਸਦੇ ਇੰਟਰਫ਼ੇਸ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ। ਜਦੋਂ ਰਾਊਟਰ ਫਲੋ ਸੁੱਟ ਦਿੰਦਾ ਹੈ, ਡੀਮਨ ਨੂੰ ਕੁਝ ਨਹੀਂ ਮਿਲਦਾ, ਕਲਾਇੰਟ ਹੈਂਡਸ਼ੇਕ ਟਾਈਮਆਊਟ ਦੱਸਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਲਾਗ ਖਾਲੀ ਰਹਿੰਦੀ ਹੈ। ਇਸ ਲਈ ਖਾਲੀ ਲਾਗ ਇਸ ਗੱਲ ਦਾ ਸੁਰਾਗ ਹੈ ਕਿ ਪੈਕਟ ਕਿੱਥੇ ਰੁਕਿਆ, ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਸਰਵਰ ਬੰਦ ਹੈ। ਦੁਬਾਰਾ ਇੰਸਟਾਲ ਕਰਨ ਨਾਲ ਕੁਝ ਨਾ ਬਦਲਣ ਦਾ ਕਾਰਨ ਵੀ ਇਹੀ ਹੈ।
ਉਲਟਾ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: LAN ਪਤੇ ਤੋਂ ਹੈਂਡਸ਼ੇਕ ਦੀ ਕੋਸ਼ਿਸ਼ ਦਿਖਾਉਣ ਵਾਲੀ ਸਰਵਰ ਲਾਗ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਪੈਕਟ ਪਹੁੰਚਿਆ ਅਤੇ ਰਾਹ ਠੀਕ ਹੈ, ਜਿਸ ਨਾਲ ਜਾਂਚ ਕੁੰਜੀਆਂ ਅਤੇ ਮਨਜ਼ੂਰ ਪਤਿਆਂ ਵੱਲ ਤੁਰਦੀ ਹੈ। ਲਾਗ ਨੂੰ ਇਸ ਲਈ ਪੜ੍ਹੋ ਕਿ ਇਹ ਕੀ ਸਾਬਤ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਕੀ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਸੀ।
ਕੁਝ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸਨੂੰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰੋ
ਉਸੇ ਡਿਵਾਈਸ ਅਤੇ ਉਸੇ ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਕਿਸੇ ਅਧਿਕਾਰਤ ਬਾਹਰੀ ਨੈੱਟਵਰਕ ਤੋਂ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਕੁਝ ਵੀ ਬਦਲੇ ਬਿਨਾਂ LAN ਦੇ ਅੰਦਰ ਉਹੀ ਜਾਂਚ ਦੁਹਰਾਓ। ਬਾਹਰ ਪੂਰਾ ਹੋਇਆ ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਅੰਦਰ ਡਿਵਾਈਸ ਛੱਡ ਕੇ ਨਾ ਜਾਣ ਵਾਲਾ ਕਲਾਇੰਟ ਅੰਦਾਜ਼ੇ ਦੀ ਥਾਂ ਉਸ ਹਾਲਤ ਨੂੰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਦੋਵੇਂ ਕੋਸ਼ਿਸ਼ਾਂ ਵਿੱਚ ਇੱਕੋ ਪ੍ਰੋਫਾਈਲ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਤੁਲਨਾ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ।
ਫਿਰ ਦੇਖੋ ਕਿ ਇਸ ਡਿਵਾਈਸ ਲਈ ਐਂਡਪਾਇੰਟ ਨਾਮ ਕਿਹੜੇ ਪਤੇ ਉੱਤੇ ਰਿਜ਼ਾਲਵ ਹੁੰਦਾ ਹੈ। ਇਹ ਤਿੰਨ ਕਮਾਂਡ ਇਹ ਵੀ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਕਿ ਕਲਾਇੰਟ ਨੇ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਪਤਾ ਡਾਇਲ ਕੀਤਾ:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netਪਹਿਲੀ ਕਮਾਂਡ ਦੱਸਦੀ ਹੈ ਕਿ ਇੰਟਰਫ਼ੇਸ ਇਸ ਵੇਲੇ ਕਿਹੜਾ ਐਂਡਪਾਇੰਟ ਵਰਤ ਰਿਹਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਦੋ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਕਿ ਇਸ ਮਸ਼ੀਨ ਉੱਤੇ ਨਾਮ ਕਿਹੜੇ ਪਤੇ ਉੱਤੇ ਰਿਜ਼ਾਲਵ ਹੁੰਦਾ ਹੈ। ਸਰਵਰ ਦੇ ਹੀ ਨੈੱਟਵਰਕ ਉੱਤੇ ਬੈਠ ਕੇ ਜਨਤਕ ਪਤਾ ਡਾਇਲ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਹੇਅਰਪਿਨ ਰਾਹ ਵਰਤ ਰਿਹਾ ਹੈ। LAN ਪਤਾ ਡਾਇਲ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਉੱਥੋਂ ਦੀ ਅਸਫਲਤਾ ਕਿਸੇ ਹੋਰ ਜਾਂਚ ਦੀ ਗੱਲ ਹੈ। ਇਹੀ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਅਗਲਾ ਹਿੱਸਾ ਇੱਥੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਨੇੜਲੇ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਣ ਦੇ ਸਮਰਥਿਤ ਤਰੀਕੇ
ਸਭ ਤੋਂ ਸਾਫ਼ ਬੰਦੋਬਸਤ ਸਪਲਿਟ-ਹੋਰਾਈਜ਼ਨ ਜਵਾਬ ਹੈ: ਜਨਤਕ ਨਾਮ ਇੰਟਰਨੈੱਟ ਲਈ ਜਨਤਕ ਪਤੇ ਉੱਤੇ ਅਤੇ ਅੰਦਰਲੇ ਕਲਾਇੰਟਾਂ ਲਈ ਸਰਵਰ ਦੇ LAN ਪਤੇ ਉੱਤੇ ਰਿਜ਼ਾਲਵ ਹੁੰਦਾ ਹੈ। ਪ੍ਰੋਫਾਈਲ ਇੱਕ ਐਂਡਪਾਇੰਟ ਨਾਮ ਰੱਖਦੀ ਹੈ ਅਤੇ ਰਿਜ਼ਾਲਵਰ ਰਾਹ ਚੁਣਦਾ ਹੈ। ਇਸ ਲਈ ਅੰਦਰੂਨੀ DNS ਜਵਾਬ ਦਾ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਘਰੇਲੂ ਰਾਊਟਰ ਆਮ ਤੌਰ ਉੱਤੇ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕੋਈ ਸੰਸਥਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਕਰ ਸਕਦੀ ਹੈ। ਉਸ ਨਿਯੰਤਰਣ ਤੋਂ ਬਿਨਾਂ ਬਚੇ ਵਿਕਲਪ ਰਾਊਟਰ ਦੀ ਕੋਈ ਸੁਵਿਧਾ ਜਾਂ ਦੂਜੀ ਪ੍ਰੋਫਾਈਲ ਹਨ।
ਰਾਊਟਰ ਦੀ ਸੁਵਿਧਾ ਪਰਾਵਰਤਨ ਹੈ: ਗੇਟਵੇ ਅੰਦਰੋਂ-ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਫਲੋ ਦਾ ਅਨੁਵਾਦ ਕਰਕੇ ਉਸਨੂੰ ਮੁੜ ਅੰਦਰ ਭੇਜਦਾ ਹੈ। ਜਿੱਥੇ ਇਹ ਚੱਲਦਾ ਹੈ ਉੱਥੇ ਕਲਾਇੰਟ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਚਾਹੀਦਾ, ਅਤੇ ਜਿੱਥੇ ਨਹੀਂ ਚੱਲਦਾ ਉੱਥੇ ਕੋਈ ਕਲਾਇੰਟ ਸੈਟਿੰਗ ਬਚਾ ਨਹੀਂ ਸਕਦੀ। ਰਾਊਟਰ ਦੀ ਸੁਵਿਧਾ-ਸੂਚੀ ਪੜ੍ਹਨ ਦੀ ਥਾਂ ਅੰਦਰੂਨੀ ਕੋਸ਼ਿਸ਼ ਵੇਲੇ ਸਰਵਰ ਲਾਗ ਦੇਖ ਕੇ ਇਸਦੀ ਜਾਂਚ ਕਰੋ।
ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਨਿੱਜੀ ਪਤੇ ਉੱਤੇ ਬਦਲਣਾ ਨਿਦਾਨ ਹੈ, ਡਿਜ਼ਾਈਨ ਨਹੀਂ। ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਰਵਰ LAN ਉੱਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਲੈਪਟਾਪ ਦੇ ਘਰੋਂ ਬਾਹਰ ਨਿਕਲਦਿਆਂ ਹੀ ਉਹੀ ਪ੍ਰੋਫਾਈਲ ਟੁੱਟ ਜਾਂਦੀ ਹੈ।
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
ਘਰ ਤੋਂ ਦੂਰ ਵੀ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਵਰਤੋਂਯੋਗ ਰੱਖੋ
ਕੋਈ ਵੀ ਰਾਹ ਚੁਣੋ, ਪਛਾਣ-ਪੜਤਾਲ ਨੂੰ ਹੱਥ ਨਾ ਲਾਓ। ਐਂਡਪਾਇੰਟ ਪਤਾ ਪੀਅਰ ਦੀ ਪਛਾਣ ਨਹੀਂ ਹੈ, ਅਤੇ ਪਤਾ ਬਦਲਣਾ ਕਦੇ ਵੀ ਇੱਕ ਅਜਿਹੀ ਅਸੰਬੰਧਿਤ ਜਨਤਕ ਕੁੰਜੀ ਮਨਜ਼ੂਰ ਕਰਨ ਦਾ ਜਾਇਜ਼ ਆਧਾਰ ਨਹੀਂ ਹੁੰਦਾ ਜੋ ਸੰਜੋਗ ਨਾਲ ਜਵਾਬ ਦੇ ਰਹੀ ਹੋਵੇ। WireGuard ਕੁੰਜੀ ਨਾਲ ਹੀ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਗਲਤ ਹੋਸਟ ਹੈਂਡਸ਼ੇਕ ਫੇਲ੍ਹ ਕਰਦਾ ਹੈ, ਕਿਸੇ ਅਣਕਿਆਸੀ ਚੀਜ਼ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਦਿੰਦਾ।
ਜੇ ਜਨਤਕ ਪਤਾ ਬਦਲੇ, ਤਾਂ ਨਾਮ ਨੂੰ ਲਾਭਕਾਰੀ ਰੱਖਣ ਵਾਲਾ ਡਾਇਨਾਮਿਕ DNS ਹੈ, ਅਤੇ ਬਦਲਾਅ ਕਿੰਨੀ ਛੇਤੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਇਹ ਕਲਾਇੰਟ ਦਾ ਰਿਫ਼੍ਰੈਸ਼ ਵਿਵਹਾਰ ਤੈਅ ਕਰਦਾ ਹੈ। ਪਤਾ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਬਾਹਰੋਂ ਜਾਂਚੋ, ਕਿਉਂਕਿ LAN ਦੀ ਹਾਲਤ ਇਸਨੂੰ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਅਜਿਹੇ ਰਿਜ਼ਾਲਵਰ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ ਜੋ ਰਿਕਾਰਡ ਦੀ ਉਮਰ ਲੰਘਣ ਤੋਂ ਬਾਅਦ ਵੀ ਪੁਰਾਣਾ ਜਵਾਬ ਕੈਸ਼ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਪਿਛਲੇ ਪਤੇ ਵੱਲ ਅਜੇ ਵੀ ਇਸ਼ਾਰਾ ਕਰਦਾ ਨਾਮ ਬਿਲਕੁਲ ਬੰਦ ਪਏ ਸਰਵਰ ਵਰਗਾ ਦਿਸਦਾ ਹੈ।
ਲਿਖ ਲਓ ਕਿ ਪ੍ਰੋਫਾਈਲ ਕਿਹੜਾ ਨਾਮ ਵਰਤਦੀ ਹੈ ਅਤੇ ਸੀਮਾ ਦੇ ਦੋਵੇਂ ਪਾਸੇ ਉਹ ਕਿਹੜੇ ਪਤੇ ਉੱਤੇ ਰਿਜ਼ਾਲਵ ਹੁੰਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਵੱਲੋਂ ਦਰਜ ਨਾ ਕੀਤੀ ਰਾਊਟਰ ਸੁਵਿਧਾ ਉੱਤੇ ਨਿਰਭਰ ਪ੍ਰੋਫਾਈਲ ਅਗਲੇ ਫਰਮਵੇਅਰ ਅਪਡੇਟ ਦੀ ਉਡੀਕ ਕਰਦੀ ਸਹਾਇਤਾ ਕਾਲ ਹੈ। ਉਹੀ ਨੋਟ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਅੰਦਰੂਨੀ ਅਸਫਲਤਾ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਹੇਅਰਪਿਨ ਕੇਸ ਹੈ ਜਾਂ ਕੁਝ ਨਵਾਂ।