ਦੋ WireGuard peer ਇੱਕ ਰੇਂਜ ਸਾਂਝੀ ਕਰਦੇ ਹਨ: ਪੈਕੇਟ ਕਿਸਨੂੰ ਮਿਲਦਾ ਹੈ

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

WireGuard ਦੇ ਅੰਦਰ ਸਭ ਤੋਂ ਲੰਮਾ ਪ੍ਰੀਫਿਕਸ ਜਿੱਤਦਾ ਹੈ

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

road-warrior ਸੈਟਅਪ ਇਸਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਵਰਤਦੇ ਹਨ। ਇੱਕ peer ਸਾਈਟ ਲਈ ਚੌੜੀ ਰੇਂਜ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਵੱਖਰੇ ਹੋਸਟ ਦੂਜੇ peerਾਂ ਦੀਆਂ /32 ਐਂਟਰੀਆਂ ਨਾਲ ਵੱਖ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇਹ ਪੈਟਰਨ ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਵੱਖ ਕੀਤੇ ਹਿੱਸੇ ਵਧੇਰੇ ਵਿਸ਼ੇਸ਼ ਹਨ, ਕ੍ਰਮ ਕਾਰਨ ਨਹੀਂ।

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

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਪਹਿਲਾਂ ਇੰਟਰਫੇਸ ਚੁਣਦਾ ਹੈ

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

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

ਆਉਣ ਵਾਲੇ ਪੈਕੇਟ ਸਰੋਤ ਅਨੁਸਾਰ ਜਾਂਚੇ ਜਾਂਦੇ ਹਨ

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

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

ਤੰਗ ਸਰੋਤ ਮਾਲਕੀ ਇਸਨੂੰ ਲਾਭ ਵਿੱਚ ਬਦਲਦੀ ਹੈ। ਹਰ peer ਨੂੰ ਆਪਣੇ ਪਤੇ ਲਈ /32 ਦਿਓ ਅਤੇ ਹੇਠਾਂ ਵਾਲੀ ਫਾਇਰਵਾਲ ਕੋਲ ਮਿਲਾਨ ਲਈ ਭਰੋਸੇਯੋਗ ਸਰੋਤ ਹੋਵੇਗਾ, ਕਿਸੇ ਵੀ ਮੈਂਬਰ ਦੁਆਰਾ ਦਾਅਵਾ ਕੀਤੀ ਜਾ ਸਕਣ ਵਾਲੀ ਸਮੂਹ-ਵਿਆਪੀ ਰੇਂਜ ਦੀ ਬਜਾਏ।

ਨਕਲੀ ਰੇਂਜਾਂ failover ਨਹੀਂ ਹਨ

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

ਅਸੰਬੰਧਿਤ ਨਾਕਾਮੀ ਠੀਕ ਕਰਨ ਲਈ ਰੇਂਜ ਚੌੜੀ ਕਰਨਾ ਦੂਜੀ ਆਮ ਗਲਤੀ ਹੈ। ਇਹ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕੰਮ ਕਰ ਰਹੇ peer ਤੋਂ ਦੂਰ ਲੈ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਪੁਰਾਣਾ ਸਮਝੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਨਵਾਂ ਲੱਛਣ ਆ ਜਾਂਦਾ ਹੈ।

ਸੰਪਾਦਨ ਤੋਂ ਪਹਿਲਾਂ ਚੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

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

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