WireGuard 5G ਸ਼ਾਖਾ: ਸ਼ਾਖਾ ਹੀ ਹੱਬ ਨੂੰ ਡਾਇਲ ਕਰੇ

ਸ਼ਾਖਾ ਨੂੰ ਹੱਬ ਵੱਲ ਮੋੜਨਾ ਇਸ ਡਿਜ਼ਾਈਨ ਦਾ ਸੌਖਾ ਅੱਧਾ ਹੈ, ਜਦੋਂ ਸ਼ਾਖਾ ਬਦਲਦੇ ਮੋਬਾਈਲ ਪਤੇ ਪਿੱਛੇ ਬੈਠੀ ਹੋਵੇ ਅਤੇ ਹੱਬ ਕੋਲ ਸਥਿਰ ਨਾਮ ਹੋਵੇ। ਤਦ ਹੱਬ ਸ਼ਾਖਾ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਟ੍ਰੈਫਿਕ ਤੋਂ ਸਿੱਖਦਾ ਹੈ, ਉਸ ਰਿਕਾਰਡ ਤੋਂ ਨਹੀਂ ਜਿਸਨੂੰ ਤੁਹਾਨੂੰ ਅੱਪ-ਟੂ-ਡੇਟ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ। ਸਮਝੌਤਾ ਸੌਖਾ ਹੈ: ਸ਼ਾਖਾ ਹਮੇਸ਼ਾ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ।

ਇਸਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਸੰਰਚਿਤ ਕਰੋ ਅਤੇ ਫਿਰ ਉਸ ਹਿੱਸੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਜਿਸਨੂੰ ਲੋਕ ਕੰਮ ਕਰਦਾ ਮੰਨਦੇ ਹਨ। ਦੋਵੇਂ ਕਦਮਾਂ ਵਿੱਚ ਮਿੰਟ ਲੱਗਦੇ ਹਨ, ਅਤੇ ਇਹ ਡਿਜ਼ਾਈਨ ਆਮ ਤੌਰ ’ਤੇ ਦੂਜੇ ਵਿੱਚ ਫੇਲ ਹੁੰਦੇ ਹਨ।

ਕਿਹੜਾ ਪਾਸਾ ਸਥਿਰ ਐਂਡਪੌਇੰਟ ਰੱਖਦਾ ਹੈ

ਸ਼ਾਖਾ ਦੀ ਸੰਰਚਨਾ ਹੱਬ ਦਾ ਐਂਡਪੌਇੰਟ ਅਤੇ ਉਸਦੀ ਜਨਤਕ ਕੁੰਜੀ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ। ਹੱਬ ਦੀ ਸੰਰਚਨਾ ਸ਼ਾਖਾ ਦੀ ਜਨਤਕ ਕੁੰਜੀ ਅਤੇ ਉਸਦੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਅੰਦਰੂਨੀ ਪ੍ਰੀਫਿਕਸ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਕੋਈ ਐਂਡਪੌਇੰਟ ਨਾ ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਪਛਾਣ ਕੁੰਜੀ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਆਖਰੀ ਪੈਕੇਟ ਦੇ ਸਰੋਤ ਪਤੇ ਤੋਂ ਨਹੀਂ। ਇਹ ਅਸਮਾਨਤਾ ਹੀ ਪੂਰਾ ਤੰਤਰ ਹੈ, ਅਤੇ ਇਹ ਹੱਬ ਵੱਲੋਂ ਖੋਜ ਸਮੱਸਿਆਵਾਂ ਦੀ ਪੂਰੀ ਸ਼੍ਰੇਣੀ ਹਟਾ ਦਿੰਦੀ ਹੈ।

ਜਦੋਂ ਸ਼ਾਖਾ ਪ੍ਰਮਾਣਿਤ ਪੈਕੇਟ ਭੇਜਦੀ ਹੈ, ਹੱਬ ਉਹ ਸਰੋਤ ਦਰਜ ਕਰਦਾ ਹੈ ਜਿੱਥੋਂ ਉਹ ਆਇਆ ਅਤੇ ਜਵਾਬਾਂ ਲਈ ਉਹੀ ਮੈਪਿੰਗ ਵਰਤਦਾ ਹੈ। ਫਿਰ ਮੋਬਾਈਲ ਲਿੰਕ ਦੀ ਮੁੜ-ਨੰਬਰਿੰਗ ਅਗਲੇ ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਬਿਨਾਂ ਕੁਝ ਵੀ ਖਰਚ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਹੁਣ ਜਿਸ ਕੰਪੋਨੈਂਟ ਦੀ ਲੋੜ ਨਹੀਂ ਉਹ ਅਜਿਹਾ ਹੈ ਜੋ ਬਦਲਾਅ ਦੌਰਾਨ ਫੇਲ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਇਹ ਗੁਣ ਨਿਯੋਜਿਤ ਬਦਲਾਅ ਦੌਰਾਨ ਪਰਖਣ ਯੋਗ ਹੈ, ਘਟਨਾ ਦੌਰਾਨ ਨਹੀਂ। ਇਹ ਕਰੋ ਜਦੋਂ ਕੋਈ ਦੋਵੇਂ ਸਿਰੇ ਇਕੱਠੇ ਦੇਖ ਸਕੇ।

