ਦੋ ਸਾਈਟਾਂ, ਇੱਕ ਸਬਨੈੱਟ: ਹਰ ਇੱਕ ਲਈ ਅਲਿਆਸ ਦ੍ਰਿਸ਼ ਬਣਾਓ

ਦੋ ਗਾਹਕ ਸਾਈਟਾਂ ਦੋਵੇਂ 192.168.50.0/24 ਚਲਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਦੂਰਸਥ ਇੰਜੀਨੀਅਰ ਨੂੰ ਹਰ ਇੱਕ ਵਿੱਚ ਉਸੇ ਪਤੇ ’ਤੇ ਪ੍ਰਿੰਟਰ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ। ਕੋਈ ਵੀ ਰਾਊਟਿੰਗ ਚਾਲ ਇਸ ਅਸਪਸ਼ਟਤਾ ਨੂੰ ਇਕੱਲੀ ਹੱਲ ਨਹੀਂ ਕਰਦੀ। ਹਰ ਸਾਈਟ ਨੂੰ ਵੱਖਰਾ ਪਤਾ-ਦ੍ਰਿਸ਼ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਗੇਟਵੇ ਨੂੰ ਕੁਝ ਵੀ ਅੱਗੇ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸੇ ਦ੍ਰਿਸ਼ ਤੋਂ ਸਾਈਟ ਚੁਣਨੀ ਚਾਹੀਦੀ ਹੈ।

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

ਹਰ ਸਾਈਟ ਲਈ ਇੱਕ ਅਲਿਆਸ ਪ੍ਰੀਫਿਕਸ ਚੁਣੋ

ਹਰ ਸਾਈਟ ਨੂੰ ਇੱਕ ਪੂਰਾ ਅਲਿਆਸ ਪ੍ਰੀਫਿਕਸ ਦਿਓ ਜੋ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਦਾ ਨਹੀਂ ਹੈ। ਦੋ ਸਾਈਟਾਂ ਦੀ ਯੋਜਨਾ ਸਾਈਟ A ਦੇ 192.168.50.0/24 ਨੂੰ 172.21.10.0/24 ’ਤੇ ਅਤੇ ਸਾਈਟ B ਦੇ ਸਮਾਨ LAN ਨੂੰ 172.21.20.0/24 ’ਤੇ ਮੈਪ ਕਰ ਸਕਦੀ ਹੈ। ਉਮੀਦਵਾਰਾਂ ਨੂੰ ਹਰ ਹਿੱਸਾ ਲੈਣ ਵਾਲੇ ਨੈੱਟਵਰਕ ਦੇ ਵਿਰੁੱਧ ਜਾਂਚੋ, ਜਿਸ ਵਿੱਚ ਕਲਾਊਡ VPC ਅਤੇ ਹੋਰ VPN ਪੂਲ ਸ਼ਾਮਲ ਹਨ। ਨਿੱਜੀ ਪਤਾ-ਥਾਂ ਹਰ ਸੰਸਥਾ ਸਾਂਝੀ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਰੇਂਜ RFC 1918 ਹੋਣਾ ਇਹ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਇਹ ਇੱਥੇ ਖਾਲੀ ਹੈ।

ਦੂਰਸਥ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਮੂਲ ਸਬਨੈੱਟ ਨਹੀਂ, ਅਲਿਆਸ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ। ਮੂਲ ਰੇਂਜ ਸਥਾਨਕ ਤੱਥ ਹੀ ਰਹਿੰਦੀ ਹੈ।

ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰੋ

ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰੋ। ਮੰਜ਼ਿਲ ਮੈਪਿੰਗ ਅਲਿਆਸ ਪਤੇ ਨੂੰ ਮਾਲਕ ਸਾਈਟ ’ਤੇ ਮੂਲ ਪਤੇ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਦੀ ਹੈ। ਸਰੋਤ ਮੈਪਿੰਗ ਦੂਰਸਥ ਕਾਲਰ ਨੂੰ ਅਜਿਹੇ ਅਲਿਆਸ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਦੀ ਹੈ ਜਿਸਨੂੰ ਹੋਰ ਸਾਈਟਾਂ ਵੱਖਰਾ ਪਛਾਣ ਸਕਣ।

