NetBird 'ਤੇ ਦੋ LAN: ਕਿਹੜੇ ਪੀਅਰ ਰੂਟ ਕਰਦੇ ਹਨ ਅਤੇ ਕੌਣ ਬੋਲ ਸਕਦਾ ਹੈ
ਰਜਿਸਟਰੇਸ਼ਨ ਕਿਸੇ LAN ਨੂੰ ਰੂਟ ਨਹੀਂ ਕਰਦੀ। ਹਰ ਸਾਈਟ ਲਈ ਇੱਕ ਰੂਟਿੰਗ ਪੀਅਰ ਚੁਣੋ, ਮਾਸਕਰੇਡਿੰਗ ਚਾਲੂ ਰੱਖੋ, ਨੀਤੀ ਸੀਮਿਤ ਕਰੋ, ਫਿਰ ਹਰ LAN ਗੇਟਵੇ ਨੂੰ ਅਗਲਾ ਹੌਪ ਸਿਖਾਓ।
ਪੱਛਮੀ LAN ਉੱਤੇ ਇੱਕ ਵਰਕਸਟੇਸ਼ਨ ਬ੍ਰਾਊਜ਼ਰ ਖੋਲ੍ਹਦਾ ਹੈ, ਪੂਰਬੀ LAN ਉੱਤੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਪਤਾ ਲਿਖਦਾ ਹੈ ਅਤੇ ਸਮਾਂ ਖਤਮ ਹੋਣ ਤੱਕ ਉਡੀਕ ਕਰਦਾ ਹੈ। NetBird ਦੀ ਹਰ ਸਕ੍ਰੀਨ ਕਹਿੰਦੀ ਹੈ ਕਿ ਪੀਅਰ ਜੁੜੇ ਹੋਏ ਹਨ, ਜੋ ਸੱਚ ਹੈ ਪਰ ਮੁੱਦਾ ਨਹੀਂ: ਇੱਕ ਓਵਰਲੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਹੋਣਾ ਦੋ ਸਥਾਨਕ ਸਬਨੈੱਟਾਂ ਨੂੰ ਇੱਕ ਨੈੱਟਵਰਕ ਵਿੱਚ ਰੱਖਣਾ ਨਹੀਂ ਹੈ। ਹੇਠਾਂ ਦਾ ਸਫਰ ਉਸ ਵਰਕਸਟੇਸ਼ਨ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਸ ਬੇਨਤੀ ਉੱਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ ਜਿਸਨੂੰ ਡਿਜ਼ਾਈਨ ਜਾਣਬੁੱਝ ਕੇ ਰੱਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰ ਰੁਕਣਾ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਸੀਂ ਡਿਵਾਈਸ ਤੋਂ ਪੜ੍ਹਦੇ ਹੋ, ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਾਉਂਦੇ। ਉਮੀਦ ਰੱਖੋ ਕਿ ਗੁੰਮ ਹਿੱਸਾ ਰੂਟ ਜਾਂ ਨੀਤੀ ਹੈ, ਓਵਰਲੇ ਨਹੀਂ।
ਪਹਿਲਾਂ ਵਰਕਸਟੇਸ਼ਨ ਤੋਂ ਅਸਫਲਤਾ ਪੜ੍ਹੋ
ਪ੍ਰਬੰਧਨ ਕੰਸੋਲ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਵਰਕਸਟੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਭੇਜਦਾ ਹੈ। ਪੈਕਟ ਸਾਈਟ ਗੇਟਵੇ, ਸਥਾਨਕ ਇੰਟਰਫੇਸ ਜਾਂ ਕਿਤੇ ਨਹੀਂ ਜਾਂਦਾ, ਇਹ ਉਸਦੀ ਆਪਣੀ ਰੂਟਿੰਗ ਸਾਰਣੀ ਤੈਅ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਫੈਸਲਾ ਕਿਸੇ ਓਵਰਲੇ ਸੰਦ ਤੋਂ ਬਿਨਾਂ ਦਿਸਦਾ ਹੈ। ਦੂਰ ਦੇ ਪ੍ਰੀਫਿਕਸ ਲਈ ਰੂਟ ਨਾ ਹੋਣ ਵਾਲੀ ਮਸ਼ੀਨ ਪੀਅਰ ਸੂਚੀ ਕਿੰਨੀ ਵੀ ਸਿਹਤਮੰਦ ਦਿਸੇ, ਅਸਫਲ ਹੋਵੇਗੀ। ਓਵਰਲੇ ਰੇਂਜ ਅਤੇ ਸਾਈਟ ਦਾ ਆਪਣਾ ਪ੍ਰੀਫਿਕਸ ਵੱਖਰੀਆਂ ਪਤਾ-ਥਾਵਾਂ ਹਨ, ਅਤੇ ਰਜਿਸਟਰੇਸ਼ਨ ਨੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ ਇੱਕ ਸੰਰਚਿਤ ਕੀਤਾ।
ਫਿਰ ਨਾਮ ਹੱਲ ਅਤੇ ਪਹੁੰਚ ਨੂੰ ਵੱਖ ਕਰੋ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਦੋਵਾਂ ਨੂੰ ਇੱਕੋ ਸਮਾਂ ਸਮਾਪਤੀ ਵਜੋਂ ਦੱਸਦਾ ਹੈ। NetBird ਕਲਾਇੰਟ ਚੱਲਣ ਵਾਲੀ ਮਸ਼ੀਨ ਤੋਂ ਪਤੇ ਨਾਲ ਬੇਨਤੀ ਦੁਹਰਾਓ, ਫਿਰ ਨਾ ਚੱਲਣ ਵਾਲੇ ਆਮ ਵਰਕਸਟੇਸ਼ਨ ਤੋਂ। ਜੇ ਰਜਿਸਟਰਡ ਮਸ਼ੀਨ ਸਫਲ ਅਤੇ ਆਮ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਅੰਤਰ ਸਥਾਨਕ ਰੂਟਿੰਗ ਵਿੱਚ ਹੈ; ਜੇ ਦੋਵੇਂ ਅਸਫਲ ਹੋਣ, ਤਾਂ ਰੂਟ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੜ੍ਹਨਾ ਜਾਰੀ ਰੱਖੋ।
ਹਰ ਸਾਈਟ ਲਈ ਇੱਕ ਰੂਟਿੰਗ ਪੀਅਰ ਚੁਣੋ
ਰੂਟਿੰਗ ਪੀਅਰ ਉਹ ਹੋਸਟ ਹੈ ਜੋ ਓਵਰਲੇ ਉੱਤੇ ਆਪਣੇ LAN ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਕਿਸੇ ਦੇ ਡੈਸਕ ਵਰਕਸਟੇਸ਼ਨ ਦੀ ਥਾਂ ਸਬਨੈੱਟ ਤੱਕ ਸਥਿਰ ਪਹੁੰਚ ਵਾਲੀ Linux ਮਸ਼ੀਨ ਚੁਣੋ। ਇਸਨੂੰ ਆਮ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਰਜਿਸਟਰ ਕਰੋ ਅਤੇ ਭੂਮਿਕਾ ਦੇ ਨਾਮ ਵਾਲੇ ਸਮੂਹ ਵਿੱਚ ਰੱਖੋ, ਕਿਉਂਕਿ ਨੈੱਟਵਰਕ ਸਰੋਤ ਅਤੇ ਨੀਤੀ ਦੋਵੇਂ ਉਸ ਸਮੂਹ ਦਾ ਹਵਾਲਾ ਦੇਣਗੇ। ਹਰ ਸਾਈਟ ਲਈ ਇੱਕ ਨੁਮਾਇੰਦਾ ਪੜ੍ਹਨ ਯੋਗ ਰਹਿੰਦਾ ਹੈ; ਉਹੀ ਪ੍ਰੀਫਿਕਸ ਘੋਸ਼ਿਤ ਕਰਨ ਵਾਲੇ ਸਵੈਸੇਵੀਆਂ ਦੀ ਭੀੜ ਹਰ ਅਗਲੇ ਸਵਾਲ ਨੂੰ ਡੀਬੱਗ ਸੈਸ਼ਨ ਬਣਾ ਦਿੰਦੀ ਹੈ। ਸਥਾਨਕ ਹਿੱਸੇ ਵਿੱਚ ਪੀਅਰ ਦਾ ਪਤਾ ਉਸਦੀ ਓਵਰਲੇ ਪਛਾਣ ਜਿੰਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਉਹੀ ਪਤਾ ਹਰ ਆਮ ਡਿਵਾਈਸ ਨੂੰ ਦੱਸਿਆ ਜਾਣ ਵਾਲਾ ਅਗਲਾ ਹੌਪ ਬਣਦਾ ਹੈ।
ਕੰਸੋਲ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਯੋਜਨਾ ਲਿਖੋ, ਕਿਉਂਕਿ ਨਾਮ ਅਤੇ ਪ੍ਰੀਫਿਕਸ ਹੀ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਇਹ ਡਿਜ਼ਾਈਨ ਭਟਕਦੇ ਹਨ: ਪ੍ਰੀਫਿਕਸ, ਗੇਟਵੇ, ਪੀਅਰ ਪਤਾ ਅਤੇ ਸਮੂਹ, ਹਰ ਸਾਈਟ ਲਈ। ਪੱਛਮ 10.52.0.0/24 ਹੈ ਜਿਸਦੀ ਸੇਵਾ 10.52.0.5 ਕਰਦਾ ਹੈ ਅਤੇ ਪੂਰਬ 10.63.0.0/24 ਹੈ ਜਿਸਦੀ ਸੇਵਾ 10.63.0.5 ਕਰਦਾ ਹੈ; ਦੋ ਸਮੂਹ west-routers ਅਤੇ east-routers ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਪ੍ਰੀਫਿਕਸ ਦੂਜੇ, ਓਵਰਲੇ ਰੇਂਜ ਜਾਂ ਕਿਸੇ ਹੋਰ ਰੂਟ ਕੀਤੇ ਮੰਜ਼ਿਲ ਨਾਲ ਓਵਰਲੈਪ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਸਰੋਤ ਬਣਾਓ, ਮਾਸਕਰੇਡਿੰਗ ਚਾਲੂ ਰੱਖੋ
ਤੈਨਾਤ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਹਰ ਸਾਈਟ ਲਈ ਇੱਕ ਨੈੱਟਵਰਕ ਸਰੋਤ ਬਣਾਓ ਅਤੇ ਉਸ ਸਾਈਟ ਦਾ ਰੂਟਿੰਗ-ਪੀਅਰ ਸਮੂਹ ਉਸ ਨਾਲ ਜੋੜੋ। ਸਰੋਤ ਪ੍ਰੀਫਿਕਸ ਹੈ ਅਤੇ ਸਮੂਹ ਉਹ ਹੋਸਟ ਹੈ ਜੋ ਇਸਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਵੀ ਘੋਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੈਨਾਤ ਸਵੈ-ਹੋਸਟ ਕੀਤੇ ਸੰਸਕਰਣ ਵਿੱਚ ਨੈੱਟਵਰਕ ਵਰਕਫਲੋ ਬਿਲਕੁਲ ਹੈ, ਕਿਉਂਕਿ ਸਮਾਨ ਨਾਮ ਵਾਲੀ ਰੂਟ ਵਸਤੂ ਵਾਲਾ ਪੁਰਾਣਾ ਇੰਟਰਫੇਸ ਵੱਖਰੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ।
ਮਾਸਕਰੇਡਿੰਗ ਚਾਲੂ ਰੱਖੋ। NetBird ਦੀ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਗਾਈਡ ਇਸ ਪ੍ਰਬੰਧ ਵਿੱਚ ਇਸਦੀ ਲੋੜ ਦੱਸਦੀ ਹੈ, ਅਤੇ ਹਰ ਮੂਲ ਪਤਾ ਦਿਸਦਾ ਰੱਖਣ ਲਈ ਇਸਨੂੰ ਬੰਦ ਕਰਨਾ ਇੱਕ ਹੌਪ ਘੱਟ ਵਾਲਾ ਉਹੀ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਹੈ; ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਓਵਰਲੇ ਦੀਆਂ ਸਰੋਤ ਜਾਂਚਾਂ ਅਤੇ ਨੀਤੀਆਂ ਕੀ ਦੇਖਦੀਆਂ ਹਨ। ਨਤੀਜਾ ਸਿੱਧਾ ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ: ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਸਰੋਤ ਵਜੋਂ ਰੂਟਿੰਗ ਪੀਅਰ ਦਰਜ ਕਰਦੀ ਹੈ, ਵਿਅਕਤੀਗਤ ਵਰਕਸਟੇਸ਼ਨ ਨਹੀਂ। ਜੇ ਉਸ ਸੇਵਾ ਦੀ ਆਗਿਆ ਸੂਚੀ ਜਾਂ ਆਡਿਟ ਵਰਕਸਟੇਸ਼ਨ ਪਤਿਆਂ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਤਾਂ ਜਾਂ ਉਮੀਦ ਬਦਲਦੀ ਹੈ ਜਾਂ ਅਨੁਵਾਦ ਤੋਂ ਪਹਿਲਾਂ ਸਾਈਟ ਸੀਮਾ ਉੱਤੇ ਪਛਾਣ ਲਾਗੂ ਕਰਨੀ ਪਵੇਗੀ।
ਸ਼ੁਰੂ ਕਰਨ ਵਾਲਿਆਂ ਨੂੰ ਅਧਿਕਾਰ ਦਿਓ, ਪ੍ਰੀਫਿਕਸਾਂ ਨੂੰ ਨਹੀਂ
ਰੂਟ ਪਤੇ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਨੀਤੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਕੌਣ ਇਸਦਾ ਇਸਤੇਮਾਲ ਕਰ ਸਕਦਾ ਹੈ; ਇਹ ਵੱਖਰੇ ਮਾਲਕਾਂ ਵਾਲੀਆਂ ਵੱਖਰੀਆਂ ਵਸਤੂਆਂ ਹਨ। ਨੀਤੀ ਕੰਮ ਦੇ ਭਾਰ ਤੋਂ ਪਿੱਛੇ ਲਿਖੋ: ਕਿਹੜਾ ਸਮੂਹ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਕਿਹੜੇ ਸਰੋਤ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਕਿਹੜੀ TCP ਸੇਵਾ ਚਾਹੀਦੀ ਹੈ। ਹਰ ਰਜਿਸਟਰਡ ਪੀਅਰ ਨੂੰ ਦੋਵੇਂ ਪ੍ਰੀਫਿਕਸ ਘੋਸ਼ਿਤ ਕਰਨ ਵਾਲਾ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਬਣਾ ਚੁੱਕਾ ਹੈ ਪਰ ਕੁਝ ਵੀ ਤੈਅ ਨਹੀਂ ਕੀਤਾ।
ਫਿਰ ਪੜ੍ਹੋ ਕਿ ਹੋਰ ਕੀ ਪਹਿਲਾਂ ਹੀ ਮਨਜ਼ੂਰ ਹੈ, ਕਿਉਂਕਿ ਤੰਗ ਨਵਾਂ ਨਿਯਮ ਉਸਦੇ ਉੱਪਰ ਵਾਲੇ ਚੌੜੇ ਪੁਰਾਣੇ ਨਿਯਮ ਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰਦਾ। ਜਦੋਂ ਪੂਰਬ ਨੂੰ ਵੀ ਪੱਛਮ ਵੱਲ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨੇ ਹੋਣ, ਤਾਂ ਉਹ ਦਿਸ਼ਾ ਆਪਣੀ ਵੱਖਰੀ ਨੀਤੀ ਵਜੋਂ ਲਿਖੋ; ਪੱਛਮ ਵੱਲੋਂ ਖੋਲ੍ਹੇ ਸੈਸ਼ਨ ਦਾ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਪੂਰਬ ਵੱਲ ਨਵੇਂ ਸੈਸ਼ਨਾਂ ਦੀ ਆਗਿਆ ਦੇਣ ਤੋਂ ਵੱਖਰਾ ਸਵਾਲ ਹੈ। ਜੇ ਪੱਛਮ ਦੇ ਸਿਰਫ ਕੁਝ ਵਰਕਸਟੇਸ਼ਨਾਂ ਨੂੰ ਪੂਰਬੀ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ, ਤਾਂ ਅਨੁਵਾਦ ਤੋਂ ਪਹਿਲਾਂ ਸਾਈਟ ਸੀਮਾ ਉੱਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਚੁਣੋ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਪਣੀ ਪ੍ਰਮਾਣਿਕਤਾ ਥਾਂ ਉੱਤੇ ਰੱਖੋ। ਰੂਟਿੰਗ ਪੀਅਰ LAN ਟ੍ਰੈਫਿਕ ਨੂੰ ਪੂਰੀ ਸਾਈਟ ਵਜੋਂ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ, ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਓਵਰਲੇ ਪਛਾਣ ਵਜੋਂ ਨਹੀਂ, ਇਸ ਲਈ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਹਿਸਾਬ ਕਿਤੇ ਹੋਰੋਂ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਹਰ ਗੇਟਵੇ ਨੂੰ ਅਗਲਾ ਹੌਪ ਸਿਖਾਓ, ਫਿਰ ਇਨਕਾਰ ਦੀ ਜਾਂਚ ਕਰੋ
ਆਮ ਡਿਵਾਈਸ ਓਵਰਲੇ ਕਦੇ ਨਹੀਂ ਦੇਖਦੇ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਦੇ ਆਪਣੇ ਗੇਟਵੇ ਨੂੰ ਦੂਰ ਦੇ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਰੂਟਿੰਗ ਪੀਅਰ ਦੇ LAN ਪਤੇ ਵੱਲ ਭੇਜਣ ਵਾਲਾ ਸਥਿਰ ਰੂਟ ਚਾਹੀਦਾ ਹੈ। ਇਹੀ ਉਹ ਕਦਮ ਹੈ ਜੋ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਕਿਉਂਕਿ NetBird ਅੰਦਰ ਦਿਸਦਾ ਸਭ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਆਮ ਵਰਕਸਟੇਸ਼ਨ ਅਜੇ ਵੀ ਸਮਾਂ ਖਤਮ ਕਰਦੇ ਹਨ। ਗੇਟਵੇ ਆਪਣਾ ਡਿਫਾਲਟ ਰੂਟ ਜਿਵੇਂ ਸੀ ਤਿਵੇਂ ਰੱਖਦਾ ਹੈ; ਇਹ ਪ੍ਰੀਫਿਕਸ ਵਾਧਾ ਹੈ, ਬਦਲੀ ਨਹੀਂ।
ਦੋਵੇਂ ਰੂਟ ਵਰਣਨ ਹਰ ਸਾਈਟ ਦੀ ਆਪਣੀ ਗੇਟਵੇ ਸੰਰਚਨਾ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਹੋਸਟ ਉੱਤੇ ਓਵਰਰਾਈਡ ਵਿੱਚ ਨਹੀਂ। ਦੋਵੇਂ ਆਮ ਸਥਿਰ ਰੂਟ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਡਿਫਾਲਟ ਰੂਟ ਨੂੰ ਨਹੀਂ ਛੂਹਦਾ:
west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਅਸਲ ਵਿੱਚ ਲੋੜੀਂਦੀ ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ, ਆਮ ਵਰਕਸਟੇਸ਼ਨ ਤੋਂ ਜਾਂਚੋ ਅਤੇ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦਰਜ ਕਰੋ: ਭੇਜਣ ਵਾਲੇ ਪਾਸੇ ਚੁਣਿਆ ਅਗਲਾ ਹੌਪ, ਮੇਲ ਖਾਂਦੀ ਨੀਤੀ ਅਤੇ ਸੇਵਾ ਵੱਲੋਂ ਦਰਜ ਕੀਤਾ ਸਰੋਤ ਪਤਾ। ਇਨਕਾਰ ਦੀ ਵੀ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ ਜਿਸ ਡਿਜ਼ਾਈਨ ਨੇ ਕਦੇ ਕੁਝ ਨਹੀਂ ਰੱਦ ਕੀਤਾ ਉਸਦੇ ਕਿਨਾਰੇ ਅਣਜਾਣ ਹਨ, ਅਤੇ ਇਨਕਾਰ ਹੀ ਇੱਕੋ-ਇੱਕ ਸਬੂਤ ਹੈ ਕਿ ਰੂਟਿੰਗ ਨਹੀਂ ਸਗੋਂ ਨੀਤੀ ਕੰਮ ਕਰ ਰਹੀ ਹੈ। ਜਦੋਂ ਪੂਰਬ ਨੂੰ ਵੀ ਸ਼ੁਰੂ ਕਰਨਾ ਹੋਵੇ, ਤਾਂ ਦੂਜੀ ਦਿਸ਼ਾ ਆਪਣੇ ਆਪ ਆਵੇਗੀ ਮੰਨਣ ਦੀ ਥਾਂ ਉਸ ਪਾਸੇ ਤੋਂ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰੋ। ਰੂਟਿੰਗ ਪੀਅਰ ਦੇ ਮੁੜ-ਸ਼ੁਰੂ, ਅੱਪਗ੍ਰੇਡ ਅਤੇ ਬਦਲਣ ਦੀ ਵੀ ਯੋਜਨਾ ਬਣਾਓ, ਕਿਉਂਕਿ ਇੱਕ ਹੋਸਟ ਸਾਈਟ ਦੀ ਨਿਰਭਰਤਾ ਬਣ ਗਿਆ ਹੈ।
| Test | A pass looks like | A failure points at |
|---|---|---|
| Ordinary workstation opens the east application | Next hop on west is the routing peer | Missing static route on the west gateway |
| A source outside policy is refused | No session in the service log | Policy too broad, or a route bypasses it |
| East starts a connection, if required | A fresh reverse session succeeds | No policy for the reverse direction |
ਨਿੱਜੀ ਨਾਵਾਂ ਨੂੰ ਆਪਣਾ ਰਿਜ਼ੌਲਵਰ ਡਿਜ਼ਾਈਨ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਪਹੁੰਚ DNS ਰਿਕਾਰਡ ਨਹੀਂ ਬਣਾਉਂਦੀ ਅਤੇ ਟੁੱਟੇ ਨਾਮ ਵਾਲਾ ਕੰਮ ਕਰਦਾ IP ਮਾਰਗ ਬਿਲਕੁਲ ਟੁੱਟੇ ਮਾਰਗ ਵਾਂਗ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਰੂਟਿੰਗ ਪੀਅਰ ਕਿਸੇ ਕਲਾਉਡ ਨੈੱਟਵਰਕ ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਪ੍ਰਦਾਤਾ ਦੇ ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਵੀ ਦੇਖੋ, ਕਿਉਂਕਿ ਰਜਿਸਟਰੇਸ਼ਨ ਉਨ੍ਹਾਂ ਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰਦੀ। ਜਾਂਚ ਦੇ ਨਿਰੀਖਣ ਯੋਜਨਾ ਦੇ ਕੋਲ ਰੱਖੋ, ਕਿਉਂਕਿ ਅੱਗੇ ਇਸਨੂੰ ਡੀਬੱਗ ਕਰਨ ਵਾਲੇ ਨੂੰ ਟੋਪੋਲੋਜੀ ਦਾ ਵਰਣਨ ਨਹੀਂ, ਮੇਲ ਖਾਂਦੀ ਨੀਤੀ ਅਤੇ ਦਰਜ ਕੀਤਾ ਸਰੋਤ ਪਤਾ ਚਾਹੀਦਾ ਹੋਵੇਗਾ।