VPN ਐਂਡਪੌਇੰਟ ਨਾਮ ਬਨਾਮ ਨਿੱਜੀ ਸੇਵਾ ਦਾ ਨਾਮ: ਦੋ ਮਾਲਕ

ਦੋ ਨਾਮ ਇੱਕੋ ਸ਼ਾਖਾ ਦਾ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਬਿਲਕੁਲ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ। vpn.branch.example ਦੂਰਲੇ ਸਾਥੀ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ VPN ਐਂਡਪੌਇੰਟ ਕਿੱਥੇ ਮਿਲੇਗਾ, ਅਤੇ ਕੋਈ ਵੀ ਟਨਲ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਹੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। inventory.branch.example ਅਧਿਕਾਰਤ ਵਰਤੋਂਕਾਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਨਿੱਜੀ ਐਪਲੀਕੇਸ਼ਨ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਟਨਲ ਚਾਲੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਇਸ ਦੀ ਅਹਿਮੀਅਤ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਦੀ ਸੰਭਾਲ ਦੂਜੇ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦੀ।

ਕਿਸੇ ਵੀ ਇੱਕ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਰਿਕਾਰਡਾਂ ਦੇ ਨਾਮ ਲਿਖੋ

ਦੋਵੇਂ ਆਪਣੇ ਮਾਲਕਾਂ ਨਾਲ ਲਿਖੋ। ਐਂਡਪੌਇੰਟ ਲਈ ਲਿਖੋ ਕਿ ਜਨਤਕ ਪਤਾ ਕੌਣ ਅਪਡੇਟ ਕਰਦਾ ਹੈ ਅਤੇ VPN ਕਲਾਇੰਟ ਆਪਣਾ ਜਵਾਬ ਕਿਵੇਂ ਤਾਜ਼ਾ ਕਰਦਾ ਹੈ। ਸੇਵਾ ਲਈ ਲਿਖੋ ਕਿ ਨਿੱਜੀ ਪਤੇ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ, ਕਿਹੜਾ ਜ਼ੋਨ ਰਿਕਾਰਡ ਰੱਖਦਾ ਹੈ ਅਤੇ ਕਿਹੜੇ ਰਿਜ਼ੌਲਵਰ ਇਸ ਲਈ ਜਵਾਬ ਦੇਣੇ ਚਾਹੀਦੇ ਹਨ।

ਇਹ ਛੋਟੀ ਸੂਚੀ ਇਸ ਖੇਤਰ ਦੀ ਸਭ ਤੋਂ ਆਮ ਗ਼ਲਤ ਨਿਦਾਨ ਨੂੰ ਰੋਕਦੀ ਹੈ: ਕੰਮ ਕਰ ਰਹੇ ਸ਼ਾਖਾ ਟਨਲ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨਾ, ਉਸ ਰਿਕਾਰਡ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਇਸਦੇ ਅੰਦਰ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਟਨਲ ਸੇਵਾ ਦੇ ਨਾਮ ਲਈ ਢੋਆ-ਢੁਆਈ ਹੈ; ਇਹ ਇਸਦਾ ਅਧਿਕਾਰ ਨਹੀਂ ਹੈ।

ਜਦੋਂ ਤਬਦੀਲੀ ਪ੍ਰਸਤਾਵਿਤ ਹੋਵੇ, ਪੁੱਛੋ ਕਿ ਇਹ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਹੜੇ ਰਿਕਾਰਡ ਨੂੰ ਛੂਹਦੀ ਹੈ। ਜੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਤਬਦੀਲੀ ਤਹਿ-ਮਿਤੀ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੈ।

ਕੋਈ ਵੀ ਟਨਲ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਐਂਡਪੌਇੰਟ ਹੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

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

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

ਸੇਵਾ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ

ਹੁਣ ਮੰਨ ਲਓ ਟਨਲ ਤੰਦਰੁਸਤ ਰਹਿੰਦਾ ਹੈ ਪਰ ਇਨਵੈਂਟਰੀ ਸਰਵਰ 172.26.14.20 ਤੋਂ 172.26.14.35 ਤੇ ਸਰਦਾ ਹੈ। ਜਨਤਕ ਐਂਡਪੌਇੰਟ ਰਿਕਾਰਡ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹੁੰਦਾ, ਜਦੋਂ ਕਿ ਨਿੱਜੀ ਸੇਵਾ ਰਿਕਾਰਡ ਬਦਲਣਾ ਪੈਂਦਾ ਹੈ। ਉਸ ਸੇਵਾ ਲਈ ਰਾਖਵਾਂ ਪਤਾ ਜਾਂ ਸਥਿਰ ਅਲਾਟਮੈਂਟ ਵਰਤਣ ਨਾਲ ਇਹ ਵਿਰਲਾ ਹੁੰਦਾ ਹੈ; ਅਧਿਕਾਰਤ ਅਪਡੇਟ ਮਾਰਗ ਉਹ ਵਾਰ ਸੰਭਾਲਦਾ ਹੈ ਜਦੋਂ ਇਹ ਜਾਣ-ਬੁੱਝ ਕੇ ਹੁੰਦਾ ਹੈ।

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

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

ਦੋਵੇਂ ਮਾਰਗ ਵੱਖਰੇ ਤੌਰ ਤੇ ਜਾਂਚੋ

ਟਨਲ ਤੋਂ ਬਾਹਰੋਂ ਐਂਡਪੌਇੰਟ ਅਤੇ ਅੰਦਰੋਂ ਸੇਵਾ ਜਾਂਚੋ, ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਦੋ ਸੁਤੰਤਰ ਤੱਥਾਂ ਵਜੋਂ ਰੱਖੋ:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

ਹਰ ਪਤਾ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਜੋੜੀ ਚਲਾਓ ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਕਿਹੜਾ ਰਿਕਾਰਡ ਸਰਿਆ। ਜੋ ਹੈਂਡਓਵਰ ਸਿਰਫ਼ ਕਹਿੰਦਾ ਹੈ «DNS ਅਪਡੇਟ ਹੋ ਗਿਆ» ਉਹ ਅਗਲੇ ਇੰਜੀਨੀਅਰ ਨੂੰ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਲਈ ਛੱਡ ਦਿੰਦਾ ਹੈ ਕਿ ਦੋ ਜੀਵਨ-ਚੱਕਰਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਅਸਲ ਵਿੱਚ ਚੱਲਿਆ।