ਸਥਿਰ ਇੱਕ-ਤੋਂ-ਇੱਕ ਮੈਪਿੰਗ ਨਿਰਧਾਰਕ ਹੈ, ਅਤੇ ਇਸ ਨਾਲ ਅਮਲ ਸਟੇਟਲੈੱਸ ਨਹੀਂ ਹੋ ਜਾਂਦਾ। ਉਲਟਾ ਅਨੁਵਾਦ ਕਨੈਕਸ਼ਨ ਸਥਿਤੀ ’ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਫੇਲਓਵਰ ਜਾਂ ਅਸਮਮਿਤ ਮਾਰਗ ਉਸ ਯੋਜਨਾ ਨੂੰ ਤੋੜ ਸਕਦੇ ਹਨ ਜੋ ਇਸਨੂੰ ਅਣਡਿੱਠ ਕਰਦੀ ਹੈ। ਪਲੇਟਫਾਰਮ ਦਾ ਦਸਤਾਵੇਜ਼ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

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

ਯੋਜਨਾ ਨੂੰ ਓਵਰਲੇ ਰਾਹੀਂ ਲੈ ਜਾਓ

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

ਪੂਰੇ ਸਬਨੈੱਟ ਦਾ ਪ੍ਰਕਾਸ਼ਨ ਇੱਕ ਸੇਵਾ ਦੇ ਪ੍ਰਕਾਸ਼ਨ ਤੋਂ ਵਿਆਪਕ ਹੈ। ਜੇ ਸਿਰਫ਼ ਕੁਝ ਮਸ਼ੀਨਾਂ ਜਾਂ ਪੋਰਟ ਚਾਹੀਦੇ ਹਨ, ਤਾਂ ਪਹੁੰਚ ਨਿਯਮ ਮੈਪਿੰਗ ਤੋਂ ਸੰਗਰੇ ਰੱਖੋ।

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

ਹਰ ਕਾਲਰ ਜੋ ਨਾਮ ਦੇਖਦਾ ਹੈ ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰੋ

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

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

ਹਰ ਸਾਈਟ ਲਈ ਰਿਕਾਰਡ ਕਰੋ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰੋ

ਅਸਲੀ ਕਾਲਰ ਤੋਂ ਹਰ ਸਾਈਟ ਵੱਖਰੀ ਸਵੀਕਾਰ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਿਹੜੀ ਮਸ਼ੀਨ ਨੇ ਜਵਾਬ ਦਿੱਤਾ। ਮੂਲ ਪਤਾ, ਅਲਿਆਸ, ਮਾਲਕ ਗੇਟਵੇ ਅਤੇ ਮਨਜ਼ੂਰ ਸੇਵਾ ਇਕੱਠੇ ਰਿਕਾਰਡ ਕਰੋ।

ਜਦੋਂ ਤੀਜੀ ਸਾਈਟ ਉਸੇ ਡਿਫੌਲਟ LAN ਨਾਲ ਆਉਂਦੀ ਹੈ ਤਾਂ ਇਹੀ ਸੂਚੀ ਫ਼ਰਕ ਬਚਾਉਂਦੀ ਹੈ। ਨੀਤੀ-ਆਧਾਰਿਤ IPsec NAT ਗਾਈਡ ਇੱਕ ਠੋਸ ਅਨੁਵਾਦ ਮਾਡਲ ਦਸਤਾਵੇਜ਼ ਕਰਦੀ ਹੈ; ਇਹ ਹਰ ਪਲੇਟਫਾਰਮ ਲਈ ਸਮਝੌਤਾ ਨਹੀਂ ਹੈ।