VPN ਸਾਈਟ ਵਿਸਥਾਰ: ਗੇਟਵੇ ਤੋਂ ਪਰੇ ਵਾਪਸੀ ਮਾਰਗ ਦੀ ਪਾਲਣਾ ਕਰੋ

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

ਦੂਰ ਦਾ ਗੇਟਵੇ ਇਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਅੰਤ ਬਿੰਦੂ ਹੈ

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

ਮਾਰਗ ਨੂੰ ਤਿੰਨ ਟੁਕੜਿਆਂ ਵਿੱਚ ਖਿੱਚੋ: ਸ਼ਾਖਾ ਤੋਂ ਨੇੜਲੇ ਗੇਟਵੇ ਤੱਕ, ਨੇੜਲੇ ਤੋਂ ਦੂਰ ਤੱਕ, ਦੂਰ ਦੇ ਗੇਟਵੇ ਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ। ਹਰ ਟੁਕੜੇ ਦਾ ਆਪਣਾ ਮਾਲਕ ਅਤੇ ਆਪਣਾ ਅਸਫ਼ਲਤਾ ਢੰਗ ਹੈ।

ਟਨਲ ਨੀਤੀ ਦੀਆਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਪੜ੍ਹੋ

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

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

ਅੱਗੇ ਦਾ ਰੂਟ ਜੋੜੋ ਅਤੇ ਦਾਖ਼ਲੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

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

ਸ਼ਾਖਾ ਤੋਂ ਪਰਖੋ, ਫਿਰ ਪੁਰਾਣੇ ਮਾਰਗ ਦੀ ਮੁੜ ਪਰਖ ਕਰੋ

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

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

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

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