WireGuard PersistentKeepalive: NAT ਮੈਪਿੰਗ ਨੂੰ ਜੀਵਤ ਰੱਖੋ
ਜੇ ਉਲਟਾ ਕਨੈਕਸ਼ਨ ਸਿਰਫ਼ ਪੀਅਰ ਵੱਲੋਂ ਟ੍ਰੈਫਿਕ ਭੇਜਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਮੈਪਿੰਗ ਖਤਮ ਹੋ ਰਹੀ ਹੈ। ਰਾਊਟਰ ਦੇ ਪਿੱਛੇ keepalive ਸੈੱਟ ਕਰੋ ਅਤੇ ਫਿਰ ਅਸਲ ਸਮਾਂ-ਸੀਮਾ ਪੜ੍ਹੋ।
ਘਰ ਦਾ ਬਕਸਾ ਸੁਰੰਗ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਬਿਨਾਂ ਕਿਸੇ ਮੁਸ਼ਕਲ ਦੇ ਕਲਾਊਡ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਘਰ ਦੇ ਬਕਸੇ ਵੱਲੋਂ ਆਖਰੀ ਵਾਰ ਕੁਝ ਭੇਜਣ ਤੋਂ ਬਾਅਦ ਕਲਾਊਡ ਸਰਵਰ ਇੱਕ ਜਾਂ ਦੋ ਮਿੰਟ ਲਈ ਘਰ ਦੇ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਰੁਕ ਜਾਂਦਾ ਹੈ। WireGuard ਲਾਗ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਦਿਸਦਾ, ਕੋਈ ਹੈਂਡਸ਼ੇਕ ਗਲਤੀ ਦੀ ਰਿਪੋਰਟ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਸੁਰੰਗ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਇਹ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਠੀਕ ਹੋ ਜਾਂਦੀ ਹੈ। ਉਹ ਪੈਟਰਨ ਖਤਮ ਹੋ ਰਹੀ ਮੈਪਿੰਗ ਹੈ, ਟੁੱਟੀ ਸੁਰੰਗ ਨਹੀਂ, ਅਤੇ ਹੇਠਾਂ ਦਿੱਤੀ ਗਾਈਡ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ।
ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪੈਟਰਨ ਨਿਸ਼ਕਿਰਿਆ ਵਿੱਚ ਖਤਮ ਹੋਣਾ ਹੈ
ਵੱਖਰਾ ਕਰਨ ਵਾਲਾ ਵੇਰਵਾ ਸਮਾਂ ਹੈ। ਜੇ ਉਲਟਾ ਕਨੈਕਸ਼ਨ ਘਰ ਦੇ ਪੀਅਰ ਵੱਲੋਂ ਟ੍ਰੈਫਿਕ ਭੇਜਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਸ਼ਾਂਤ ਅੰਤਰਾਲ ਤੋਂ ਬਾਅਦ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਰਸਤਾ ਠੀਕ ਹੈ ਅਤੇ ਵਿਚਕਾਰਲੀ ਸਥਿਤੀ ਨਹੀਂ। ਜੇ ਇਹ ਕਦੇ ਕੰਮ ਨਹੀਂ ਕੀਤਾ, ਟ੍ਰੈਫਿਕ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਵੀ ਨਹੀਂ, ਤਾਂ ਇਹ ਗਲਤ ਨਿਦਾਨ ਹੈ।
sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transferਘਰ ਦੇ ਪੀਅਰ ਵੱਲੋਂ ਕੁਝ ਭੇਜਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਪਹਿਲੇ ਦੋ ਚਲਾਓ, ਪੰਜ ਮਿੰਟ ਉਡੀਕ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਚਲਾਓ। ਨਵੇਂ ਐਂਡਪੁਆਇੰਟ ਤੋਂ ਬਿਨਾਂ ਸ਼ਡਿਊਲ ਅਨੁਸਾਰ ਨਵੀਨੀਕਰਨ ਹੋਣ ਵਾਲਾ ਹੈਂਡਸ਼ੇਕ ਟਾਈਮਸਟੈਂਪ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਸੁਰੰਗ ਜੀਵਤ ਹੈ। ਜੋ ਬਦਲਿਆ ਉਹ ਬਾਹਰੋਂ ਬਿਨਾਂ ਮੰਗੇ ਪੈਕਟਾਂ ਦੇ ਆਉਣ ਦੀ ਸਮਰੱਥਾ ਹੈ, ਜੋ ਸੁਰੰਗ ਦੀ ਨਹੀਂ, ਰਸਤੇ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ।
ਫਿਰ ਉਲਟਾ ਯਤਨ ਕਰੋ ਅਤੇ ਟ੍ਰਾਂਸਫਰ ਕਾਊਂਟਰ ਦੇਖੋ। ਜੇ ਕਲਾਊਡ ਪਾਸਾ ਬਾਈਟ ਭੇਜਦਾ ਹੈ ਅਤੇ ਘਰ ਵਾਲਾ ਪਾਸਾ ਇੱਕ ਵੀ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਪੈਕਟ ਕਲਾਊਡ ਛੱਡ ਗਿਆ ਅਤੇ ਰਸਤੇ ਵਿੱਚ ਸਥਿਤੀ ਰੱਖਣ ਵਾਲੇ ਯੰਤਰ ਵਿੱਚ ਮਰ ਗਿਆ। ਤੁਸੀਂ ਜਿਸ ਦਸਤਖਤ ਦੀ ਭਾਲ ਕਰ ਰਹੇ ਹੋ ਉਹ ਇਹੀ ਹੈ। ਜੇ ਦੋਵੇਂ ਕਾਊਂਟਰ ਚੱਲਦੇ ਹਨ, ਤਾਂ ਸੁਰੰਗ ਨੇ ਪੈਕਟ ਪਹੁੰਚਾ ਦਿੱਤਾ ਅਤੇ ਸ਼ੱਕੀ ਐਪਲੀਕੇਸ਼ਨ ਹੈ।
keepalive ਰਾਊਟਰ ਦੇ ਪਿੱਛੇ ਵਾਲੇ ਪੀਅਰ ਉੱਤੇ ਰੱਖੋ
ਸਥਾਈ keepalive ਸ਼ਡਿਊਲ ਅਨੁਸਾਰ ਛੋਟਾ ਪ੍ਰਮਾਣਿਤ ਪੈਕਟ ਭੇਜ ਕੇ NAT ਮੈਪਿੰਗ ਅਤੇ ਕਿਸੇ ਵੀ ਫਾਇਰਵਾਲ ਸਥਿਤੀ ਨੂੰ ਜੀਵਤ ਰੱਖਦੇ ਹਨ। ਸੈਟਿੰਗ ਰਾਊਟਰ ਦੇ ਪਿੱਛੇ ਵਾਲੀ ਮਸ਼ੀਨ ਉੱਤੇ, ਦੂਰ ਦੇ ਪੀਅਰ ਲਈ ਉਸ ਦੀ ਐਂਟਰੀ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਉਸੇ ਪਾਸੇ ਦਾ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਪੈਕਟ ਸਥਿਤੀ ਬਣਾਉਂਦਾ ਹੈ।
[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25ਇਸ ਨੂੰ ਮੌਜੂਦਾ ਪੀਅਰ ਭਾਗ ਵਿੱਚ ਮਿਲਾਓ। ਉਸੇ ਜਨਤਕ ਕੁੰਜੀ ਨਾਲ ਦੂਜਾ ਬਲਾਕ ਜੋੜਨਾ ਵਿਕਲਪ ਜੋੜਨ ਦਾ ਸਹੀ ਤਰੀਕਾ ਨਹੀਂ ਹੈ, ਅਤੇ wg-quick ਉਹਨਾਂ ਨੂੰ ਤੁਹਾਡੇ ਲਈ ਨਹੀਂ ਮਿਲਾਏਗਾ। ਦਰਜ 25 ਸਕਿੰਟ ਆਮ UDP ਸਮਾਂ-ਸੀਮਾਵਾਂ ਤੋਂ ਹੇਠਾਂ ਰਹਿਣ ਲਈ ਚੁਣਿਆ ਗਿਆ ਉਦਾਹਰਨ ਹੈ, ਵਿਸ਼ੇਸ਼ ਅਰਥ ਵਾਲਾ ਮੁੱਲ ਨਹੀਂ।
ਉਹੀ ਨਿਰਦੇਸ਼ ਕਲਾਊਡ ਪਾਸੇ ਰੱਖਣ ਨਾਲ ਇਸ ਸਮੱਸਿਆ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਮਿਲਦੀ। ਉਸ ਪੀਅਰ ਦੇ ਪੈਕਟ ਪਹਿਲਾਂ ਹੀ ਜਨਤਕ ਪਤੇ ਤੋਂ ਆ ਰਹੇ ਹਨ, ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਦਿਸ਼ਾ ਵਿੱਚ ਬਚਾਉਣ ਲਈ ਕੋਈ ਮੈਪਿੰਗ ਨਹੀਂ। ਇਹ ਟ੍ਰੈਫਿਕ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
ਅੰਤਰਾਲ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਬਜਾਏ ਟਾਈਮਰ ਪੜ੍ਹੋ
keepalive ਇਸ ਲਈ ਕੰਮ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸਥਿਤੀ ਖਤਮ ਹੋਣ ਤੋਂ ਵੱਧ ਵਾਰ ਆਉਂਦੇ ਹਨ। ਇਹ ਸਮਾਂ-ਸੀਮਾ ਨੂੰ ਉਹ ਸੰਖਿਆ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ Linux ਉੱਤੇ ਇਹ ਅਨੁਵਾਦ ਕਰਨ ਵਾਲੇ ਯੰਤਰ ਉੱਤੇ ਪੜ੍ਹੀ ਜਾ ਸਕਦੀ ਹੈ:
sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820ਪਹਿਲਾ ਮੁੱਲ ਉਸ UDP ਪ੍ਰਵਾਹ ਲਈ ਸਮਾਂ-ਸੀਮਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਦੇਖਿਆ ਗਿਆ ਹੈ, ਅਤੇ ਦੂਜਾ ਜਵਾਬ ਦੇਖੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਦੋਵੇਂ ਆਮ ਤੌਰ ਉੱਤੇ ਛੋਟੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸ਼ਾਂਤ ਹੋਣ ਵਾਲੀ ਮੈਪਿੰਗ ਤੁਹਾਡੇ ਪ੍ਰਵਾਹ ਉੱਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲੇ ਦੀ ਪਾਲਣਾ ਕਰੇਗੀ।
ਉਸ ਸੰਖਿਆ ਦੀ ਤੁਲਨਾ ਆਪਣੇ ਅੰਤਰਾਲ ਨਾਲ ਕਰੋ। 30 ਸਕਿੰਟ ਦੀ ਸਮਾਂ-ਸੀਮਾ ਹੇਠ 25 ਸਕਿੰਟ ਦਾ keepalive ਕੰਮ ਕਰਦਾ ਹੈ; ਉਹੀ keepalive 15 ਸਕਿੰਟ ਦੀ ਸਮਾਂ-ਸੀਮਾ ਹੇਠ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਕਿੰਨੀ ਵੀ ਵਾਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਇਹ ਗਣਿਤ ਨਹੀਂ ਬਦਲਦਾ। ਕੁਝ ਖਪਤਕਾਰ ਰਾਊਟਰ ਅਤੇ ਮੋਬਾਈਲ ਆਪਰੇਟਰ Linux ਦੇ ਡਿਫਾਲਟ ਤੋਂ ਬਹੁਤ ਛੋਟੇ ਮੁੱਲ ਵਰਤਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਨੈੱਟਵਰਕ ਉੱਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਕਨਫਿਗਰੇਸ਼ਨ ਦੂਜੇ ਉੱਤੇ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ।
| Observation | What it means | Reasonable response |
|---|---|---|
| Works after traffic, dies when idle | Mapping or firewall state expiring | Lower the keepalive interval |
| Never works, even immediately | No return route, listener or firewall | Stop tuning keepalive |
| Works for hours, then dies once | Carrier-side translation or address change | Check the endpoint and logs together |
ਸਰੋਤਾ ਅਤੇ ਫਾਇਰਵਾਲ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ਉੱਤੇ ਜਾਂਚੋ
ਜੀਵਤ ਮੈਪਿੰਗ ਜ਼ਰੂਰੀ ਹੈ ਅਤੇ ਕਾਫ਼ੀ ਨਹੀਂ। ਘਰ ਦੇ ਬਕਸੇ ਉੱਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਹੀ ਪਤੇ ਉੱਤੇ ਸੁਣਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਹੋਸਟ ਫਾਇਰਵਾਲ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਹੋਣ ਤੋਂ ਬਾਅਦ ਪੈਕਟ ਦੀ ਆਗਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ।
sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/healthਜੇ ਸਾਕਟ ਸਿਰਫ਼ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਦੇ ਪਤੇ ਨਾਲ ਬੱਝਾ ਹੈ, ਸੁਰੰਗ ਦੇ ਪਤੇ ਨਾਲ ਨਹੀਂ, ਤਾਂ ਸੁਰੰਗ ਉੱਤੇ ਆਉਣ ਵਾਲੇ ਪੈਕਟ ਫਾਇਰਵਾਲ ਨੂੰ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਇਹ ਫੇਲ੍ਹਤਾ ਕਲਾਊਡ ਪਾਸੇ ਤੋਂ ਮੈਪਿੰਗ ਸਮੱਸਿਆ ਵਾਂਗ ਹੀ ਦਿਸਦੀ ਹੈ, ਅਤੇ ਹਰ keepalive ਸਮਾਯੋਜਨ ਨੂੰ ਬਰਦਾਸ਼ਤ ਕਰਦੀ ਹੈ।
ਇਜਾਜ਼ਤ ਵਾਲੀ ਸੂਚੀ ਦੀ ਜਾਂਚ ਦੂਜੀ ਦਿਸ਼ਾ ਵਿੱਚ ਵੀ ਉਨੀ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਕਲਾਊਡ ਪੀਅਰ ਨੂੰ ਜਵਾਬ ਦੇਣਾ ਹੋਵੇ ਤਾਂ ਘਰ ਦੀ ਸੁਰੰਗ ਦੇ ਪਤੇ ਨੂੰ ਸਰੋਤ ਵਜੋਂ ਇਜਾਜ਼ਤ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਘਰ ਦੇ ਪੀਅਰ ਨੂੰ ਕਲਾਊਡ ਪਤੇ ਨੂੰ ਮੰਜ਼ਿਲ ਵਜੋਂ ਇਜਾਜ਼ਤ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ। keepalive ਪੈਕਟ ਪ੍ਰਮਾਣਿਤ ਟ੍ਰੈਫਿਕ ਹਨ ਅਤੇ ਉਹੀ ਨਿਯਮ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਦਿਸਣ ਵਾਲਾ keepalive ਕੰਮ ਨਾ ਕਰਨ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਰਹਿ ਸਕਦਾ ਹੈ।
ਬਦਲਾਅ ਨੂੰ ਰੋਲ ਆਉਟ ਕਰੋ ਅਤੇ ਇਸ ਦੀਆਂ ਹੱਦਾਂ ਜਾਣੋ
ਸੈਟਿੰਗ ਲਾਗੂ ਕਰੋ, ਜੇ ਇਹ ਤੁਹਾਡਾ ਅਪਡੇਟ ਤਰੀਕਾ ਹੈ ਤਾਂ ਇੰਟਰਫੇਸ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ, ਅਤੇ ਫਿਰ ਤੁਰੰਤ ਟੈਸਟ ਦੀ ਬਜਾਏ ਨਿਸ਼ਕਿਰਿਆ ਟੈਸਟ ਦੁਹਰਾਓ। ਪਹਿਲਾਂ ਪੜ੍ਹੀ ਸਮਾਂ-ਸੀਮਾ ਤੋਂ ਵੱਧ ਉਡੀਕ ਕਰੋ, ਉਲਟੀ ਬੇਨਤੀ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਦੋਵੇਂ ਸਿਰਿਆਂ ਉੱਤੇ ਕਾਊਂਟਰ ਚੱਲੇ ਹਨ।
ਅੰਤਰਾਲ ਅਤੇ ਮਾਪੀ ਸਮਾਂ-ਸੀਮਾ ਨੂੰ ਉਸ ਦੇ ਕੋਲ ਦਰਜ ਕਰੋ। ਭਵਿੱਖ ਵਿੱਚ ਰਾਊਟਰ ਦੇ ਫਰਮਵੇਅਰ ਵਿੱਚ ਬਦਲਾਅ, ਜਾਂ ਮੋਬਾਈਲ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਜਾਣਾ, ਸਮਾਂ-ਸੀਮਾ ਬਦਲ ਸਕਦਾ ਹੈ। ਨੋਟ ਹੀ ਕਿਸੇ ਨੂੰ ਮੁੱਲ ਕਾਪੀ ਕਰਨ ਦੀ ਬਜਾਏ ਦੁਬਾਰਾ ਕੱਢਣ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਦੋ ਸੰਖਿਆਵਾਂ ਬਾਅਦ ਵਿੱਚ ਪੂਰੀ ਜਾਂਚ ਬਚਾਉਂਦੀਆਂ ਹਨ।
ਸਥਾਈ keepalive ਸਥਿਤੀ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ। ਉਹ ਪੋਰਟ ਨਹੀਂ ਖੋਲ੍ਹਦੇ, ਇਜਾਜ਼ਤ ਵਾਲੀ ਸੂਚੀ ਵਿੱਚ ਐਂਟਰੀ ਨਹੀਂ ਜੋੜਦੇ, ਅਤੇ ਕਿਸੇ ਸਰੋਤੇ ਨੂੰ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰਦੇ। ਜਦੋਂ ਉਲਟਾ ਕਨੈਕਸ਼ਨ ਬਿਲਕੁਲ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਦੋਸ਼ ਉਹਨਾਂ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਅਤੇ WireGuard ਦੀ ਤੇਜ਼ ਸ਼ੁਰੂਆਤ keepalive ਸੈਟਿੰਗ ਦਾ ਵਰਣਨ ਉਹਨਾਂ ਹੀ ਸੰਖੇਪ ਸ਼ਰਤਾਂ ਵਿੱਚ ਕਰਦੀ ਹੈ।