ਸ਼ਾਖਾ ਨੂੰ ਮੁੜ-ਨੰਬਰਿੰਗ ਸਹਿਣ ਵਾਲੀ ਸੰਰਚਨਾ ਦਿਓ

ਐਂਡਪੌਇੰਟ ਅਤੇ keepalive ਸ਼ਾਖਾ ’ਤੇ ਰੱਖੋ, ਅਤੇ ਹੱਬ ਦੀ ਪੀਅਰ ਐਂਟਰੀ ਨੂੰ ਸਖ਼ਤ ਕੋਡ ਕੀਤੇ ਪਤੇ ਤੋਂ ਮੁਕਤ ਰੱਖੋ। keepalive ਅਨੁਵਾਦਿਤ ਮੈਪਿੰਗ ਨੂੰ ਇੰਨਾ ਚਿਰ ਖੁੱਲ੍ਹਾ ਰੱਖਦਾ ਹੈ ਕਿ ਹੱਬ ਨਿਸ਼ਕਿਰਿਆ ਅਵਧੀ ਤੋਂ ਬਾਅਦ ਬਿਨਾਂ ਮੰਗਿਆ ਟ੍ਰੈਫਿਕ ਭੇਜ ਸਕੇ।

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

ਪੱਚੀ ਸਕਿੰਟ NAT ਮੈਪਿੰਗ ਨੂੰ ਜੀਵਿਤ ਰੱਖਣ ਦੀ ਅਕਸਰ ਦਿੱਤੀ ਜਾਂਦੀ ਉਦਾਹਰਨ ਹੈ, ਹਰ ਪੀਅਰ ਲਈ ਲਾਜ਼ਮੀ ਨਹੀਂ। ਇਸਨੂੰ ਉਸ ਮੈਪਿੰਗ ਟਾਈਮਆਉਟ ਦੇ ਆਧਾਰ ’ਤੇ ਸੈੱਟ ਕਰੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਦੇਖਦੇ ਹੋ, ਅਤੇ ਯਾਦ ਰੱਖੋ ਕਿ ਇੰਟਰਫੇਸ ਚਾਲੂ ਰਹਿਣ ਤੱਕ ਇਹ ਡੇਟਾ-ਸੀਮਤ ਲਿੰਕ ’ਤੇ ਟ੍ਰੈਫਿਕ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਹੱਬ ’ਤੇ, ਸ਼ਾਖਾ ਪੀਅਰ ਦੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਉਹ ਸਭ ਢੱਕਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸ਼ਾਖਾ ਭੇਜੇਗੀ। ਗੁੰਮ ਪ੍ਰੀਫਿਕਸ ਦੂਰ ਸਿਰੇ ’ਤੇ ਰੂਟਿੰਗ ਫੇਲ ਹੋਣ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਪਾਸੇ ਚੇਤਾਵਨੀ ਨਹੀਂ ਦਿੰਦਾ, ਇਸ ਲਈ ਪਹਿਲੇ ਅਸਲ ਪੈਕੇਟ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੀ ਸਮੀਖਿਆ ਕਰਨੀ ਯੋਗ ਹੈ। ਪਹਿਲੇ ਕਨੈਕਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਹੱਬ ਦੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪ੍ਰੀਫਿਕਸ ਦੀ ਸ਼ਾਖਾ ਦੇ ਇੰਟਰਫੇਸ ਪਤਿਆਂ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

ਮੈਪਿੰਗ ਅਤੇ ਫੇਲਓਵਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਹੱਬ ਸ਼ਾਖਾ ਦਾ ਮੌਜੂਦਾ ਐਂਡਪੌਇੰਟ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਰਾਹੀਂ ਸ਼ਾਖਾ ਦੇ ਅੰਦਰੂਨੀ ਪਤੇ ਪਹੁੰਚਯੋਗ ਹਨ। ਇਹੀ ਅਧਾਰ-ਰੇਖਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਦੇ ਮੋਬਾਈਲ ਲਿੰਕ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਦਰਜ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਦੋ ਲਾਈਨਾਂ ਦਾ ਆਉਟਪੁੱਟ ਕਾਫੀ ਹੈ। ਸਮਾਂ-ਮੋਹਰ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਟਿਕਟ ਵਿੱਚ ਰੱਖੋ।

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

