ਮੌਜੂਦਾ Site-to-Site VPN 10.60.0.0/16 ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ, ਉਸੇ ਆਨ-ਪ੍ਰੀਮਾਈਸਿਜ਼ ਗੇਟਵੇ ਦੇ ਪਿੱਛੇ 10.70.0.0/16 ਵਜੋਂ ਨਵਾਂ ਸੇਵਾ ਨੈੱਟਵਰਕ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਪੁੱਛਦਾ ਹੈ ਕਿ ਕੀ ਪ੍ਰੌਕਸੀ ਲੋੜੀਂਦੀ ਹੈ। ਆਮ ਤੌਰ ’ਤੇ ਨਹੀਂ: ਰੂਟ ਕੀਤਾ ਮਾਰਗ ਪ੍ਰੀਫਿਕਸ ਲੈ ਕੇ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਤਦ ਜਦੋਂ ਤਿੰਨ ਚੀਜ਼ਾਂ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਕਿਹੜੀਆਂ ਤਿੰਨ ਇਹ ਤੁਹਾਡੇ ਪਹਿਲਾਂ ਤੋਂ ਚੱਲ ਰਹੇ AWS ਆਰਕੀਟੈਕਚਰ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਵਰਚੁਅਲ ਪ੍ਰਾਈਵੇਟ ਗੇਟਵੇ ਦੀ ਇੱਕ ਰੂਟ-ਟੇਬਲ ਸੀਮਾ ਹੁੰਦੀ ਹੈ; ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਦੂਜੀ ਜੋੜਦਾ ਹੈ। ਐਲਾਨ ਸਹੀ ਅਤੇ ਟੇਬਲ ਗਲਤ ਹੋਣ ’ਤੇ ਅਜਿਹਾ ਸੈਸ਼ਨ ਬਣਦਾ ਹੈ ਜੋ ਸਿਹਤਮੰਦ ਦਿਖਦਾ ਹੈ ਅਤੇ ਕੁਝ ਵੀ ਨਹੀਂ ਪਹੁੰਚਾਉਂਦਾ।

ਅਜਿਹਾ ਪ੍ਰੀਫਿਕਸ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਜੋ ਗੇਟਵੇ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚਾ ਸਕੇ

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

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

ਮਾਰਗ ਇੱਕ: ਵਰਚੁਅਲ ਪ੍ਰਾਈਵੇਟ ਗੇਟਵੇ ਦੀ ਸੀਮਾ

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

ਸਿਹਤਮੰਦ BGP ਸੈਸ਼ਨ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਚੈਨਲ ਮੌਜੂਦ ਹੈ। ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਸੇ ਦਿੱਤੀ ਸਬਨੈੱਟ ਟੇਬਲ ਨੇ ਰੂਟ ਲਿਆ ਹੈ ਜਾਂ ਨਹੀਂ।

ਮਾਰਗ ਦੋ: ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਇੱਕ ਟੇਬਲ ਜੋੜਦਾ ਹੈ

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

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

ਰੂਟ ਪ੍ਰਚਾਰ ਵੀ ਹਰ ਅਟੈਚਮੈਂਟ ਨੂੰ ਪ੍ਰੀਫਿਕਸ ਨਹੀਂ ਦਿੰਦਾ। ਇਹ ਇਸਨੂੰ ਉਨ੍ਹਾਂ ਟੇਬਲਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕਨਫਿਗਰ ਹਨ।

ਵਾਪਸੀ ਮਾਰਗ ਆਪਣਾ ਵੱਖਰਾ ਨੀਤੀ ਫੈਸਲਾ ਹੈ

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

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

ਨਵੇਂ ਨੈੱਟਵਰਕ ਵਿੱਚ ਸਰੋਤ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਸਬਨੈੱਟ ਵਿੱਚ ਮੰਜ਼ਿਲ ਨਾਲ ਪਰਖ ਕਰੋ, ਫਿਰ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਦੁਹਰਾਓ। ਇੱਕ-ਦਿਸ਼ਾ ਪਰਖ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਸਾਬਤ ਕਰਦੀ ਹੈ।

ਪ੍ਰੌਕਸੀ ਅਸਲ ਵਿੱਚ ਵਧੀਆ ਸੀਮਾ ਕਦੋਂ ਹੁੰਦੀ ਹੈ

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

ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਫੈਸਲਾ ਕਰੋ: ਸਥਾਨਕ ਫਾਰਵਰਡਿੰਗ, ਐਲਾਨ, ਟੇਬਲ ਸੀਮਾ, ਵਾਪਸੀ ਨੀਤੀ। ਜੋ ਪਹਿਲਾ ਅਸਫਲ ਹੋਵੇ ਉਸਨੂੰ ਠੀਕ ਕਰੋ, ਅਤੇ ਫਿਰ ਹੀ ਪੁੱਛੋ ਕਿ ਕੀ ਰੂਟ ਕੀਤਾ ਮਾਰਗ ਹੀ ਸਹੀ ਜਵਾਬ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