Wi-Fi ਬਦਲਣ ਜਾਂ Ethernet ਲਾਉਣ ’ਤੇ ਤੁਹਾਡਾ VPN ਕਿਉਂ ਟੁੱਟਦਾ ਹੈ
'ਨਵਾਂ SSID, ਐਕਸੈਸ ਪੁਆਇੰਟਾਂ ਵਿਚਕਾਰ ਰੋਮਿੰਗ ਅਤੇ ਲੱਗੀ ਕੇਬਲ ਟਨਲ ਨੂੰ ਤਿੰਨ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ’ਤੇ ਤੋੜਦੇ ਹਨ। ਸਰੋਤ ਪਤਾ, ਫਿਰ ਰੂਟ, ਫਿਰ ਪ੍ਰੋਟੋਕੋਲ ਜਾਂਚੋ।'
ਦੋ ਗੱਲਾਂ ਇੱਕ ਹੀ ਖਰਾਬੀ ਵਜੋਂ ਦਰਜ ਹੁੰਦੀਆਂ ਹਨ: ਲੈਪਟਾਪ ਕਿਸੇ ਹੋਰ Wi-Fi ਨੈੱਟਵਰਕ ’ਤੇ ਚਲਾ ਗਿਆ, ਜਾਂ Wi-Fi ਚੱਲਦੇ ਹੋਏ ਹੀ ਕੇਬਲ ਲੱਗ ਗਈ। ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਕਹਿੰਦਾ ਹੈ ਜੁੜਿਆ ਹੈ, ਆਈਕਨ ਤੰਦਰੁਸਤ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਕੁਝ ਵੀ ਨਹੀਂ ਢੋਂਦੀ। ਅੰਦਰ ਸਿਰਫ਼ ਤਿੰਨ ਹਾਲਤ-ਟੁਕੜੇ ਹਿੱਲ ਸਕਦੇ ਹਨ - ਲਿੰਕ, ਸਥਾਨਕ ਪਤਾ, ਡਿਫ਼ਾਲਟ ਰੂਟ - ਅਤੇ ਕਿਹੜਾ ਹਿੱਲਿਆ ਇਸੇ ਗੱਲ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਟਨਲ ਆਪਣੇ ਆਪ ਠੀਕ ਹੋਵੇਗੀ ਜਾਂ ਦੁਬਾਰਾ ਜੁੜਨਾ ਪਵੇਗਾ। ਮੈਂ ਇਨ੍ਹਾਂ ਨੂੰ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚਦਾ ਹਾਂ, ਕਿਉਂਕਿ ਖਾਤਾ ਸੈਟਿੰਗਾਂ ਬਦਲਣ ਨਾਲ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਕਦੇ ਠੀਕ ਨਹੀਂ ਹੋਇਆ।
ਲਿੰਕ, ਪਤਾ ਅਤੇ ਰੂਟ ਆਜ਼ਾਦ ਰੂਪ ਵਿੱਚ ਹਿੱਲਦੇ ਹਨ
ਇੱਕੋ ਨੈੱਟਵਰਕ ਦੇ ਐਕਸੈਸ ਪੁਆਇੰਟਾਂ ਵਿਚਕਾਰ ਰੋਮਿੰਗ ਆਮ ਤੌਰ ’ਤੇ L2 ਘਟਨਾ ਹੁੰਦੀ ਹੈ। ਰੇਡੀਓ ਦੁਬਾਰਾ ਜੁੜਦਾ ਹੈ, ਇੰਟਰਫ਼ੇਸ ਆਪਣਾ ਪਤਾ ਅਤੇ ਗੇਟਵੇ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਜਿਸ ਉੱਤੇ ਨਿਰਭਰ ਹੈ ਉਸ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਇਸੇ ਲਈ ਵੱਡੇ ਦਫ਼ਤਰ ਵਿੱਚ ਤੁਰਨਾ ਕਦੇ-ਕਦੇ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ। ਦੂਜੇ SSID ਵਿੱਚ ਜੁੜਨਾ ਇਹ ਨਹੀਂ ਹੈ: ਪੁਰਾਣਾ ਇੰਟਰਫ਼ੇਸ ਹੇਠਾਂ ਜਾ ਸਕਦਾ ਹੈ, DHCP ਨਵਾਂ ਪਤਾ, ਨਵਾਂ ਗੇਟਵੇ ਅਤੇ ਨਵੇਂ ਰਿਜ਼ੋਲਵਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਜੋ ਬਾਹਰੀ ਪ੍ਰਵਾਹ ਵਰਤ ਰਹੀ ਸੀ ਉਹ ਹੋਂਦ ਵਿੱਚ ਨਹੀਂ ਰਹਿੰਦਾ।
Ethernet ਤੀਜਾ ਰੂਪ ਜੋੜਦਾ ਹੈ। Wi-Fi ਕਦੇ ਨਹੀਂ ਡਿੱਗਦਾ, ਇਸ ਲਈ ਲਿੰਕ ਘਟਨਾ ਬਿਲਕੁਲ ਨਹੀਂ ਹੁੰਦੀ, ਪਰ ਤਾਰ ਵਾਲਾ ਇੰਟਰਫ਼ੇਸ ਆਪਣੇ ਪਤੇ ਨਾਲ ਦਿਸਦਾ ਹੈ ਅਤੇ ਅਕਸਰ ਮੈਟ੍ਰਿਕ ’ਤੇ ਡਿਫ਼ਾਲਟ ਰੂਟ ਜਿੱਤ ਲੈਂਦਾ ਹੈ। ਟਨਲ ਹੁਣ ਪਸੰਦ ਨਾ ਕੀਤੇ ਜਾਂਦੇ ਰਾਹ ਉੱਤੇ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ, ਜਾਂ ਕਲਾਇੰਟ ਆਪਣਾ ਸਾਕਟ ਉਸੇ ਵਾਇਰਲੈੱਸ ਨੈੱਟਵਰਕ ਨਾਲ ਬੰਨ੍ਹੀ ਰੱਖਦਾ ਹੈ ਜਿੱਥੇ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ। ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਦੋਵੇਂ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ: ਕੇਬਲ ਬੈਠਦੇ ਹੀ ਪੇਜ ਅਟਕ ਜਾਂਦੇ ਹਨ।
ਇਸ ਲਈ ਪਹਿਲਾ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ Wi-Fi ਬਦਲਿਆ ਜਾਂ ਨਹੀਂ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਜਿਸ ਪਤੇ ਨਾਲ ਤੁਸੀਂ ਬੱਝੇ ਹੋ, ਜਾਂ ਅੰਤਿਮ ਬਿੰਦੂ ਤੱਕ ਦਾ ਰੂਟ, ਟਨਲ ਚੱਲਦੇ ਹੋਏ ਬਦਲਿਆ ਜਾਂ ਨਹੀਂ।
ਬਾਹਰੀ ਸਾਕਟ ਉਸ ਪਤੇ ਨਾਲ ਬੱਝੀ ਹੋਈ ਹੈ ਜੋ ਹੁਣੇ ਗਾਇਬ ਹੋਇਆ
ਹਰ ਟਨਲ ਇੱਕ ਬਾਹਰੀ ਪ੍ਰਵਾਹ ਹੈ: ਇੱਕ ਸਥਾਨਕ ਪਤਾ ਅਤੇ ਪੋਰਟ ਸਰਵਰ ਦੇ ਪਤੇ ਅਤੇ ਪੋਰਟ ਨਾਲ ਗੱਲ ਕਰਦੇ ਹਨ। Linux ’ਤੇ ਇਹ ਪੁਰਾਣੇ ਸਰੋਤ ਨਾਲ ਬੱਝੀ UDP ਸਾਕਟ ਹੈ; ਜਦੋਂ ਪਤਾ ਰੱਖਣ ਵਾਲਾ ਇੰਟਰਫ਼ੇਸ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਭੇਜਣੀਆਂ ਜਾਂ ਤਾਂ EADDRNOTAVAIL ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ ਜਾਂ ਨਵੇਂ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਉਸ ਸਰੋਤ ਨਾਲ ਨਿਕਲਦੀਆਂ ਹਨ ਜੋ ਸਰਵਰ ਨੇ ਕਦੇ ਨਹੀਂ ਵੇਖਿਆ।
ਪਰਲਾ ਪਾਸਾ ਆਪਣੀ ਬੰਨ੍ਹੀ ਰੱਖਦਾ ਹੈ। MOBIKE ਤੋਂ ਬਿਨਾਂ IKEv2 SA ਪਤਿਆਂ ਦੀ ਜੋੜੀ ਨਾਲ ਪਛਾਣੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇੱਕ OpenVPN ਸੈਸ਼ਨ ਉਸ ਪੀਅਰ ਪਤੇ ਨਾਲ ਬੱਝਾ ਹੁੰਦਾ ਹੈ ਜੋ ਉਸਨੇ ਸਿੱਖਿਆ, ਅਤੇ NAT ਮੈਪਿੰਗ ਉਸ ਨਿੱਜੀ ਪਤੇ, ਪੋਰਟ ਅਤੇ ਜਨਤਕ ਪਤੇ ਦੀ ਹੁੰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੇ ਇਸਨੂੰ ਬਣਾਇਆ। ਕਿਸੇ ਹੋਰ NAT ਪਿੱਛੇ ਜਾਓ ਅਤੇ ਹਰ ਜਵਾਬ ਉਸ ਮੈਪਿੰਗ ’ਤੇ ਜਾਂਦਾ ਹੈ ਜੋ ਹੁਣ ਨਹੀਂ ਹੈ। ਤੁਹਾਡੀ ਮਸ਼ੀਨ ’ਤੇ ਕੁਝ ਵੀ ਗਲਤ ਸੰਰਚਿਤ ਨਹੀਂ ਹੈ; ਪੰਜ-ਟਪਲ ਉਸ ਨੈੱਟਵਰਕ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਛੱਡਿਆ।
ਸਿਧਾਂਤ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹਾਲਤ ਪੜ੍ਹੋ:
ss -unpਹਰ ਟਨਲ ਸਾਕਟ ਅਸਲ ਵਿੱਚ ਰੱਖਦੀ ਸਥਾਨਕ ਪਤਾ ਅਤੇ ਪੋਰਟ ਦਿਖਾਉਂਦੀ ਹੈ।ip route get 203.0.113.10ਕਰਨਲ ਹੁਣ ਅੰਤਿਮ ਬਿੰਦੂ ਲਈ ਵਰਤਣ ਵਾਲਾ ਸਰੋਤ ਪਤਾ ਅਤੇ ਡਿਵਾਈਸ ਛਾਪਦਾ ਹੈ।wg show wg0 endpoints,swanctl --list-sasਜਾਂ ਕਲਾਇੰਟ ਲੌਗ ਉਹ ਪੀਅਰ ਪਤਾ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿਸ ਨਾਲ ਪਰਲਾ ਪਾਸਾ ਗੱਲ ਕਰ ਰਿਹਾ ਹੈ।
ਜੇ ਸਾਕਟ ਦਾ ਪਤਾ ਅਤੇ ਰੂਟ ਖੋਜ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਤਾਂ ਤੁਸੀਂ ਟੁੱਟਣ ਲੱਭ ਲਈ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਬਦਲਾਅ ਇਸਨੂੰ ਨਹੀਂ ਛੂਹੇਗਾ।
ਨਵੇਂ ਸਰੋਤ ਪਤੇ ਨਾਲ ਹਰ ਪ੍ਰੋਟੋਕੋਲ ਕੀ ਕਰਦਾ ਹੈ
ਕਲਾਇੰਟ ਬਦਲਾਅ ਨੂੰ ਵੱਖਰੇ ਪੱਧਰਾਂ ’ਤੇ ਸੋਖਦੇ ਹਨ, ਅਤੇ ਦੁਬਾਰਾ ਜੁੜਨ ਦੇ ਵਿਵਹਾਰ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਮੈਂ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਨਾਲ ਤੁਲਨਾ ਕਰਦਾ ਹਾਂ, ਉਹ ਇਹ ਸਾਰਣੀ ਹੈ।
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
WireGuard ਦਾ ਰੋਮਿੰਗ ਨਿਯਮ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ: ਕਲਾਇੰਟ ਨੇ ਪਹਿਲਾਂ ਨਵੇਂ ਪਤੇ ਤੋਂ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੁਰਾਣੇ ਇੰਟਰਫ਼ੇਸ ਨਾਲ ਬੱਝੀ ਸਾਕਟ ਇਹ ਕਦੇ ਨਹੀਂ ਕਰਦੀ, ਇਸੇ ਲਈ ਟਨਲ ਜੀਵਤ ਦਿਸ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਇਸਦਾ ਹੈਂਡਸ਼ੇਕ ਟਾਈਮਰ ਪੁਰਾਣਾ ਹੁੰਦਾ ਰਹਿੰਦਾ ਹੈ। ਪ੍ਰੋਟੋਕੋਲ ਵਰਣਨ ਅੰਤਿਮ ਬਿੰਦੂ ਅੱਪਡੇਟ ਦੀ ਸ਼ਰਤ ਸਟੀਕ ਰੂਪ ਵਿੱਚ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਸੰਰਚਨਾ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਪੜ੍ਹਨਾ ਲਾਹੇਵੰਦ ਹੈ।
MOBIKE ਗੱਲਬਾਤ ਰਾਹੀਂ ਤੈਅ ਹੁੰਦਾ ਹੈ, ਮੰਨ ਲਿਆ ਨਹੀਂ ਜਾਂਦਾ। ਜੇ ਸਰਵਰ ਇਹ ਨਹੀਂ ਦਿੰਦਾ, ਤਾਂ ਕਲਾਇੰਟ ਨੂੰ ਦੁਬਾਰਾ ਸਥਾਪਿਤ ਕਰਨਾ ਪਵੇਗਾ, ਅਤੇ ਇਹ ਉਹ ਤੱਥ ਹੈ ਜੋ ਤੁਸੀਂ SA ਸੂਚੀ ਜਾਂ ਲੌਗ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹੋ, ਘੁੰਮਦੇ ਚੱਕਰ ਤੋਂ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਾਉਂਦੇ।
ਰਾਹ ਨੂੰ ਰੂਟ ਦੀ ਤਰਜੀਹ ਤੈਅ ਕਰਦੀ ਹੈ, Wi-Fi ਆਈਕਨ ਨਹੀਂ
ਦੋਵੇਂ ਇੰਟਰਫ਼ੇਸ ਉੱਪਰ ਹੋਣ ’ਤੇ ਕਰਨਲ ਮੈਟ੍ਰਿਕ ਅਤੇ ਪ੍ਰੀਫ਼ਿਕਸ ਲੰਬਾਈ ਨਾਲ ਚੁਣਦਾ ਹੈ। ip route show default ਉਮੀਦਵਾਰਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਅਤੇ ip route get 203.0.113.10 ਸਰੋਤ ਪਤੇ ਸਮੇਤ ਅਸਲ ਫ਼ੈਸਲਾ ਸੁਲਝਾਉਂਦਾ ਹੈ। ਮੈਟ੍ਰਿਕ 100 ’ਤੇ ਤਾਰ ਵਾਲਾ ਡਿਫ਼ਾਲਟ ਅਤੇ 600 ’ਤੇ ਵਾਇਰਲੈੱਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੇਬਲ ਬੈਠਦੇ ਹੀ ਅੰਤਿਮ ਬਿੰਦੂ ਹਿੱਲ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਪਹਿਲਾਂ ਸਾਕਟ ਖੋਲ੍ਹ ਚੁੱਕੀ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਆਪਣਾ ਪੁਰਾਣਾ ਸਰੋਤ ਰੱਖਦੀ ਹੈ।
Windows ਵੀ ਸਵੈਚਾਲਿਤ ਇੰਟਰਫ਼ੇਸ ਮੈਟ੍ਰਿਕ ਨਾਲ ਇਹੀ ਕਰਦਾ ਹੈ, ਲਿੰਕ ਗਤੀ ਨਾਲ ਪੱਖਪਾਤ ਲੈਂਦਾ। Get-NetRoute -DestinationPrefix 0.0.0.0/0 ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਤਰਤੀਬ ਦਿੰਦਾ ਹੈ ਅਤੇ Find-NetRoute -RemoteIPAddress 203.0.113.10 ਸਟੈਕ ਜੋ ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਸਰੋਤ ਚੁਣੇਗਾ ਉਹ ਵਾਪਸ ਦਿੰਦਾ ਹੈ। ਆਪਣੀ ਬਾਹਰੀ ਸਾਕਟ ਇੱਕ ਇੰਟਰਫ਼ੇਸ ਨਾਲ ਬੰਨ੍ਹਣ ਵਾਲਾ ਕਲਾਇੰਟ ਮੈਟ੍ਰਿਕ ਪਲਟਣ ਤੋਂ ਬਾਅਦ ਵੀ ਉਹੀ ਵਰਤਦਾ ਹੈ; ਇਹ ਬੰਨ੍ਹਣ ਦਾ ਫ਼ੈਸਲਾ ਹੈ, ਰੂਟਿੰਗ ਦੀ ਖਰਾਬੀ ਨਹੀਂ।
Android ਵੰਡ ਨੂੰ ਦਿੱਸਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ: ConnectivityManager ਉਪਲਬਧ ਨੈੱਟਵਰਕ ਅਤੇ ਵੱਖਰਾ ਡਿਫ਼ਾਲਟ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਸਾਕਟ ਨੂੰ Network ਆਬਜੈਕਟ ਨਾਲ ਬੰਨ੍ਹਣ ਵਾਲੀ VPN ਐਪ ਦੁਬਾਰਾ ਨਾ ਬੰਨ੍ਹਣ ਤੱਕ ਉਹ ਬੰਨ੍ਹਾਅ ਰੱਖਦੀ ਹੈ। macOS ’ਤੇ, scutil --nwi ਪ੍ਰਾਇਮਰੀ ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਸਿਸਟਮ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਕ੍ਰਮ ਛਾਪਦਾ ਹੈ।
DNS, MTU ਅਤੇ IPv6 ਜੁੜਾਅ ਦੇ ਨਾਲ ਹਿੱਲਦੇ ਹਨ
ਨਵਾਂ ਜੁੜਾਅ ਨਵੇਂ ਰਿਜ਼ੋਲਵਰ ਲਿਆਉਂਦਾ ਹੈ। systemd-resolved ਨਾਲ DNS ਪ੍ਰਤੀ-ਲਿੰਕ ਹੁੰਦਾ ਹੈ, resolvectl status ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਲਿੰਕ ਨਾਮ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਆਪਣਾ ਰਿਜ਼ੋਲਵਰ ਵੰਡਣ ਵਾਲਾ ਮਹਿਮਾਨ ਨੈੱਟਵਰਕ ਲਿੰਕ ਦੁਬਾਰਾ ਤਰਜੀਹੀ ਹੋਣ ਤੱਕ ਟਨਲ ਵੱਲੋਂ ਧੱਕੇ ਗਏ DNS ਨੂੰ ਵਰਤੇ ਬਿਨਾਂ ਛੱਡ ਸਕਦਾ ਹੈ। ਕੈਪਟਿਵ ਪੋਰਟਲ ਇਸਨੂੰ ਹੋਰ ਵਿਗਾੜਦਾ ਹੈ: ਪਹਿਲੀ HTTPS ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਅੰਤਿਮ ਬਿੰਦੂ ਦੀ ਥਾਂ ਪੋਰਟਲ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਮਰੇ ਸਰਵਰ ਨੂੰ ਦਰਜ ਕਰਦਾ ਹੈ।
ਰਾਹ ਦਾ MTU ਵੀ ਬਦਲਦਾ ਹੈ। Ethernet ਅਤੇ Wi-Fi ਆਮ ਤੌਰ ’ਤੇ 1500 ਬਾਈਟ ਢੋਂਦੇ ਹਨ, PPPoE 1492, ਅਤੇ ਮੋਬਾਈਲ ਲਿੰਕ ਅਕਸਰ ਘੱਟ। ਛੋਟਾ MTU ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਣ ’ਤੇ ਟਨਲ ਵੱਡੇ ਪੈਕਟਾਂ ’ਤੇ ਅਟਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਲੰਘ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸਨੂੰ ਅੱਧ-ਟੁੱਟੀ ਕਨੈਕਸ਼ਨ ਵਜੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ping -M do -s 1472 203.0.113.10 DF ਸੈੱਟ ਕੀਤੇ 1500 ਬਾਈਟ ਦਾ ਪੈਕਟ ਭੇਜਦਾ ਹੈ; ਚੁੱਪ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਰਾਹ ਤੁਹਾਡੇ ਅੰਦਾਜ਼ੇ ਤੋਂ ਛੋਟਾ ਹੈ।
IPv6 ਦੂਜਾ ਅੱਧ ਹੈ। ਨਵਾਂ ਪ੍ਰੀਫ਼ਿਕਸ ਦੇਣ ਵਾਲਾ ਨੈੱਟਵਰਕ ਦੋਹਰੀ ਸਟੈਕ ਵਾਲੇ ਕਲਾਇੰਟ ਦਾ ਸਰੋਤ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ v4 ਵਾਲੀ ਟਨਲ ਨੀਤੀ ਆਉਣ ਤੱਕ v6 ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਬਾਹਰ ਰੱਖਦੀ ਹੈ। ip -6 route show default ਅਤੇ ip -6 addr show ਨਵੇਂ ਲਿੰਕ ਨੂੰ v6 ਰਾਹ ਹੈ ਕਿ ਨਹੀਂ ਇਸਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ।
ਵਰਣਨ ਕਰਨ ਦੀ ਥਾਂ ਸੰਕ੍ਰਮਣ ਨੂੰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰੋ
ਇੱਕ ਨਿਰਦੋਸ਼ ਬੇਨਤੀ ਚੁਣੋ ਅਤੇ ਬਦਲਾਅ ਦੇ ਦੋਵੇਂ ਪਾਸਿਆਂ ’ਤੇ ਉਹੀ ਤਿੰਨ ਕਮਾਂਡ ਚਲਾਓ: ip -br addr, ip route show default, ip route get 203.0.113.10। ਫਿਰ ਵੇਖੋ ਕਿ ਟਨਲ ਅਜੇ ਵੀ ਪੈਕਟ ਛੱਡਦੀ ਹੈ ਜਾਂ ਨਹੀਂ - tcpdump -ni any udp port 51820 WireGuard ਲਈ, ਬਾਕੀ ਸਭ ਲਈ ਮਿਲਦਾ ਪੋਰਟ। ਪੁਰਾਣੇ ਸਰੋਤ ਤੋਂ ਨਿਕਲਦੇ ਪੈਕਟ ਬੰਨ੍ਹਾਅ ਦੀ ਸਮੱਸਿਆ ਹਨ। ਨਵੇਂ ਸਰੋਤ ਤੋਂ ਜਵਾਬ ਬਿਨਾਂ ਨਿਕਲਦੇ ਪੈਕਟ ਪਰਲੇ ਪਾਸੇ ਜਾਂ ਵਿਚਕਾਰਲੇ NAT ਦਾ ਮਤਲਬ ਹਨ।
ਪਹਿਲੀ ਖਰਾਬੀ ਨਾਲ ਕਿਹੜੀ ਘਟਨਾ ਮੇਲ ਖਾਂਦੀ ਸੀ ਨੋਟ ਕਰੋ: ਲਿੰਕ ਥੱਲੇ, ਪਤਾ ਬਦਲਾਅ, ਜਾਂ ਡਿਫ਼ਾਲਟ ਰੂਟ ਬਦਲਾਅ। ਇਹ ਵੱਖਰੇ ਜ਼ਿੰਮੇਵਾਰਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ - ਦੁਬਾਰਾ ਬੰਨ੍ਹਣ ਵਾਲਾ ਕਲਾਇੰਟ, ਦੁਬਾਰਾ ਲੈਣ ਵਾਲਾ ਪਤਾ, ਜਾਂ ਸੰਰਚਨਾ ਫ਼ਾਈਲ ਦਾ, ਸਥਾਈ ਬਾਈਪਾਸ ਨਿਯਮ ਦਾ ਨਾ ਹੋਣ ਵਾਲਾ ਰੂਟ।
ਠੀਕ ਹੋਇਆ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਿੱਧੇ ਟ੍ਰੈਫ਼ਿਕ ਦਾ ਬਲਾਕ ਵਿਚਾਲੇ ਦੌਰਾਨ ਵੀ ਟਿਕਿਆ ਹੈ ਅਤੇ ਨਾਮ ਨਵੇਂ ਜੁੜਾਅ ਰਾਹੀਂ ਹੱਲ ਹੁੰਦੇ ਹਨ। ਜੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਵੀ ਕਲਾਇੰਟ ਪੁਰਾਣਾ ਅੰਤਿਮ ਬਿੰਦੂ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਰੋਮਿੰਗ ਜਾਂ float ਸੈਟਿੰਗ ਠੀਕ ਕਰੋ। ਜੇ ਠੀਕ ਰੋਮਿੰਗ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਜਵਾਬ ਨਹੀਂ ਮਿਲਦਾ, ਤਾਂ ਸਰਵਰ ਦੀ ਪੀਅਰ ਪਛਾਣ ਅਤੇ ਰਾਹ ਦੇ NAT ਵੱਲ ਵੇਖੋ, ਅਤੇ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਤੁਲਨਾ ਕਰਨ ਲਈ ਦੋਵੇਂ ਨੈੱਟਵਰਕ ਸੰਦਰਭ ਰਿਪੋਰਟ ਵਿੱਚ ਰੱਖੋ।