WireGuard: ਸਬਨੈੱਟ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਪੀਅਰ ਤੱਕ ਕੋਈ ਰੂਟ ਨਹੀਂ — ਦੋ ਰਾਹ
ਸਬਨੈੱਟ ਬਦਲਾਅ WireGuard ਨੂੰ ਦੋ ਥਾਵਾਂ ’ਤੇ ਤੋੜਦਾ ਹੈ: AllowedIPs ਅਤੇ ਵਾਪਸੀ ਦਾ ਰਾਹ। ਜਗ੍ਹਾ ’ਤੇ ਮੁੜ-ਨੰਬਰੀ ਅਤੇ ਇੰਟਰਫ਼ੇਸ ਮੁੜ ਬਣਾਉਣ ਦੀ ਤੁਲਨਾ ਕਰੋ।
wg show ਵਿੱਚ ਹੈਂਡਸ਼ੇਕ ਤਾਜ਼ਾ ਹੈ, ਐਂਡਪੁਆਇੰਟ ਸਹੀ ਹੈ, ਕੁੰਜੀਆਂ ਕਦੇ ਨਹੀਂ ਬਦਲੀਆਂ — ਅਤੇ ping ਫਿਰ ਵੀ ਕਹਿੰਦਾ ਹੈ ਕਿ ਪੀਅਰ ਤੱਕ ਕੋਈ ਰੂਟ ਨਹੀਂ। ਇੱਕ ਘੰਟਾ ਪਹਿਲਾਂ ਤੁਸੀਂ ਟਨਲ ਦਾ ਸਬਨੈੱਟ ਬਦਲਿਆ ਸੀ। ਉਹ ਲੱਛਣ ਕੁੰਜੀ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ, ਪ੍ਰੀਫ਼ਿਕਸ ਦੀ ਅਸੰਗਤ ਦਾ ਚਿੰਨ੍ਹ ਹੈ: WireGuard ਨੇ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਕੀਤਾ ਅਤੇ ਫਿਰ ਡੇਟਾ ਸੁੱਟ ਦਿੱਤਾ, ਕਿਉਂਕਿ ਸਰੋਤ ਪਤਾ ਹੁਣ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਪੀਅਰ ਵੱਲੋਂ ਮਨਜ਼ੂਰ ਕੀਤੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਸਬਨੈੱਟ ਬਦਲਾਅ ਲਾਗੂ ਕਰਨ ਦੇ ਦੋ ਸਮਝਦਾਰ ਤਰੀਕੇ ਹਨ ਅਤੇ ਉਹ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ ’ਤੇ ਅਸਫਲ ਹੁੰਦੇ ਹਨ।
ਬਦਲਾਅ ਲਾਗੂ ਕਰਨ ਦੇ ਦੋ ਤਰੀਕੇ ਅਤੇ ਹਰੇਕ ਦੀ ਕੀਮਤ
ਵਿਕਲਪ A ਜਗ੍ਹਾ ’ਤੇ ਮੁੜ-ਨੰਬਰੀ ਹੈ: ਇੰਟਰਫ਼ੇਸ ਦਾ ਪਤਾ, ਪੀਅਰ ਦੀਆਂ ਸੀਮਾਵਾਂ, ਰੂਟ ਅਤੇ ਕਾਨਫ਼ਿਗ ਦੀ ਹਰ ਕਾਪੀ ਸੋਧੋ, ਫਿਰ ਮੁੜ ਲੋਡ ਕਰੋ। ਵਿਕਲਪ B ਨਵੇਂ ਪ੍ਰੀਫ਼ਿਕਸ ’ਤੇ ਪੁਰਾਣੇ ਦੇ ਕੋਲ ਦੂਜਾ ਇੰਟਰਫ਼ੇਸ ਬਣਾਉਣਾ, ਪੀਅਰ ਸ਼ਿਫ਼ਟ ਕਰਨਾ ਅਤੇ ਟਰੈਫ਼ਿਕ ਅਸਲ ਵਿੱਚ ਸ਼ਿਫ਼ਟ ਹੋਣ ਤੋਂ ਬਾਅਦ ਪੁਰਾਣਾ ਇੰਟਰਫ਼ੇਸ ਹਟਾਉਣਾ ਹੈ।
| A: renumber in place | B: parallel interface | |
|---|---|---|
| Downtime | The reload window, per host | None if peers are added to both |
| Rollback | Re-apply the previous files | Point peers back at the old interface |
| Risk | Half-applied change: new address, old ranges | Two live interfaces with overlapping intent |
| Effort | Small, if the deployment has one owner | Higher, and needs a cleanup step |
| Fits | Two or three peers you control | Many peers, remote sites, or no maintenance window |
ਅੱਧਾ ਲਾਗੂ ਹੋਇਆ ਹਾਲ ਹੀ ਵਿਕਲਪ A ਨੂੰ ਖ਼ਤਰਨਾਕ ਬਣਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਟੁੱਟਿਆ ਨਹੀਂ ਦਿਸਦਾ। ਇੰਟਰਫ਼ੇਸ ਉੱਪਰ ਆਉਂਦਾ ਹੈ, ਹੈਂਡਸ਼ੇਕ ਸਫਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਡੇਟਾ ਦਾ ਰਾਹ ਅਸਫਲ ਹੁੰਦਾ ਹੈ। ਵਿਕਲਪ B ਵਧੇਰੇ ਕੰਮ ਮੰਗਦਾ ਹੈ ਪਰ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਹਰ ਹਵਾਲਾ ਲੱਭਦੇ ਹੋ, ਕੰਮ ਕਰਨ ਵਾਲਾ ਰਾਹ ਜੀਵਿਤ ਰੱਖਦਾ ਹੈ।
ਤੁਹਾਡੇ ਪਾਸੇ ਕੀ ਇਕੱਠਾ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ
ਲੋਕਲ ਹੋਸਟ ’ਤੇ ਚਾਰ ਚੀਜ਼ਾਂ ਇੱਕੋ ਸਬਨੈੱਟ ਦੱਸਦੀਆਂ ਹਨ ਅਤੇ ਇੱਕ ਬਦਲਣਾ ਸਭ ਬਦਲਣਾ ਹੈ: ਇੰਟਰਫ਼ੇਸ ਦਾ ਪਤਾ, ਹਰ ਪੀਅਰ ਦਾ AllowedIPs, ਉਹ ਰੂਟ ਜੋ ਸਿਸਟਮ ਉਨ੍ਹਾਂ ਮੰਜ਼ਿਲਾਂ ਲਈ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਮੈਨੇਜਰ ਤੁਹਾਡੇ ਵੱਲੋਂ ਜੋ ਵੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ। wg-quick ਨਾਲ ਆਖ਼ਰੀ ਦੋ ਹਰ ਵਾਰ ਇੰਟਰਫ਼ੇਸ ਉੱਪਰ ਆਉਣ ’ਤੇ ਕਾਨਫ਼ਿਗ ਤੋਂ ਬਣਦੇ ਹਨ, ਇਸ ਲਈ ਪੁਰਾਣੀ ਕਾਪੀ ਚੁੱਪਚਾਪ ਪੁਰਾਣਾ ਪ੍ਰੀਫ਼ਿਕਸ ਮੁੜ ਸਥਾਪਿਤ ਕਰ ਦਿੰਦੀ ਹੈ।
ਕਿਸੇ ਇੱਕ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਕਾਨਫ਼ਿਗਰ ਕੀਤੇ ਦੀ ਤੁਲਨਾ ਜੀਵਿਤ ਨਾਲ ਕਰੋ:
wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5ਰੂਟ ਖੋਜ ਉਹ ਕਦਮ ਹੈ ਜੋ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਕਰਨਲ ਕਿਸੇ ਮੰਜ਼ਿਲ ਲਈ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰੇਗਾ, ਜਿਸ ਵਿੱਚ ਮੈਨੇਜਰ ਜਾਂ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਵੱਲੋਂ ਛੱਡਿਆ ਵਧੇਰੇ ਖ਼ਾਸ ਰੂਟ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਜੇ ਇਹ ਟਨਲ ਤੋਂ ਵੱਖਰਾ ਇੰਟਰਫ਼ੇਸ ਦਿਖਾਉਂਦੀ ਹੈ, ਤਾਂ ਕਾਨਫ਼ਿਗ ਸਮੱਸਿਆ ਨਹੀਂ।
ਚੱਲ ਰਹੇ ਇੰਟਰਫ਼ੇਸ ਲਈ, ਟਨਲ ਤੋੜੇ ਬਿਨਾਂ ਸੋਧੀ ਫ਼ਾਈਲ ਲਾਗੂ ਕਰੋ:
wg syncconf wg0 <(wg-quick strip wg0)ਇਹ ਪੀਅਰ ਅਤੇ ਸੀਮਾਵਾਂ ਜਗ੍ਹਾ ’ਤੇ ਹੀ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ। ਇਹ ਇੰਟਰਫ਼ੇਸ ਦਾ ਪਤਾ ਜਾਂ ਰੂਟ ਅੱਪਡੇਟ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਉਹ WireGuard ਸੈਟਿੰਗਾਂ ਨਹੀਂ ਹਨ — ਇਸ ਲਈ ਮੁੜ-ਨੰਬਰੀ ਲਈ ਅਜੇ ਵੀ ਇੰਟਰਫ਼ੇਸ ਮੁੜ ਬਣਾਉਣਾ ਜਾਂ ip ਨਾਲ ਪਤਾ ਬਦਲਣਾ ਅਤੇ ਫਿਰ ਰੂਟਿੰਗ ਮੁੜ ਜਾਂਚਣਾ ਲਾਜ਼ਮੀ ਹੈ।
ਦੂਰ ਵਾਲੇ ਸਿਰੇ ’ਤੇ ਕੀ ਇਕੱਠਾ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ
ਆਮ ਤੌਰ ’ਤੇ ਸਬਨੈੱਟ ਬਦਲਾਅ ਇੱਥੇ ਹੀ ਮਰਦਾ ਹੈ। AllowedIPs ਸਿਰਫ਼ ਰੂਟਿੰਗ ਸੰਕੇਤ ਨਹੀਂ; ਇਹ ਉਨ੍ਹਾਂ ਸਰੋਤ ਪਤਿਆਂ ਦੀ ਸੂਚੀ ਵੀ ਹੈ ਜੋ ਪੀਅਰ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਕਲਾਇੰਟਾਂ ਦੀ ਮੁੜ-ਨੰਬਰੀ ਕਰਦੇ ਹੋ ਅਤੇ ਸਰਵਰ ਦਾ AllowedIPs ਪੁਰਾਣੇ ਪ੍ਰੀਫ਼ਿਕਸ ’ਤੇ ਛੱਡ ਦਿੰਦੇ ਹੋ, ਸਰਵਰ ਹੈਂਡਸ਼ੇਕ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ, ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਪੈਕਟ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸੁੱਟ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਅੰਦਰਲਾ ਸਰੋਤ ਉਸ ਪੀਅਰ ਨਾਲ ਜੁੜੀ ਕਿਸੇ ਵੀ ਸੀਮਾ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ। ਕੋਈ ਗਲਤੀ ਲੌਗ ਨਹੀਂ ਹੁੰਦੀ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਸਮਾਂ-ਸਮਾਪਤੀ ਦਿਸਦੀ ਹੈ।
ਇਸ ਲਈ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਪਾਸੇ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਅੱਪਡੇਟ ਕਰੋ: ਸਰਵਰ ’ਤੇ ਪੀਅਰ ਐਂਟਰੀ ਵਿੱਚ ਨਵਾਂ ਕਲਾਇੰਟ ਪ੍ਰੀਫ਼ਿਕਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਰਵਰ ਦਾ ਆਪਣਾ ਵਾਪਸੀ ਰੂਟ ਉਸ ਪ੍ਰੀਫ਼ਿਕਸ ਲਈ ਟਨਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਪਿੱਛੇ ਕੋਈ ਵੀ ਹੇਠਲਾ ਨੈੱਟਵਰਕ ਨਵਾਂ ਰਾਹ ਸਿੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੁਰਾਣੀ ਸੀਮਾ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲੀ ਫ਼ਾਇਰਵਾਲ ਨੀਤੀ ਨੂੰ ਵੀ ਉਹੀ ਇਲਾਜ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਰੋਤ-ਆਧਾਰਿਤ ਚੋਣ ਕਰਨ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਵੀ।
ਦੋਵੇਂ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਵਾਲੀ ਜਾਂਚ ਸਸਤੀ ਹੈ। ਤਾਜ਼ਾ ਹੈਂਡਸ਼ੇਕ ਪਰ ਡੇਟਾ ਨਹੀਂ ਦਾ ਮਤਲਬ ਟਨਲ ਉੱਪਰ ਹੈ ਅਤੇ ਅੰਦਰਲੀ ਪਤਾ-ਪ੍ਰਣਾਲੀ ਸਹਿਮਤ ਨਹੀਂ। ਬਿਲਕੁਲ ਹੈਂਡਸ਼ੇਕ ਨਾ ਹੋਣ ਦਾ ਮਤਲਬ ਤੁਸੀਂ ਪਹੁੰਚ ਜਾਂ ਕੁੰਜੀਆਂ ਵੱਲ ਵੇਖ ਰਹੇ ਹੋ। ਪ੍ਰੀਫ਼ਿਕਸ ਸਮੱਸਿਆ ਲਈ ਕੁੰਜੀਆਂ ਨਾ ਘੁਮਾਓ; ਇਹ ਉਸ ਇੱਕੋ ਚੀਜ਼ ਨੂੰ ਰੀਸੈਟ ਕਰਦਾ ਹੈ ਜੋ ਕੰਮ ਕਰ ਰਹੀ ਸੀ।
ਤੁਹਾਡੀ ਸੋਧ ਤੋਂ ਵੱਧ ਜੀਉਣ ਵਾਲੀਆਂ ਪੁਰਾਣੀਆਂ ਕਾਪੀਆਂ
ਫ਼ਾਈਲ ਸੋਧਣਾ ਚੱਲ ਰਹੇ ਸਿਸਟਮ ਨੂੰ ਬਦਲਣਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਕਾਪੀਆਂ ਲੋਕਾਂ ਦੀ ਉਮੀਦ ਤੋਂ ਵੱਧ ਹੁੰਦੀਆਂ ਹਨ: ਇੰਟਰਫ਼ੇਸ ਦਾ ਮਾਲਕ ਯੂਨਿਟ ਜਾਂ ਮੈਨੇਜਰ, ਦੂਜੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਉਸੇ ਨਾਮ ਦੀ ਦੂਜੀ ਪ੍ਰੋਫ਼ਾਈਲ, ਇਮੇਜ ਵਿੱਚ ਕਾਨਫ਼ਿਗ ਬੇਕ ਕੀਤਾ ਕੰਟੇਨਰ, ਆਪਣਾ ਸੋਧਿਆ ਸੰਸਕਰਣ ਰੱਖਣ ਵਾਲਾ ਰਾਊਟਰ UI, ਅਤੇ ਸ਼ੁਰੂ ਹੁੰਦਿਆਂ ਸੰਭਾਲਿਆ ਟਨਲ ਮੁੜ ਆਯਾਤ ਕਰਨ ਵਾਲੀ ਕਲਾਇੰਟ ਐਪ। ਤੁਹਾਡਾ ਬਦਲਾਅ ਪੂਰਾ ਦਿਸਣ ਤੋਂ ਬਾਅਦ ਵੀ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਪੁਰਾਣਾ ਪ੍ਰੀਫ਼ਿਕਸ ਵਾਪਸ ਲਿਆ ਸਕਦੀ ਹੈ।
ਨਾਮ ਵੀ ਸਫ਼ਰ ਕਰਦੇ ਹਨ। ਜੇ ਸੰਖਿਆਤਮਕ ਰੂਟ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਹੋਸਟਨਾਮ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਅੰਦਰੂਨੀ DNS ਰਿਕਾਰਡ ਜਾਂ ਸੇਵਾ ਕਾਨਫ਼ਿਗ ਅਜੇ ਵੀ ਪੁਰਾਣੇ ਟਨਲ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਹਰ ਪੀਅਰ ਸੀਮਾ ਚੌੜੀ ਕਰਨ ਦੀ ਥਾਂ ਹਵਾਲਾ ਠੀਕ ਕਰੋ, ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਅਸਲ ਸਮੱਸਿਆ ਢਕੀ ਜਾਵੇਗੀ ਅਤੇ ਨਾਲ ਹੀ ਸਰੋਤ ACL ਵੱਡਾ ਹੋਵੇਗਾ।
ਕੰਮ ਕਰਦਿਆਂ ਇੱਕ ਬਹਾਲੀ ਰਾਹ ਖੁੱਲ੍ਹਾ ਰੱਖੋ: ਹੋਸਟ ਵਿੱਚ ਦਾਖ਼ਲ ਹੋਣ ਦਾ ਦੂਜਾ ਰਾਹ, ਸੀਰੀਅਲ ਕਨਸੋਲ, ਜਾਂ ਕਾਨਫ਼ਿਗ ਫ਼ਾਈਲਾਂ ਦਾ ਨਿਯਤ ਰੋਲਬੈਕ। ਜੋ ਟਨਲ ਬਦਲਾਅ ਤੁਹਾਨੂੰ ਉਸ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਤਾਲਾ ਲਗਾ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਬਦਲ ਰਹੇ ਹੋ, ਇਹ ਕੰਮ ਸ਼ਾਮ ਬਣਨ ਦਾ ਸਭ ਤੋਂ ਆਮ ਰਾਹ ਹੈ।
ਦੋਵਾਂ ਵਿੱਚੋਂ ਚੋਣ, ਅਤੇ ਕਟ ਦੀ ਪੁਸ਼ਟੀ
A ਚੁਣੋ ਜਦੋਂ ਹਰ ਪੀਅਰ ਤੁਹਾਡਾ ਹੈ, ਗਿਣਤੀ ਘੱਟ ਹੈ ਅਤੇ ਥੋੜ੍ਹਾ ਰੁਕਾਵਟ ਸਵੀਕਾਰਯੋਗ ਹੈ। B ਚੁਣੋ ਜਦੋਂ ਪੀਅਰ ਦੂਰ ਦੇ ਹੱਥ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰਦੇ, ਜਦੋਂ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਲਿੰਕ ਉੱਪਰ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ ਤੁਸੀਂ ਭਰੋਸਾ ਨਹੀਂ ਦੇ ਸਕਦੇ ਕਿ ਹਰ ਕਾਪੀ ਇੱਕ ਹੀ ਪਾਸ ਵਿੱਚ ਅੱਪਡੇਟ ਹੋਵੇਗੀ। ਉਸ ਹਾਲਤ ਵਿੱਚ ਨਵਾਂ ਪ੍ਰੀਫ਼ਿਕਸ ਦੋਵੇਂ ਇੰਟਰਫ਼ੇਸਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ, ਪੀਅਰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਸ਼ਿਫ਼ਟ ਕਰੋ, ਨਵੇਂ ’ਤੇ ਟਰੈਫ਼ਿਕ ਵੇਖੋ ਅਤੇ ਉਦੋਂ ਹੀ ਪੁਰਾਣਾ ਇੰਟਰਫ਼ੇਸ ਤੇ ਉਸ ਦੇ ਰੂਟ ਹਟਾਓ।
ਕਿਸੇ ਵੀ ਵਿਕਲਪ ਵਿੱਚ, ਬਦਲਾਅ ਉਦੋਂ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਚਾਰ ਜਾਂਚਾਂ ਪਾਸ ਹੁੰਦੀਆਂ ਹਨ: ਹੈਂਡਸ਼ੇਕ ਤਾਜ਼ਾ ਹੈ, ਨਵੇਂ ਪ੍ਰੀਫ਼ਿਕਸ ਦੀ ਮੰਜ਼ਿਲ ਲਈ ਰੂਟ ਖੋਜ ਟਨਲ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ, ਕੁਝ ਸੌ ਬਾਈਟ ਦਾ ਪੇਲੋਡ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹੋਸਟ ਜਾਂ ਮੈਨੇਜਰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਉਹੀ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਲਈ wg(8) ਦਸਤਾਵੇਜ਼ ਹਰ ਦਿਸ਼ਾ ਵਿੱਚ AllowedIPs ਦਾ ਅਰਥ ਕੀ ਹੈ ਦਾ ਹਵਾਲਾ ਹੈ, ਅਤੇ ਲੱਛਣ ਮਿਟਾਉਣ ਲਈ ਸੀਮਾ ਚੌੜੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਮੁੜ ਪੜ੍ਹਨਾ ਯੋਗ ਹੈ।
- ਹੈਂਡਸ਼ੇਕ ਤਾਜ਼ਾ ਅਤੇ ਡੇਟਾ ਨਹੀਂ: ਕੁੰਜੀਆਂ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਾਪਤਕਰਤਾ ਕੋਲ AllowedIPs ਵੇਖੋ।
- ਰੂਟ ਖੋਜ ਗ਼ਲਤ ਇੰਟਰਫ਼ੇਸ ਦਿਖਾਉਂਦੀ ਹੈ: ਰੂਟ ਦਾ ਮਾਲਕ ਮੈਨੇਜਰ ਜਾਂ ਕੰਟੇਨਰ ਹੈ, ਤੁਹਾਡੀ ਫ਼ਾਈਲ ਨਹੀਂ।
- ਸੰਖਿਆਤਮਕ ਪਤਾ ਠੀਕ ਅਤੇ ਹੋਸਟਨਾਮ ਟੁੱਟਿਆ: ਪੁਰਾਣਾ ਹਵਾਲਾ, ਰੂਟਿੰਗ ਲੂਪ ਨਹੀਂ।
- ਮੁੜ ਚਾਲੂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਨਵਾਂ ਪ੍ਰੀਫ਼ਿਕਸ ਵਰਤਿਆ ਜਾਣ ’ਤੇ ਹੀ ਬਦਲਾਅ ਪੂਰਾ ਹੁੰਦਾ ਹੈ।