AWS Client VPN ਐਂਡਪੌਇੰਟ DNS: ਹੱਲ ਕੀਤਾ IP ਪਿੰਨ ਕਰਨਾ ਕਿਉਂ ਫੇਲ ਹੁੰਦਾ ਹੈ
AWS Client VPN ਐਂਡਪੌਇੰਟ ਦਾ ਨਾਮ ਉਸ ਪਤੇ ਨਾਲ ਬਦਲੋ ਜੋ ਤੁਸੀਂ ਹੱਲ ਕੀਤਾ ਸੀ, ਅਤੇ ਟਨਲ ਬਾਅਦ ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਵੇਗਾ। ਐਕਸਪੋਰਟ ਕੀਤਾ ਨਾਮ ਅਤੇ ਉਸਦਾ ਬੇਤਰਤੀਬ ਪ੍ਰੀਫਿਕਸ ਰੱਖੋ।
ਪਿਛਲੇ ਹਫ਼ਤੇ dig +short ਨੇ ਤੁਹਾਡੀ AWS Client VPN ਪਰੋਫਾਈਲ ਵਿੱਚ ਐਂਡਪੌਇੰਟ ਨਾਮ ਲਈ ਇੱਕ ਪਤਾ ਦਿੱਤਾ, ਅਤੇ ਟਨਲ ਜੁੜ ਗਿਆ। ਇਸ ਹਫ਼ਤੇ ਉਹੀ ਪਰੋਫਾਈਲ ਤੁਹਾਡੇ ਲੈਪਟਾਪ 'ਤੇ 'Connecting' 'ਤੇ ਰੁਕੀ ਹੈ, ਜਦਕਿ ਸਹਿਕਰਮੀ ਦੀ ਨਾ-ਛੋਹੀ ਕਾਪੀ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ। ਕੁਝ ਵੀ ਬਲੌਕ ਨਹੀਂ ਹੋਇਆ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਦੀ ਮਿਆਦ ਖ਼ਤਮ ਨਹੀਂ ਹੋਈ। ਕਿਸੇ ਨੇ ਐਂਡਪੌਇੰਟ ਹੋਸਟਨਾਮ ਨੂੰ ਉਸ ਹੱਲ ਕੀਤੇ ਪਤੇ ਨਾਲ ਬਦਲ ਦਿੱਤਾ, ਅਤੇ ਸੇਵਾ ਹੁਣ ਉੱਥੇ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀ। ਐਕਸਪੋਰਟ ਕੀਤਾ ਨਾਮ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਇਸ ਬਦਲਾਅ ਨੂੰ ਸਹਿਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ।
ਤੁਹਾਡੀ ਪਰੋਫਾਈਲ ਦਾ ਨਾਮ ਉਹ ਨਾਮ ਨਾ ਹੋਵੇ ਜਿਸਦੀ ਪੁੱਛਗਿੱਛ ਹੁੰਦੀ ਹੈ
Client VPN ਤੋਂ ਐਕਸਪੋਰਟ ਕੀਤੀਆਂ ਪਰੋਫਾਈਲਾਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ remote-random-hostname ਹੁੰਦਾ ਹੈ। ਉਹ ਵਿਕਲਪ ਚਾਲੂ ਹੋਣ 'ਤੇ ਕਲਾਇੰਟ ਇੱਕ ਵਾਰ ਵਰਤੋਂ ਵਾਲਾ ਲੇਬਲ ਬਣਾਉਂਦਾ ਹੈ, ਬਿੰਦੂ ਨਾਲ ਐਂਡਪੌਇੰਟ ਨਾਮ ਨਾਲ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਮਿਲਿਆ ਨਾਮ ਹੱਲ ਕਰਦਾ ਹੈ। ਐਂਡਪੌਇੰਟ ਦੇ ਜ਼ੋਨ ਵਿੱਚ ਵਾਈਲਡਕਾਰਡ ਰਿਕਾਰਡ ਕਿਸੇ ਵੀ ਲੇਬਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਬਣਾਇਆ ਪ੍ਰੀਫਿਕਸ ਵੀ ਹੱਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਸ ਲਈ ਕਵੈਰੀ ਹੱਥ ਨਾਲ ਦੁਹਰਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਇਹ ਚਾਲ ਅਦਿੱਖ ਰਹਿੰਦੀ ਹੈ।
ਇਸ ਲਈ ਜਦੋਂ ਤੁਸੀਂ ਐਂਡਪੌਇੰਟ ਨਾਮ ਟਰਮੀਨਲ ਵਿੱਚ ਪੇਸਟ ਕਰਕੇ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਕਲਾਇੰਟ ਵੱਲੋਂ ਜੁੜਨ ਸਮੇਂ ਵਰਤੇ ਨਾਮ ਤੋਂ ਵੱਖਰਾ ਨਾਮ ਹੱਲ ਕੀਤਾ ਹੈ। ਇਹ ਅੰਤਰ ਪਰੋਫਾਈਲ ਵਿੱਚ ਸੁਧਾਰਨ ਵਾਲਾ ਨੁਕਸ ਨਹੀਂ ਹੈ। ਲੇਬਲ ਜਾਣਬੁੱਝ ਕੇ ਦੁਬਾਰਾ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ: ਵਿਕਲਪ ਕੈਸ਼ ਨੂੰ ਪੁਰਾਣਾ ਜਵਾਬ ਰੱਖਣ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਦੇ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਜਾਂ ਸੈਸ਼ਨ ਦੀ ਪਛਾਣ ਨਹੀਂ ਕਰਦਾ।
ਮੈਨੂੰ ਉਹ ਅਨੁਕੂਲਤਾ-ਸਥਿਤੀ ਮਿਲੀ ਹੈ ਜਿੱਥੇ ਕਲਾਇੰਟ ਵਿਕਲਪ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ। AWS ਹੱਲ ਦਰਜ ਕਰਦਾ ਹੈ: ਅਸਲ ਐਂਡਪੌਇੰਟ ਨਾਮ ਰੱਖੋ ਅਤੇ ਅੱਗੇ ਇੱਕ ਬੇਤਰਤੀਬ ਸਟਰਿੰਗ ਤੇ ਬਿੰਦੂ ਜੋੜੋ, ਇਸਨੂੰ ਪੇਸਟ ਕਰਨ ਵਾਲਾ ਮੁੱਲ ਨਹੀਂ ਸਗੋਂ ਨਾਮਕਰਨ ਢਾਂਚਾ ਮੰਨੋ। ਪੁਰਾਣੇ ਕਲਾਇੰਟ 'ਤੇ ਇਹ ਲਾਗੂ ਕਰਨਾ ਜਾਇਜ਼ ਹੈ; ਪ੍ਰੀਫਿਕਸ ਵਾਲੀ ਸਟਰਿੰਗ ਨੂੰ ਐਂਡਪੌਇੰਟ ਵਜੋਂ ਹਾਰਡਕੋਡ ਕਰਨਾ ਨਹੀਂ।
ਸੰਭਾਲਿਆ ਜਵਾਬ ਸਹੀ ਕਿਉਂ ਨਹੀਂ ਰਹਿ ਸਕਦਾ
Client VPN ਐਂਡਪੌਇੰਟ ਪਤੇ AWS ਸੰਭਾਲਦਾ ਹੈ ਅਤੇ ਸਮੇਂ ਨਾਲ ਬਦਲਦੇ ਹਨ, ਜੋ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਸਪਸ਼ਟ ਕਹਿੰਦਾ ਹੈ। ਫੜਿਆ ਜਵਾਬ ਇੱਕ ਹੱਲ ਦਾ ਸਨੈਪਸ਼ਾਟ ਹੈ। ਇਸਨੂੰ ਹਾਰਡਕੋਡ ਕਰਨ ਵਾਲੀ ਪਰੋਫਾਈਲ ਸੇਵਾ ਹਿਲਣ ਸਾਰ ਰਿਟਾਇਰ ਹੋਏ ਹੋਸਟ ਵੱਲ ਨਿਸ਼ਾਨਾ ਬਣੀ ਪਰੋਫਾਈਲ ਬਣ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਫੇਲ੍ਹ ਹੋਣਾ ਘੱਟ ਹੀ DNS ਵਰਗਾ ਲੱਗਦਾ ਹੈ: ਤੁਹਾਨੂੰ ਕਨੈਕਸ਼ਨ ਟਾਈਮਆਊਟ ਜਾਂ ਰੁਕਿਆ ਹੈਂਡਸ਼ੇਕ ਮਿਲਦਾ ਹੈ, ਇਸ ਲਈ ਲੋਕ ਰਾਊਟਿੰਗ ਅਤੇ ਸਰਟੀਫਿਕੇਟਾਂ ਪਿੱਛੇ ਭੱਜਦੇ ਹਨ।
/etc/hosts ਵਿੱਚ ਉਹੀ ਜਵਾਬ ਉਹੀ ਮਿਆਦ ਵਾਧੂ ਸਮੱਸਿਆ ਨਾਲ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ। hosts ਐਂਟਰੀ ਰੀਬੂਟ, ਮੁੜ-ਐਕਸਪੋਰਟ ਅਤੇ 'ਕਲਾਇੰਟ ਮੁੜ ਸਥਾਪਿਤ ਕਰੋ' ਸੁਧਾਰਾਂ ਤੋਂ ਬਚੀ ਰਹਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਪਤਾ ਹਿਲਣ 'ਤੇ ਹਰ ਵਾਰ ਫੇਲ੍ਹ ਹੋਣਾ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਮੈਂ ਇੱਕ ਨੂੰ ਹਫ਼ਤਿਆਂ ਤੱਕ ਬੇਨੁਕਸਾਨ ਪਿਆ ਅਤੇ ਫਿਰ ਉਸਨੂੰ ਢੋਣ ਵਾਲੀ ਹਰ ਮਸ਼ੀਨ ਨੂੰ ਬੰਦ ਕਰਦੇ ਦੇਖਿਆ, ਜਦਕਿ ਨਵੀਆਂ ਸਥਾਪਨਾਵਾਂ ਆਮ ਤਰ੍ਹਾਂ ਜੁੜ ਰਹੀਆਂ ਸਨ। ਇੱਕੋ ਖਾਤੇ 'ਤੇ ਇੱਕ ਗਰੁੱਪ ਫੇਲ੍ਹ ਅਤੇ ਦੂਜਾ ਠੀਕ ਹੋਣ ਦਾ ਇਹ ਵੰਡਣਾ ਸਭ ਤੋਂ ਸਸਤਾ ਸੁਰਾਗ ਹੈ।
ਬੇਤਰਤੀਬੀ ਦਾ ਦਾਇਰਾ ਠੀਕ ਤਰ੍ਹਾਂ ਨਿਰਧਾਰਤ ਕਰੋ। ਇਹ ਹਰ ਕਨੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼ 'ਤੇ ਹੁੰਦੀ ਹੈ। ਸਥਾਪਿਤ ਟਨਲ ਆਪਣਾ ਐਂਡਪੌਇੰਟ ਮੁੜ ਹੱਲ ਨਹੀਂ ਕਰਦਾ, ਸੈਸ਼ਨ ਵਿਚਕਾਰ ਸਰਵਰ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ ਵੱਖਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨ ਬੇਨਤੀਆਂ ਹਰ ਇੱਕ ਨਵਾਂ VPN ਹੋਸਟ ਨਹੀਂ ਚੁਣਦੀਆਂ। ਸਿਰਫ਼ ਅਗਲੀ ਕੋਸ਼ਿਸ਼ ਮੁੜ ਹੱਲ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਦੁਪਹਿਰ ਭਰ ਚੱਲਣ ਵਾਲਾ ਸੈਸ਼ਨ ਕੱਲ੍ਹ ਸਵੇਰ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।
ਟਨਲ ਉੱਠਦਿਆਂ ਸੇਵਾ ਕੀ ਜਾਂਚਦੀ ਹੈ
Client VPN ਮੰਗ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਜਿਸ ਪਤੇ ਨਾਲ ਜੁੜੇ ਹੋ ਉਹ ਐਂਡਪੌਇੰਟ ਦੇ DNS ਨਾਮ ਲਈ ਹੱਲ ਕੀਤੇ ਪਤੇ ਨਾਲ ਮੇਲ ਖਾਵੇ। ਇਹ ਇੱਕ ਸ਼ਰਤ ਅਸੰਬੰਧੀ ਲੱਗਣ ਵਾਲੀਆਂ ਕਈ ਫੇਲ੍ਹਤਾਵਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ: ਹੋਰ ਕਿਤੇ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਕਸਟਮ DNS ਰਿਕਾਰਡ, ਅਸਲ ਐਂਡਪੌਇੰਟ ਪਤੇ ਵੱਲ ਭੇਜਣ ਵਾਲਾ ਕਸਟਮ ਫਰੰਟਐਂਡ, ਅਤੇ ਕੱਚੇ ਪਤੇ 'ਤੇ ਮੁੜ ਲਿਖੀ ਪਰੋਫਾਈਲ। AWS ਕਸਟਮ-ਰਿਕਾਰਡ-ਜਮ੍ਹਾਂ-ਫਾਰਵਰਡਿੰਗ ਪ੍ਰਬੰਧ ਨੂੰ ਨਵੇਂ AWS ਕਲਾਇੰਟਾਂ ਨਾਲ ਫੇਲ੍ਹਤਾ ਵਜੋਂ ਦਰਜ ਕਰਦਾ ਹੈ। ਜਾਂਚ ਸੰਕੁਚਿਤ ਹੈ; ਇਹ ਹਰ ਉਪਨਾਮ 'ਤੇ ਪਾਬੰਦੀ ਦਾ ਫੈਸਲਾ ਨਹੀਂ।
ਇਹ VPN ਪ੍ਰੋਟੋਕੋਲ ਬਾਰੇ ਆਮ ਨਿਯਮ ਵੀ ਨਹੀਂ ਹੈ। ਸੰਖਿਆਤਮਕ remote ਆਮ OpenVPN ਡਿਪਲੌਇਮੈਂਟ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੈਧ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਇਸੇ ਤਰ੍ਹਾਂ ਚੱਲਦੇ ਹਨ। ਪਾਬੰਦੀ ਪ੍ਰਬੰਧਿਤ ਪ੍ਰਬੰਧ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਉਸਦੇ ਹੇਠਲੇ ਪ੍ਰੋਟੋਕੋਲ ਤੋਂ ਨਹੀਂ।
ਜੋ ਸਰਟੀਫਿਕੇਟ ਦੀ ਪੁਸ਼ਟੀ ਨੂੰ ਢਿੱਲਾ ਕਰਨਾ ਗਲਤ ਪ੍ਰਤੀਕਿਰਿਆ ਬਣਾਉਂਦਾ ਹੈ। ਪਤਾ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਪਰੋਫਾਈਲ ਫੇਲ੍ਹ ਹੋਵੇ ਤਾਂ ਸਰਵਰ ਪੁਸ਼ਟੀ ਬੰਦ ਕਰਨਾ ਹੱਲ ਜਾਂ ਪਤਾ-ਮੇਲ ਦੀ ਸ਼ਰਤ ਸੁਧਾਰਨ ਦੀ ਬਜਾਏ ਗਲਤੀ ਨੂੰ ਹਿਲਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਵੀ ਭਰੋਸਾ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਐਕਸਪੋਰਟ ਕੀਤਾ CA, ਸਰਵਰ ਪੁਸ਼ਟੀ ਅਤੇ ਆਪਸੀ ਪ੍ਰਮਾਣਿਕਤਾ ਸੈਟਿੰਗਾਂ ਜਿਵੇਂ ਆਈਆਂ ਸਨ ਉਵੇਂ ਰੱਖੋ।
ਅਨੁਮਤੀ ਸੂਚੀਆਂ, ਈਗ੍ਰੇਸ ਅਤੇ ਪ੍ਰਾਈਵੇਟ DNS ਤਿੰਨ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ
ਲੈਪਟਾਪ ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਮੰਜ਼ਿਲ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਬਾਹਰੀ ਸਰੋਤੇ ਬਾਰੇ ਹੈ। ਨੈੱਟਵਰਕ ਮਾਲਕ ਨੂੰ ਐਂਡਪੌਇੰਟ ਨਾਮ, ਟਰਾਂਸਪੋਰਟ ਅਤੇ ਕਨਫਿਗਰ ਕੀਤਾ ਪੋਰਟ ਦਿਓ, ਫਿਰ ਪੁੱਛੋ ਕਿ ਕੀ ਉਨ੍ਹਾਂ ਦਾ ਨਿਯੰਤਰਣ ਸੇਵਾ ਦੇ DNS ਵਿਵਹਾਰ ਦੀ ਪਾਲਣਾ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਫੜਿਆ ਪਤਾ ਰੱਖਣ ਵਾਲਾ ਨਿਯਮ ਬਿਨਾਂ ਲਿਖੀ ਮਿਆਦ ਵਾਲਾ ਸਨੈਪਸ਼ਾਟ ਹੈ। ਜੇ ਨਿਯੰਤਰਣ ਸਿਰਫ਼ ਬਦਲਣਯੋਗ ਮੰਜ਼ਿਲਾਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਚੁੱਪਚਾਪ ਜਵਾਬ ਹਾਰਡਕੋਡ ਕਰਨ ਦੀ ਬਜਾਏ ਰੋਲਆਊਟ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਖਾਲੀ ਥਾਂ ਭਰੋ।
ਟਨਲ ਉੱਪਰ ਆਉਣ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਬੇਨਤੀਆਂ ਲਈ ਸਥਿਰ ਸਰੋਤ ਪਤਾ ਲੋੜਦੇ ਭਾਈਵਾਲ ਦੀ ਲੋੜ ਵੱਖਰੀ ਹੈ: ਈਗ੍ਰੇਸ। ਵੈੱਬਸਾਈਟ ਕੀ ਦੇਖਦੀ ਹੈ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਰੂਟ ਅਤੇ ਸਪਲਿਟ-ਟਨਲ ਨੀਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਕਲਾਇੰਟ ਜਿਸ ਪਤੇ ਨਾਲ ਜੁੜਿਆ ਉਸ 'ਤੇ ਨਹੀਂ। ਸਪਲਿਟ-ਟਨਲ ਟ੍ਰੈਫਿਕ AWS ਨੂੰ ਛੂਹ ਵੀ ਨਹੀਂ ਸਕਦਾ।
ਟਨਲ ਦੇ ਅੰਦਰ ਪ੍ਰਾਈਵੇਟ DNS ਤੀਜੀ ਪਰਤ ਹੈ। ਕਲਾਇੰਟਾਂ ਨੂੰ ਦਿੱਤਾ ਰਿਜ਼ੋਲਵਰ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਅੰਦਰੂਨੀ ਨਾਵਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ; ਟਨਲ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਜਨਤਕ ਐਂਡਪੌਇੰਟ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਐਂਡਪੌਇੰਟ ਹੱਲ ਫੇਲ੍ਹ ਹੋਣਾ ਅਤੇ ਅੰਦਰੂਨੀ ਐਪਲੀਕੇਸ਼ਨ ਹੱਲ ਫੇਲ੍ਹ ਹੋਣਾ ਵੱਖਰੇ ਪੜਾਵਾਂ ਵਿੱਚ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਤੁਸੀਂ ਗਲਤ ਲੌਗ 'ਤੇ ਪਹੁੰਚਦੇ ਹੋ।
ਪਤਾ ਟੱਬਰ ਵੀ ਉਸੇ ਸੂਚੀ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। IPv4 ਜਵਾਬ IPv6 ਜਾਂ ਦੋਹਰੇ ਸਟੈਕ ਐਂਡਪੌਇੰਟ ਦੇ ਮਨਜ਼ੂਰ ਰਸਤੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਇਸ ਲਈ ਇੱਕ ਟੱਬਰ ਵਿੱਚ ਲਿਆ ਸਨੈਪਸ਼ਾਟ ਦੂਜੇ ਲਈ ਸਬੂਤ ਨਹੀਂ।
ਕੁਝ ਵੀ ਪਿੰਨ ਕੀਤੇ ਬਿਨਾਂ ਕਨੈਕਸ਼ਨ ਜਾਂਚੋ
ਐਕਸਪੋਰਟ ਹੋਈ ਪਰੋਫਾਈਲ ਤੋਂ ਹੀ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪੜ੍ਹੋ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਕੀ ਮੰਗਦੀ ਹੈ:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'ਫਿਰ ਤਿੰਨ ਚੀਜ਼ਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ: ਪਰੋਫਾਈਲ ਵਿੱਚਲਾ ਐਂਡਪੌਇੰਟ ਨਾਮ, ਨਵੀਂ ਕੋਸ਼ਿਸ਼ ਲਈ ਕਲਾਇੰਟ ਵੱਲੋਂ ਦੱਸਿਆ ਪਤਾ, ਅਤੇ ਨਾਮ ਹੁਣ ਕੀ ਵਿੱਚ ਹੱਲ ਹੁੰਦਾ ਹੈ। ਹੱਲ ਹੁੰਦਾ ਨਾਮ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਰਿਕਾਰਡ ਜਵਾਬ ਦਿੰਦਾ ਹੈ; ਟਰਾਂਸਪੋਰਟ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਵੱਖਰੇ ਹਨ, ਅਤੇ ਐਂਡਪੌਇੰਟ ਨੂੰ ping ਦਾ ਜਵਾਬ ਦੇਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ। ਵਿਚਕਾਰਲੀ ਚੀਜ਼ ਲਈ ਕਲਾਇੰਟ ਦਾ ਆਪਣਾ ਲੌਗ ਹੀ ਇੱਕੋ ਸਰੋਤ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਕੋਸ਼ਿਸ਼ ਦੌਰਾਨ ਕੈਪਚਰ ਕਰੋ, ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ।
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
ਅੱਜ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਪਤਾ ਅੱਜ ਬਾਰੇ ਸਬੂਤ ਹੈ; ਨਾਮ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜਿਸਨੂੰ ਸੇਵਾ ਵੈਧ ਰੱਖਦੀ ਹੈ। ਨਿਰੀਖਣ ਨੋਟ ਕਰੋ, ਐਂਡਪੌਇੰਟ ਦੇ ਮਾਲਕ ਨੂੰ ਭੇਜੋ, ਅਤੇ ਪਰੋਫਾਈਲ ਨੂੰ ਨਾਮ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਰੱਖੋ।
ਛੱਡਣ ਯੋਗ ਦੋ ਆਦਤਾਂ: ਰੁਕੇ ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਲੰਘਣ ਲਈ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਬੰਦ ਕਰਨਾ, ਅਤੇ ਇੱਕ ਚਿੰਬੜ ਜਾਵੇਗੀ ਦੀ ਆਸ ਨਾਲ ਐਂਡਪੌਇੰਟ ਨਾਮ ਅੱਗੇ ਲੇਬਲ ਢੇਰ ਕਰਨਾ। ਲੇਬਲ ਵਾਈਲਡਕਾਰਡ ਰਿਕਾਰਡ ਰਾਹੀਂ ਹੱਲ ਹੁੰਦਾ ਹੈ ਜਾਂ ਸਮੱਸਿਆ ਹੋਰ ਕਿਤੇ ਹੈ। ਸਹੀ ਢੰਗ ਨਾਲ ਕਨਫਿਗਰ ਕੀਤੀ ਪਰੋਫਾਈਲ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ ਤਾਂ ਲੰਮਾ ਹੋਸਟਨਾਮ ਨਹੀਂ, ਸਹੀ ਕਵੈਰੀ ਅਤੇ ਕਨੈਕਸ਼ਨ ਘਟਨਾ ਭੇਜੋ।
ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ: ਪਰੋਫਾਈਲ ਵਿੱਚ ਅਜੇ ਵੀ ਐਕਸਪੋਰਟ ਕੀਤਾ ਐਂਡਪੌਇੰਟ ਨਾਮ ਹੈ, ਕੋਈ hosts ਫਾਈਲ ਪਤਾ ਪਿੰਨ ਨਹੀਂ ਕਰਦੀ, ਕਲਾਇੰਟ ਲੌਗ ਦਾ remote ਮੌਜੂਦਾ ਹੱਲ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਪਤੇ ਦੀ ਬਜਾਏ ਐਂਡਪੌਇੰਟ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ। ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਸੌਂਪਣ ਦੀ ਸਥਿਤੀ ਵੀ ਇਹੀ ਹੈ।