ਹਬ-ਸਪੋਕ ਬਨਾਮ ਪੂਰਾ ਮੈਸ਼: ਤੁਹਾਡੀਆਂ ਸਾਈਟਾਂ ਲਈ ਕਿਹੜੀ VPN ਟੋਪੋਲੋਜੀ ਢੁੱਕਦੀ ਹੈ
ਦੋ ਚੱਲਦੀਆਂ ਸੁਰੰਗਾਂ ਟੋਪੋਲੋਜੀ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਹਬ, ਮੈਸ਼ ਜਾਂ ਕੁਝ ਸਿੱਧੇ ਲਿੰਕਾਂ ਵਾਲਾ ਹਬ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਟ੍ਰਾਂਜ਼ਿਟ, ਨਾਕਾਮੀ ਦਾ ਵਿਵਹਾਰ ਅਤੇ ਬਦਲਾਅ ਦੀ ਲਾਗਤ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਦੋ ਬ੍ਰਾਂਚ ਦਫ਼ਤਰ ਸਾਰਾ ਦਿਨ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਗੱਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰਲੀ ਸੁਰੰਗ ਦੂਜੇ ਖੇਤਰ ਦੇ ਡੇਟਾ ਸੈਂਟਰ ਰਾਹੀਂ ਘੁੰਮਦੀ ਹੈ। ਹਰ ਬੇਨਤੀ ਉਸ ਘੁੰਮ ਦੀ ਕੀਮਤ ਦੋ ਵਾਰ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਫਾਈਲ ਸਿੰਕ ਗਲਤ ਲੱਗਣ ਲੱਗਿਆਂ ਤੱਕ ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ। ਟੋਪੋਲੋਜੀ ਦਾ ਸਵਾਲ ਸੱਚਮੁੱਚ ਇੱਥੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਕਿਹੜਾ ਖਾਕਾ ਵਧੇਰੇ ਟਿਕਾਊ ਦਿਸਦਾ ਹੈ ਨਹੀਂ, ਸਗੋਂ ਤੁਸੀਂ ਕਿਹੜੇ ਟ੍ਰੈਫਿਕ ਪੈਟਰਨ ਲਈ ਪੈਸੇ ਦੇ ਰਹੇ ਹੋ। ਦੋਵੇਂ ਡਿਜ਼ਾਈਨ ਚੱਲਦੇ ਹਨ, ਅਤੇ ਉਹ ਵੱਖਰੇ ਢੰਗਾਂ ਨਾਲ, ਵੱਖਰੀਆਂ ਲਾਗਤਾਂ ਉੱਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਪੀਅਰ ਸੰਬੰਧ ਗਿਣੋ
ਐਨ ਸਾਈਟਾਂ ਹੋਣ ਤਾਂ ਪੂਰੇ ਮੈਸ਼ ਲਈ ਐਨ ਗੁਣਾ ਐਨ ਘਟਾਓ ਇੱਕ, ਦੋ ਨਾਲ ਭਾਗ, ਸੁਰੰਗਾਂ ਚਾਹੀਦੀਆਂ ਹਨ; ਹਬ ਲਈ ਐਨ ਕਾਫ਼ੀ ਹੈ। ਪੰਜ ਸਾਈਟਾਂ ਉੱਤੇ ਉਹ ਦਸ ਬਨਾਮ ਪੰਜ, ਇਹ ਅਜੇ ਸੰਭਾਲਣ ਯੋਗ ਲੱਗਦਾ ਹੈ। ਪੰਦਰਾਂ ਉੱਤੇ ਉਹ 105 ਬਨਾਮ ਪੰਦਰਾਂ, ਅਤੇ ਫ਼ਰਕ ਹੁਣ ਗਣਿਤ ਨਹੀਂ, ਸਟਾਫ਼ ਹੈ।
ਉਨ੍ਹਾਂ ਹਰ ਸੰਬੰਧ ਵਿੱਚ ਅਜਿਹੀ ਹਾਲਤ ਹੁੰਦੀ ਹੈ ਜਿਸਦਾ ਮਾਲਕ ਤੁਸੀਂ ਹੋ। IPsec ਵਿੱਚ ਇਸਦਾ ਮਤਲਬ ਸੁਰੱਖਿਆ ਸੰਗਠਨ, ਪਛਾਣ, ਕੁੰਜੀ ਜਾਂ ਸਰਟੀਫਿਕੇਟ, ਡੈੱਡ-ਪੀਅਰ ਖੋਜ ਅਤੇ ਹਰ ਦੂਰਲੇ ਪ੍ਰੀਫਿਕਸ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਰੂਟ। WireGuard ਵਿੱਚ ਇਸਦਾ ਮਤਲਬ ਹਰ ਪੀਅਰ ਲਈ ਇੱਕ ਜਨਤਕ ਕੁੰਜੀ ਅਤੇ ਇੱਕ AllowedIPs ਬਲਾਕ, ਜੋ ਹਰ ਪੀਅਰ ਲਈ ਸਸਤਾ ਪੈਂਦਾ ਹੈ ਪਰ ਖੋਜ ਬਿਲਕੁਲ ਨਹੀਂ ਦਿੰਦਾ: ਨਵੀਂ ਸਾਈਟ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਹਰ ਪੁਰਾਣੀ ਸਾਈਟ ਉੱਤੇ ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲਾਅ ਹੀ ਹੈ।
ਫ਼ੈਸਲਾ ਖਾਕੇ ਨੇ ਨਹੀਂ, ਟ੍ਰੈਫਿਕ ਮਿਸ਼ਰਣ ਨੇ ਲੈਣਾ ਚਾਹੀਦਾ
ਜੇ ਬ੍ਰਾਂਚ ਟ੍ਰੈਫਿਕ ਜ਼ਿਆਦਾਤਰ ਕੇਂਦਰੀ ERP ਜਾਂ ਫਾਈਲ ਕਲਸਟਰ ਵੱਲ ਬੇਨਤੀਆਂ ਹਨ, ਤਾਂ ਹਬ ਸਮਝੌਤਾ ਨਹੀਂ, ਉਹੀ ਸਹੀ ਆਕਾਰ ਹੈ: ਟ੍ਰੈਫਿਕ ਪਹਿਲਾਂ ਹੀ ਉੱਥੇ ਜਾਣਾ ਚਾਹੁੰਦਾ ਸੀ, ਅਤੇ ਇੱਕ ਨੀਤੀ ਬਿੰਦੂ ਜੋੜੀ-ਵਾਰ ਨਿਯਮਾਂ ਦੇ ਮੈਸ਼ ਨਾਲੋਂ ਜਾਂਚਣਾ ਸੌਖਾ ਹੈ। ਜਦੋਂ ਬ੍ਰਾਂਚਾਂ ਆਪਸ ਵਿੱਚ ਡੇਟਾ ਬਦਲਦੀਆਂ ਹਨ — ਦੋ ਦਫ਼ਤਰਾਂ ਵਿਚਕਾਰ ਨਕਲ, ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਆਵਾਜ਼, ਦਰਜਨ ਇੰਜੀਨੀਅਰ ਸਾਰਾ ਦਿਨ ਖੋਲ੍ਹਦੇ CAD ਸ਼ੇਅਰ — ਤਾਂ ਮੈਸ਼ ਆਪਣੀ ਗੁੰਝਲ ਕਮਾਉਂਦਾ ਹੈ।
ਅਜੀਬ ਕੇਸ ਵਿਚਕਾਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਹੀ ਬਹੁਗਿਣਤੀ ਹਨ। ਸੰਗਠਨ ਚਾਰਟ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਬਹਿਸ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪੋ।
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
ਟੇਬਲ ਨੂੰ ਨਿਯਮ ਨਹੀਂ, ਬਰਾਬਰੀ ਤੋੜਨ ਵਾਲੇ ਵਜੋਂ ਪੜ੍ਹੋ। ਚਾਰ ਵਿੱਚੋਂ ਤਿੰਨ ਕਤਾਰਾਂ ਇੱਕੋ ਪਾਸੇ ਦਿਖਾਉਣ ਤਾਂ ਆਮ ਤੌਰ ਉੱਤੇ ਡਿਜ਼ਾਈਨ ਤੈਅ ਹੋ ਜਾਂਦਾ ਹੈ; ਵੰਡ ਦਾ ਮਤਲਬ ਹਾਈਬ੍ਰਿਡ ਹੈ, ਅਤੇ ਪੱਕੇ ਜ਼ਿਆਦਾਤਰ ਨੈੱਟਵਰਕ ਅੰਤ ਵਿੱਚ ਉਹੀ ਚਲਾਉਂਦੇ ਹਨ।
ਹਬ ਨੂੰ ਫਾਰਵਰਡ ਕਰਨ ਲਈ ਕਹਿਣਾ ਪੈਂਦਾ ਹੈ
ਦੋ ਚੱਲਦੀਆਂ ਸਪੋਕ-ਤੋਂ-ਹਬ ਸੁਰੰਗਾਂ ਸਪੋਕ-ਤੋਂ-ਸਪੋਕ ਪਹੁੰਚ ਨਹੀਂ ਬਣਾਉਂਦੀਆਂ। ਹਬ ਉੱਤੇ IP ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ, ਹਰ ਸਪੋਕ ਨੈੱਟ ਲਈ ਰੂਟ, ਉਸ ਟ੍ਰਾਂਜ਼ਿਟ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਅਤੇ ਵਾਪਸੀ ਰਾਹ ਤੈਅ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ; ਹਰ ਸਪੋਕ ਨੂੰ ਦੂਜੀ ਸਾਈਟ ਦੇ ਪ੍ਰੀਫਿਕਸ ਲਈ ਰੂਟ ਚਾਹੀਦਾ ਹੈ। Linux ਹਬ ਉੱਤੇ ਉਹ net.ipv4.ip_forward=1 ਅਤੇ ਇੱਕ FORWARD ਚੇਨ ਹੁੰਦੀ ਹੈ, ਜੋ ਉਸ ਜੋੜੀ ਨੂੰ ਚੁੱਪਚਾਪ ਨਹੀਂ ਛੱਡਦੀ; ਅਤੇ ਨੀਤੀ-ਅਧਾਰਿਤ IPsec ਵਿੱਚ ਦੋਵੇਂ ਸਿਰਿਆਂ ਉੱਤੇ ਦੂਰਲਾ ਸਪੋਕ ਸਬਨੈੱਟ ਸੂਚੀਬੱਧ ਕਰਨ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਚੋਣਕਾਰ ਹੁੰਦੇ ਹਨ। strongSwan ਦੇ ਫਾਰਵਰਡਿੰਗ ਨੋਟ ਉਦੋਂ ਕਰਨਲ ਅਤੇ ਫਾਇਰਵਾਲ ਪਾਸਾ ਕੱਜਦੇ ਹਨ ਜਦੋਂ ਉਹੀ ਪਰਤ ਤੁਹਾਡੇ ਕੋਲ ਗੁੰਮ ਹੈ। ਸਸਤਾ ਟੈਸਟ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸਪੋਕ ਤੋਂ ਦੂਜੇ ਉੱਤੇ ਸੇਵਾ ਵੱਲ ਟ੍ਰੈਫਿਕ ਭੇਜਦੇ ਹੋਏ ਹਬ ਦੇ ਕਾਊਂਟਰ ਵੇਖੋ; ਕਦੇ ਨਾ ਵਧਣ ਵਾਲਾ ਨਿਯਮ ਮਤਲਬ ਰੂਟ ਨਹੀਂ, ਕ੍ਰਮ ਗਲਤ ਹੈ।
ਕੇਂਦਰੀ ਨੀਤੀ ਹੀ ਲਾਹੇਵੰਦ ਹਿੱਸਾ ਹੈ। ਬ੍ਰਾਂਚਾਂ ਨੂੰ ਇੱਕ-ਦੂਜੇ ਤੱਕ ਪਹੁੰਚੇ ਬਿਨਾਂ ਸਾਂਝੀਆਂ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਉਹ ਪਹੁੰਚ ਮੈਟ੍ਰਿਕਸ ਸਪਸ਼ਟ ਲਿਖ ਕੇ ਰੱਖਣਾ ਲਾਹੇਵੰਦ ਹੈ। ਗੁੰਮ ਰੂਟ ਕਿਸੇ ਪੜ੍ਹਨ ਯੋਗ ਨਿਯਮ ਦਾ ਮਾੜਾ ਬਦਲ ਹਨ।
ਅੱਧਾ ਕੀਤਾ ਸੰਸਕਰਣ ਵੇਖੋ: ਸਪੋਕ A ਹਬ ਰਾਹੀਂ ਸਪੋਕ B ਵੱਲ ਜਾਂਦਾ ਹੈ, ਹਬ ਦੋਵੇਂ ਪਾਸੇ ਰੂਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਬ ਦਾ ਫਾਇਰਵਾਲ A ਤੋਂ ਨਵੇਂ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਪਰ B ਤੋਂ ਨਹੀਂ। ਪਹਿਲੀ ਦਿਸ਼ਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਟੈਸਟ ਹੁੰਦੀ ਹੈ ਅਤੇ ਦੂਜੀ ਅਟਕਦੀ ਹੈ, ਜੋ ਰੂਟਿੰਗ ਨੁਕਸ ਵਰਗੀ ਲੱਗਦੀ ਹੈ, ਪਰ ਨਹੀਂ।
ਪਹਿਲਾਂ ਨਾਕਾਮੀ ਦਾ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਫਿਰ ਆਮ ਰਾਹ
ਇੱਕੋ ਹਬ ਸਾਂਝਾ ਆਸਰਾ ਅਤੇ ਟ੍ਰਾਂਜ਼ਿਟ ਦੀ ਤੰਗੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਹਬ ਡਿਜ਼ਾਈਨ ਆਮ ਤੌਰ ਉੱਤੇ ਇੱਥੇ ਹੀ ਵਿਗੜਦੇ ਹਨ। ਦੋ ਹਬ ਦਾ ਮਤਲਬ ਹਰ ਸਪੋਕ ਕੋਲ ਦੋ ਸੁਰੰਗਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਵਾਪਸੀ ਰਾਹ ਨੂੰ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਰਾਹ ਨਾਲ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ; ਨਾ ਮਿਲੇ ਤਾਂ ਸਟੇਟਫੁਲ ਫਾਇਰਵਾਲ ਜਵਾਬ ਸੁੱਟ ਦਿੰਦਾ ਹੈ ਅਤੇ ਲੱਛਣ ਖੁੱਲ੍ਹ ਕੇ ਫਿਰ ਮਰਨ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਹੁੰਦਾ ਹੈ। ਵੱਡੀਆਂ ਤੈਨਾਤੀਆਂ ਇਸਨੂੰ ਸਥਿਰ ਪ੍ਰੀਫਿਕਸ ਦੀ ਥਾਂ ਸੁਰੰਗਾਂ ਉੱਤੇ ਰੂਟਿੰਗ ਪ੍ਰੋਟੋਕਾਲ ਨਾਲ ਹੱਲ ਕਰਦੀਆਂ ਹਨ, ਜੋ ਵਧੇਰੇ ਮਸ਼ੀਨਰੀ ਹੈ ਪਰ ਅੰਦਾਜ਼ਾ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਵਾਪਸੀ ਰਾਹ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਰਾਹ ਦੇ ਕੋਲ ਲਿਖੋ, ਕਿਉਂਕਿ ਵਾਪਸੀ ਵਾਲਾ ਅੱਧਾ ਹਿੱਸਾ ਹੀ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਟੈਸਟ ਨਹੀਂ ਕਰਦਾ।
ਮੈਸ਼ ਉਹ ਜੋਖਮ ਫੈਲਾਉਂਦਾ ਹੈ: ਇੱਕ ਸਾਈਟ ਦਾ ਲਿੰਕ ਡਿੱਗਣ ਨਾਲ ਬਾਕੀ ਅਲੱਗ ਨਹੀਂ ਹੁੰਦੇ। ਇਹ ਉਹ ਥਾਵਾਂ ਵਧਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਰਾਹ ਦੀ ਚੋਣ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਸੈਸ਼ਨ ਮਦਦ ਬਿਨਾਂ ਫਿਰ ਵੀ ਰਾਹ ਬਦਲਣ ਨੂੰ ਨਹੀਂ ਝੱਲਦੇ।
ਕੋਈ ਵੀ ਡਿਜ਼ਾਈਨ ਫੇਲਓਵਰ ਦੌਰਾਨ TCP ਸੈਸ਼ਨ ਆਪਣੇ ਆਪ ਜ਼ਿੰਦਾ ਨਹੀਂ ਰੱਖਦਾ। ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਦੁਬਾਰਾ ਜੁੜ ਨਹੀਂ ਸਕਦੀ, ਤਾਂ ਟੋਪੋਲੋਜੀ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਨਹੀਂ।
ਬਦਲਾਅ ਦੀ ਲਾਗਤ ਨਾਲ ਚੁਣੋ, ਫਿਰ ਰੂਟ ਜਾਂਚੋ
ਹਬ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਕਿਉਂਕਿ ਗਲਤ ਹੋਣਾ ਉੱਥੇ ਸਸਤਾ ਹੈ, ਅਤੇ ਜਿਨ੍ਹਾਂ ਜੋੜੀਆਂ ਦਾ ਟ੍ਰੈਫਿਕ ਜਾਇਜ਼ ਠਹਿਰਾਉਂਦਾ ਹੈ ਉਨ੍ਹਾਂ ਲਈ ਸਿੱਧੀਆਂ ਸੁਰੰਗਾਂ ਜੋੜੋ। ਉਹ ਹਾਈਬ੍ਰਿਡ ਫ਼ੈਸਲਾ ਨਾ ਲੈਣਾ ਨਹੀਂ ਹੈ; ਜ਼ਿਆਦਾਤਰ ਸੰਗਠਨ ਸਾਲ ਭਰ ਵਿੱਚ ਜਿਸ ਉੱਤੇ ਪਹੁੰਚਦੇ ਹਨ ਉਹੀ ਡਿਜ਼ਾਈਨ ਹੈ। ਅਹਿਮ ਗੱਲ ਇਹ ਹੈ ਕਿ ਹਰ ਸਿੱਧੇ ਲਿੰਕ ਦਾ ਦੱਸਿਆ ਹੋਇਆ ਕਾਰਨ ਅਤੇ ਇੱਕ ਮਾਲਕ ਹੋਵੇ।
ਇੱਕ ਨਹੀਂ, ਦੋਵੇਂ ਖਾਕੇ ਜਾਂਚੋ। ਆਮ ਰਾਹ ਲਈ traceroute ਹਰ ਸਾਈਟ ਤੋਂ ਹਰ ਸੇਵਾ ਪ੍ਰੀਫਿਕਸ ਵੱਲ ਚਲਾਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਹੌਪ ਖਾਕੇ ਨਾਲ ਮਿਲਦੇ ਹਨ। ਨਾਕਾਮੀ ਦੇ ਰਾਹ ਲਈ ਇੱਕ ਸੁਰੰਗ ਬੰਦ ਕਰਕੇ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਸਭ ਕੁਝ ਚਾਲੂ ਹੋਣ ਵੇਲੇ ਹੀ ਚੱਲਣ ਵਾਲਾ ਰਾਹ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ, ਸਿਰਫ਼ ਕਨਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ।
ਦੋਵੇਂ ਖਾਕੇ ਪਹੁੰਚ ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਰੱਖੋ, ਅਤੇ ਸਾਈਟ ਜੋੜਨ ਵੇਲੇ ਉਹ ਦੁਬਾਰਾ ਵੇਖੋ; ਤੁਸੀਂ ਸੰਭਾਲ ਰਹੇ ਲਾਗਤ ਅਗਲੇ ਬਦਲਾਅ ਦੀ ਲਾਗਤ ਹੈ, ਮੌਜੂਦਾ ਤਸਵੀਰ ਦੀ ਸੁੰਦਰਤਾ ਨਹੀਂ।