AWS Client VPN ਸਪਲਿਟ ਟਨਲ: ਕਿਹੜੇ ਰੂਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ

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

ਸਪਲਿਟ ਟਨਲ ਫਲੈਗ ਮੰਜ਼ਿਲਾਂ ਦੀ ਸੂਚੀ ਨਹੀਂ ਹੈ

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

ਐਂਡਪੌਇੰਟ ਰੂਟ ਟੇਬਲ ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਸਥਾਪਿਤ ਰੂਟ ਇਕੱਠੇ ਪੜ੍ਹੋ। ਲੇਬਲ ਇਰਾਦਾ ਦੱਸਦਾ ਹੈ; ਰੂਟ ਦੱਸਦੇ ਹਨ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ।

ਪਹਿਲਾ ਫੈਸਲਾ: ਕੀ ਆਮ ਇੰਟਰਨੈੱਟ ਟ੍ਰੈਫਿਕ ਸਥਾਨਕ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ?

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

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

ਦੂਜਾ ਫੈਸਲਾ: ਕਿਹੜੇ ਨਿੱਜੀ ਪ੍ਰੀਫਿਕਸ, ਅਤੇ ਕਿਸਦੇ ਅਧਿਕਾਰ ਨਾਲ?

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

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

ਜਦੋਂ ਮੰਜ਼ਿਲ ਨਾਮ ਨਾਲ ਪਹੁੰਚਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਧਿਆਨ ਦਿਓ ਕਿ ਅਗਲਾ ਸਵਾਲ ਰੂਟ ਦਾ ਨਹੀਂ, ਨਾਮ ਹੱਲ ਦਾ ਹੈ।

ਤੀਜਾ ਫੈਸਲਾ: ਕਿਹੜਾ ਰਿਜ਼ੌਲਵਰ ਟਨਲ ਦੀ ਪੈਰਵੀ ਕਰਦਾ ਹੈ?

ਕਲਾਇੰਟ ਨੂੰ ਅਜਿਹਾ DNS ਸਰਵਰ ਮਿਲ ਸਕਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ VPN ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੈ, ਅਤੇ ਉਹ ਰਿਜ਼ੌਲਵਰ ਸਿਰਫ਼ ਤਦ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਉਸ ਦਾ ਪਤਾ ਆਪ ਅਧਿਕ੍ਰਿਤ ਰੂਟ ਦੇ ਅੰਦਰ ਹੋਵੇ। ਦੋਵੇਂ ਅੱਧ ਜਾਂਚੋ: ਰਿਜ਼ੌਲਵਰ ਦਾ ਪਤਾ ਪ੍ਰਕਾਸ਼ਿਤ ਰੂਟ ਦੀ ਪੈਰਵੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਉਹਨਾਂ ਨਾਵਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਪੁੱਛਦੀ ਹੈ। ਪਤੇ ਨਾਲ ਸਫਲ ਪਰ ਹੋਸਟਨਾਮ ਨਾਲ ਅਸਫਲ ਬੇਨਤੀ ਨਾਮਕਰਨ ਵੱਲ ਸੰਕੇਤ ਕਰਦੀ ਹੈ, ਰੂਟਿੰਗ ਵੱਲ ਨਹੀਂ, ਅਤੇ ਉਸ ਹਾਲਤ ਵਿੱਚ ਟਨਲ ਡੀਬੱਗ ਕਰਨਾ ਦੁਪਹਿਰ ਬਰਬਾਦ ਕਰਦਾ ਹੈ।

ਜਨਤਕ ਨਾਮ ਕਨੈਕਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਵਾਂਗ ਹੱਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਜੋ ਤੁਸੀਂ ਕੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹੋ ਇਸ ਬਾਰੇ ਸਟੀਕ ਹੋਣ ਦਾ ਇੱਕ ਹੋਰ ਕਾਰਨ ਹੈ।

ਰੂਟ ਸੈੱਟ ਬਦਲੋ, ਫਿਰ ਦੋਵੇਂ ਦੁਨੀਆਂ ਜਾਂਚੋ

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

ਡਿਜ਼ਾਈਨ ਸਿਰਫ਼ ਤਦ ਸਵੀਕਾਰ ਕਰੋ ਜਦੋਂ ਇੱਕ ਨਿੱਜੀ ਸਰੋਤ ਅਤੇ ਇੱਕ ਜਨਤਕ ਮੰਜ਼ਿਲ ਦੋਵੇਂ ਇਛਿਤ ਢੰਗ ਨਾਲ ਵਿਵਹਾਰ ਕਰਨ, ਨਾਮ ਨਾਲ ਅਤੇ ਪਤੇ ਨਾਲ, ਉਹਨਾਂ ਪਤਾ ਪਰਿਵਾਰਾਂ ਵਿੱਚ ਜਿਨ੍ਹਾਂ ਦਾ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਸਮਰਥਨ ਕਰਦੇ ਹੋ। ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਨ ਵਾਲਾ ਟਨਲ ਸਹੀ ਵੰਡ ਕਰਨ ਵਾਲੇ ਟਨਲ ਵਰਗਾ ਨਹੀਂ ਹੁੰਦਾ।

ਰੂਟ ਸੂਚੀ ਤਰਕ ਦੇ ਨਾਲ ਰਨਬੁੱਕ ਵਿੱਚ ਲਿਖੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਜਾਣਬੁੱਝ ਕੇ ਕੀਤੇ ਬਾਹਰਕਾਵ ਨੂੰ ਭੁੱਲੇ ਹੋਏ ਤੋਂ ਵੱਖ ਕਰ ਸਕੇ।