DNS ਬਦਲਾਵਾਂ ਤੋਂ ਬਾਅਦ ਵੀ WireGuard ਪੁਰਾਣਾ ਐਂਡਪੌਇੰਟ ਵਰਤਦਾ ਹੈ
ਨਾਮ ਨਵੇਂ ਪਤੇ 'ਤੇ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਪਰ ਇੰਟਰਫ਼ੇਸ਼ ਸ਼ੁਰੂ ਹੋਣ ਵੇਲੇ ਮਿਲਿਆ ਪਤਾ ਹੀ ਵਰਤਦਾ ਰਹਿੰਦਾ ਹੈ। ਦੋਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਉਸ ਦੇ ਮੈਨੇਜਰ ਰਾਹੀਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ।
ਸਰਵਰ ਦਾ DNS ਰਿਕਾਰਡ ਹਿੱਲਣ ਤੋਂ ਬਾਅਦ ਟਨਲ ਨੇ ਟ੍ਰੈਫ਼ਿਕ ਲੰਘਾਉਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ, ਪਰ ਉਸੇ ਮਸ਼ੀਨ ਤੋਂ ਨਾਮ ਠੀਕ ਤਰ੍ਹਾਂ ਹੱਲ ਹੁੰਦਾ ਹੈ। ਇਹ ਦੋ ਤੱਥ ਆਪਸ ਵਿੱਚ ਵਿਰੋਧੀ ਨਹੀਂ ਹਨ। WireGuard ਸੰਰਚਨਾ ਇੱਕ ਐਂਡਪੌਇੰਟ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਸੰਦ ਉਸ ਸੰਰਚਨਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵੇਲੇ ਨਾਮ ਹੱਲ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਚੱਲ ਰਹੀ ਇੰਟਰਫ਼ੇਸ਼ ਘੰਟੇ ਪਹਿਲਾਂ ਮਿਲਿਆ ਪਤਾ ਹੀ ਵਰਤਦੀ ਰਹਿ ਸਕਦੀ ਹੈ। ਚਾਬੀਆਂ ਬਦਲਣ ਜਾਂ ਟਨਲ ਦੀ ਸੀਮਾ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਇੰਟਰਫ਼ੇਸ਼ ਕੀ ਵਰਤ ਰਹੀ ਹੈ।
ਨਾਮ ਇੱਕ ਵਾਰ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਲਗਾਤਾਰ ਨਹੀਂ
ਮੂਲ WireGuard ਸੰਰਚਨਾ ਐਂਡਪੌਇੰਟ ਨੂੰ ਪਤਾ ਅਤੇ ਪੋਰਟ ਵਜੋਂ ਲੈਂਦੀ ਹੈ, ਅਤੇ ਇੰਟਰਫ਼ੇਸ਼ ਚੁੱਕਣ ਵਾਲਾ ਸੰਦ ਉਸੇ ਪਲ ਹੋਸਟਨਾਮ ਹੱਲ ਕਰਦਾ ਹੈ। ਮੂਲ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਕੁਝ ਵੀ ਨਿਰਧਾਰਤ ਸਮਾਂ-ਸਾਰਣੀ ਅਨੁਸਾਰ DNS ਨੂੰ ਨਹੀਂ ਪੁੱਛਦਾ, ਅਤੇ ਕਲਾਇੰਟ ਐਪਲੀਕੇਸ਼ਨ ਉਸ ਉੱਤੇ ਆਪਣਾ ਰਿਫ਼੍ਰੈਸ਼ ਵਿਵਹਾਰ ਜੋੜ ਸਕਦੀ ਹੈ। ਨਾਮ ਦੇ ਕੋਲ ਹੱਲ ਹੋਇਆ ਪਤਾ, ਫ਼ੈਮਿਲੀ ਅਤੇ ਪੋਰਟ ਦਰਜ ਕਰਨ ਨਾਲ ਉਹ ਖਾਲੀ ਥਾਂ ਦਿਸਦੀ ਹੈ। ਉਸ ਦਰਜ ਤੋਂ ਬਿਨਾਂ ਇੰਟਰਫ਼ੇਸ਼ ਕਿਤੇ ਹੋਰ ਗੱਲ ਕਰਦਿਆਂ ਸੰਰਚਨਾ ਸਹੀ ਦਿਸਦੀ ਹੈ।
ਇੱਕ ਸੱਚਾ ਸਵੈ-ਚਾਲਿਤ ਅੱਪਡੇਟ ਹੈ, ਅਤੇ ਇਹ ਜਾਣਨਾ ਚੰਗਾ ਹੈ ਕਿਉਂਕਿ ਇਹ DNS ਰਿਫ਼੍ਰੈਸ਼ ਵਰਗਾ ਦਿਸਦਾ ਹੈ ਪਰ ਅਜਿਹਾ ਹੈ ਨਹੀਂ। ਸਹੀ ਤਰ੍ਹਾਂ ਪ੍ਰਮਾਣਿਤ ਟ੍ਰੈਫ਼ਿਕ ਨਵੇਂ ਪਤੇ ਤੋਂ ਆਉਣ 'ਤੇ ਪੀਅਰ ਐਂਡਪੌਇੰਟ ਹਿੱਲ ਸਕਦਾ ਹੈ, ਜੋ ਨਾਮ ਹੱਲ ਕਰਨਾ ਨਹੀਂ, ਰੋਮਿੰਗ ਹੈ। ਇਹ ਪੀਅਰ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪੁਰਾਣੇ ਐਂਡਪੌਇੰਟ ਨੇ ਕਦੇ ਸੰਪਰਕ ਨਾ ਕੀਤਾ ਅਸੰਬੰਧਿਤ ਨਵਾਂ ਸਰਵਰ ਇਹ ਲੱਭ ਨਹੀਂ ਸਕਦਾ।
ਰਿਕਾਰਡ ਦੀ ਤੁਲਨਾ ਵਰਤੇ ਜਾ ਰਹੇ ਪਤੇ ਨਾਲ ਕਰੋ
ਕਲਾਇੰਟ ਵਰਤਦਾ ਰਿਜ਼ੌਲਵਰ ਕਿਹੜਾ ਹੈ ਉਸ ਰਾਹੀਂ ਦਰਜ ਨਾਮ ਪੁੱਛੋ, ਫਿਰ ਇੰਟਰਫ਼ੇਸ਼ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਸ ਕੋਲ ਕਿਹੜਾ ਐਂਡਪੌਇੰਟ ਹੈ। ਇਹ ਦੋ ਜਵਾਬ ਹੀ ਇਸ ਸਫ਼ੇ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਤੈਅ ਕਰਨ ਵਾਲੀ ਤੁਲਨਾ ਹਨ:
dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes
ਇਹ ਲਾਈਨਾਂ ਜੋ show ਉਪ-ਕਮਾਂਡਾਂ ਵਰਤਦੀਆਂ ਹਨ, wg(8) ਪੁਸਤਿਕਾ ਵਿੱਚ ਦਰਜ ਹਨ। ਪਤੇ ਦੇ ਨਾਲ ਪਤੇ ਦੀ ਫ਼ੈਮਿਲੀ ਵੀ ਤੁਲਨਾ ਕਰੋ, ਸਿਰਫ਼ ਪਤਾ ਨਹੀਂ, ਕਿਉਂਕਿ IPv6 ਐਂਟਰੀ ਪ੍ਰਾਪਤ ਰਿਕਾਰਡ IPv4 ਪਤਾ ਬਦਲੇ ਰਿਕਾਰਡ ਤੋਂ ਵੱਖਰੀ ਤੁਲਨਾ ਹੈ। ਜੇ ਐਂਡਪੌਇੰਟ ਰਿਕਾਰਡ ਤੋਂ ਵੱਖਰਾ ਹੈ, ਇੰਟਰਫ਼ੇਸ਼ ਪੁਰਾਣੀ ਜਾਣਕਾਰੀ 'ਤੇ ਚੱਲ ਰਹੀ ਹੈ ਅਤੇ ਨਾਮ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ। ਜੇ ਦੋਵੇਂ ਮਿਲਦੇ ਹਨ ਅਤੇ ਟਨਲ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਪ੍ਰੋਫ਼ਾਈਲ ਦੀ ਥਾਂ ਲਿਸਨਰ ਅਤੇ ਨਿਯਮਾਂ ਵੱਲ ਜਾਓ।
ਹੈਂਡਸ਼ੇਕ ਦਾ ਟਾਈਮਸਟੈਂਪ ਉਸ ਬਲਾਕ ਵਿੱਚ ਹੈ ਕਿਉਂਕਿ ਇਕੱਲਾ ਐਂਡਪੌਇੰਟ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਪੀਅਰ ਤੱਕ ਪਹੁੰਚ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਹੀ ਐਂਡਪੌਇੰਟ ਦੇ ਕੋਲ ਪੁਰਾਣਾ ਟਾਈਮਸਟੈਂਪ ਰਾਹ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਹੱਲ ਕਰਨ ਦੀ ਨਹੀਂ, ਅਤੇ ਇਹ ਫ਼ਰਕ ਬਦਲਦਾ ਹੈ ਕਿ ਅੱਗੇ ਤੁਸੀਂ ਕੀ ਛੂਹੋਗੇ।
ਇੰਟਰਫ਼ੇਸ਼ ਦੇ ਮੈਨੇਜਰ ਰਾਹੀਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ
ਐਂਡਪੌਇੰਟ ਪੁਰਾਣਾ ਸਾਬਤ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਇੰਟਰਫ਼ੇਸ਼ ਦੀ ਮਾਲਕੀ ਵਾਲੀ ਵਿਧੀ ਰਾਹੀਂ ਇਸਨੂੰ ਰਿਫ਼੍ਰੈਸ਼ ਕਰੋ ਜੀਵੰਤ ਸੰਰਚਨਾ ਨੂੰ ਸੋਧਣ ਦੀ ਥਾਂ। wg-quick ਵੱਲੋਂ ਸ਼ੁਰੂ ਕੀਤੀ ਇੰਟਰਫ਼ੇਸ਼ ਲਈ ਇਹ ਹੇਠਾਂ ਅਤੇ ਉੱਪਰ ਹੈ, systemd ਯੂਨਿਟ ਲਈ ਇਹ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੈ, ਅਤੇ ਮੈਨੇਜਰ ਦੀ ਮਲਕੀਅਤ ਵਾਲੀ ਇੰਟਰਫ਼ੇਸ਼ ਲਈ ਇਹ ਉਸੇ ਮੈਨੇਜਰ ਵਿੱਚ ਕੀਤਾ ਬਦਲਾਅ ਹੈ, ਕਿਉਂਕਿ ਰਨਟਾਈਮ ਸੋਧ ਅਗਲੀ ਵਾਰ ਲਾਗੂ ਹੋਣ 'ਤੇ ਉੱਤੇ ਲਿਖੀ ਜਾਂਦੀ ਹੈ:
wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0
ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਬਦਲਿਆ ਲਿਸਨਰ ਅਤੇ ਉਸ ਦੀ ਪਛਾਣ ਹੀ ਤੁਹਾਡੀ ਮਨਸ਼ਾ ਵਾਲੀ ਸੇਵਾ ਹੈ। DNS ਦਾ ਹਿੱਲਣਾ ਪਛਾਣ ਦਾ ਬਦਲਾਅ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਜਾਂਚੀ ਨਾ ਗਈ ਚਾਬੀ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦਾ ਮੌਕਾ ਇਹ ਕਦੇ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਜੇ ਇੰਟਰਫ਼ੇਸ਼ ਹੁਣ ਨਵਾਂ ਪਤਾ ਦੱਸਦੀ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਖ਼ਰਾਬੀ ਨਵੇਂ ਨੈੱਟਵਰਕ ਰਾਹ ਜਾਂ ਲਿਸਨਰ ਵੱਲ ਚਲੀ ਗਈ ਹੈ, ਜੋ ਤਰੱਕੀ ਹੈ, ਉਹੀ ਖ਼ਰਾਬੀ ਦੁਬਾਰਾ ਨਹੀਂ।
ਪਹਿਲਾਂ ਹੈਂਡਸ਼ੇਕ, ਫਿਰ ਡੇਟਾ ਰਾਹ
ਚੈੱਕਲਿਸਟ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਨਤੀਜੇ ਵੱਖ ਕਰੋ। ਫੇਲ੍ਹ ਹੁੰਦੀ ਐਪਲੀਕੇਸ਼ਨ ਹੇਠ ਸਫਲ ਹੁੰਦਾ ਹੈਂਡਸ਼ੇਕ ਡੇਟਾ ਰਾਹ ਦੀ ਸਮੱਸਿਆ ਹੈ: ਰੂਟ, ਮਨਜ਼ੂਰ ਪ੍ਰੀਫ਼ਿਕਸ ਜਾਂ ਟਨਲ ਦੇ ਅੰਦਰਲਾ DNS। ਕਦੇ ਨਾ ਹੋਣ ਵਾਲਾ ਹੈਂਡਸ਼ੇਕ ਐਂਡਪੌਇੰਟ 'ਤੇ ਪਹੁੰਚ ਜਾਂ ਪਛਾਣ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਦੋਵੇਂ ਮਿਲਾ ਦੇਣ ਨਾਲ ਅਜਿਹੀ ਰਿਪੋਰਟ ਬਣਦੀ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾ ਸਕਦਾ, ਅਤੇ ਤਿੰਨ ਅਸੰਬੰਧਿਤ ਸੋਧਾਂ ਵਾਲਾ ਬਦਲਾਅ ਲੌਗ ਬਣਦਾ ਹੈ।
ਨਾਮ, ਹੱਲ ਹੋਇਆ ਪਤਾ, ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਐਂਡਪੌਇੰਟ ਅਤੇ ਇਹ ਕਿ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਹੋਇਆ ਜਾਂ ਨਹੀਂ, ਦਰਜ ਕਰੋ। ਇਹ ਚਾਰ ਤੱਥ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਜੋ ਇਹ ਖ਼ਰਾਬੀ ਵਾਰ-ਵਾਰ ਪੁੱਛਦੀ ਹੈ, ਅਤੇ ਅਗਲੀ ਘਟਨਾ ਨੂੰ ਦੋ ਮਿੰਟ ਦੀ ਜਾਂਚ ਬਣਾ ਦਿੰਦੇ ਹਨ। ਨਾਮ ਦੀ ਸੰਭਾਲ ਅਤੇ ਕਲਾਇੰਟ ਅਪਣਾਉਣਾ ਵੱਖਰੇ ਕੰਮ ਰਹਿੰਦੇ ਹਨ: ਰਿਕਾਰਡ ਸੁਧਾਰਨ ਨਾਲ ਅਪਣਾਉਣਾ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਇੰਟਰਫ਼ੇਸ਼ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਅਜੇ ਵੀ ਗ਼ਲਤ ਰਿਕਾਰਡ ਠੀਕ ਨਹੀਂ ਹੁੰਦਾ।