ਫਿਰ ਉਸ ਫੇਲ ਦੀ ਪਰਖ ਕਰੋ ਜਿਸ ਲਈ ਇਹ ਡਿਜ਼ਾਈਨ ਹੈ। ਪ੍ਰਾਇਮਰੀ WAN ਖਿੱਚੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਹੱਬ ਵੱਲ ਸ਼ਾਖਾ ਦਾ ਅਧਾਰ ਰਸਤਾ ਹੁਣ ਮੋਬਾਈਲ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਨਿਕਲਦਾ ਹੈ। ਟਨਲ ਟੁੱਟਿਆ ਭੌਤਿਕ ਰਸਤਾ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇਸ ਲਈ ਮਰੇ ਅਪਲਿੰਕ ਵੱਲ ਅਜੇ ਵੀ ਸੰਕੇਤ ਕਰਦਾ ਬਾਹਰੀ ਰਸਤਾ ਹੈਂਡਸ਼ੇਕ ਟਾਈਮਆਉਟ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੋ ਬਿਲਕੁਲ ਹੱਬ ਦੀ ਸਮੱਸਿਆ ਵਰਗਾ ਲੱਗਦਾ ਹੈ।

ਜੇ ਬਾਹਰੀ ਰਸਤਾ ਸਪਸ਼ਟ ਤੌਰ ’ਤੇ ਬੱਝਿਆ ਜਾਂ ਨੀਤੀ-ਰੂਟ ਕੀਤਾ ਹੋਇਆ ਹੈ, ਫੇਲਓਵਰ ਵਿੱਚ ਇਸਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਪਵੇਗਾ। ਸਹੀ ਢੰਗ ਨਾਲ ਪੜ੍ਹੇ ਜਾਣ ਵਾਲੇ ਡਿਜ਼ਾਈਨ ਅਤੇ ਰੁਕਾਵਟ ਸਹਿਣ ਵਾਲੇ ਡਿਜ਼ਾਈਨ ਵਿਚਕਾਰ ਇਹੀ ਖੱਪਾ ਆਮ ਤੌਰ ’ਤੇ ਇੱਕੋ-ਇੱਕ ਗੁੰਮ ਚੀਜ਼ ਹੁੰਦਾ ਹੈ।

ਇਹ ਡਿਜ਼ਾਈਨ ਕੀ ਹੱਲ ਨਹੀਂ ਕਰਦਾ

ਇੱਥੇ ਕੁਝ ਵੀ ਸ਼ਾਖਾ ਵੱਲ ਆਉਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦਾ। ਜੇ ਹੈੱਡਕੁਆਰਟਰ ਵਿੱਚ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਮੋਬਾਈਲ ਸਾਈਟ ਡਾਇਲ ਕਰਨੀ ਪਵੇ, ਤਾਂ ਉਸ ਲੋੜ ਲਈ ਟਨਲ ਦੀ ਦਿਸ਼ਾ ਗਲਤ ਹੈ, ਅਤੇ ਗਤੀਸ਼ੀਲ DNS ਸਿਰਫ ਨਾਮ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ। ਪ੍ਰਦਾਤਾ ਦਾ ਅਨੁਵਾਦ, ਆਉਣ ਵਾਲੀ ਨੀਤੀ ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਐਂਡਪੌਇੰਟ ਰਿਫ੍ਰੈਸ਼ ਸਭ ਰਸਤੇ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਬਦਲਿਆ ਰਿਕਾਰਡ ਓਪਰੇਟਰ-ਗ੍ਰੇਡ NAT ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਦਾ।

ਸ਼ਾਖਾ ਦੇ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਹਰ ਦੂਜੀ ਸਾਈਟ ਤੋਂ ਵੱਖ ਰੱਖੋ, ਅਤੇ ਸੀਮਿਤ ਕਰੋ ਕਿ ਇਸਦਾ ਗੇਟਵੇ ਕੀ ਅੱਗੇ ਭੇਜੇਗਾ। ਸਥਿਰ ਹੱਬ ਐਂਡਪੌਇੰਟ ਖੋਜ ਨੂੰ ਸੌਖਾ ਕਰਦਾ ਹੈ ਅਤੇ ਰੂਟਿੰਗ ਡਿਜ਼ਾਈਨ, ਪਤਾ ਯੋਜਨਾ ਜਾਂ ਇਸ ਸਵਾਲ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕਿਹੜੇ ਐਪਲੀਕੇਸ਼ਨ ਰਸਤੇ ਫੇਲਓਵਰ ਸਹਿੰਦੇ ਹਨ।

ਰਨਬੁੱਕ ਵਿੱਚ ਚਾਰ ਗੱਲਾਂ ਲਿਖੋ: ਕੌਣ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਕਿਹੜੇ ਪ੍ਰੀਫਿਕਸ ਮਨਜ਼ੂਰ ਹਨ, keepalive ਕਿੰਨਾ ਲੰਬਾ ਹੈ, ਅਤੇ ਪ੍ਰਾਇਮਰੀ ਲਿੰਕ ਡਿੱਗਣ ’ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ। ਭਵਿੱਖ ਦੇ ਆਪਰੇਟਰ ਨੂੰ ਰਾਤ ਤਿੰਨ ਵਜੇ ਸੱਚਮੁੱਚ ਜਿਨ੍ਹਾਂ ਲਾਈਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਉਹ ਇਹੋ ਹਨ।