AWS Client VPN ਜੁੜਿਆ ਹੈ, ਪਰ EC2 ਅਜੇ ਵੀ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ
ਜੁੜਿਆ ਦਾ ਮਤਲਬ ਸਿਰਫ਼ ਇਹ ਹੈ ਕਿ ਸਰਟੀਫਿਕੇਟ ਜਾਂ SAML ਲੌਗਇਨ ਚੱਲਿਆ। ਅਧਿਕਾਰ ਨਿਯਮ, endpoint ਰੂਟ ਅਤੇ ਸੁਰੱਖਿਆ ਗਰੁੱਪ ਹਰ ਇੱਕ ਨਿੱਜੀ ਹੋਸਟ ਤੱਕ ਦੇ ਰਾਹ ਦਾ ਇੱਕ ਹਿੱਸਾ ਪਹਿਰੇਦਾਰੀ ਕਰਦਾ ਹੈ।
ਮੇਰੇ ਲੈਪਟਾਪ ਨੇ ਜੁੜਿਆ ਦਿਖਾਇਆ। AWS Client VPN ਕਲਾਇੰਟ ਨੇ ਆਪਣੀ ਹਰੀ ਸਥਿਤੀ ਦਿਖਾਈ, endpoint ਨੇ ਸੈਸ਼ਨ ਦਰਜ ਕੀਤਾ, ਅਤੇ ਫਿਰ ਵੀ ਮੈਂ ਨਿੱਜੀ ਸਬਨੈੱਟ ਵਿੱਚ EC2 ਇੰਸਟੈਂਸ ਉੱਤੇ MongoDB ਪੋਰਟ ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਿਆ। ਸਪਸ਼ਟ ਤੌਰ ਉੱਤੇ ਕੁਝ ਵੀ ਟੁੱਟਿਆ ਨਹੀਂ ਸੀ: ਸਰਟੀਫਿਕੇਟ ਵੈਧ ਸੀ, ਪਰੋਫਾਈਲ ਕਨਸੋਲ ਤੋਂ ਆਇਆ ਸੀ, ਅਤੇ ਟਨਲ ਟ੍ਰੈਫਿਕ ਢੋ ਰਹੀ ਸੀ। ਗਲਤੀ ਮੇਰੀ ਸੀ, ਕਿਉਂਕਿ ਮੈਂ ਜੁੜਿਆ ਨੂੰ ਅਧਿਕਾਰਤ ਵਜੋਂ ਪੜ੍ਹ ਰਿਹਾ ਸੀ।
ਲੌਗਇਨ ਠੀਕ ਇੱਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਕੀ ਇਹ ਪਛਾਣ ਸੈਸ਼ਨ ਸਥਾਪਿਤ ਕਰ ਸਕਦੀ ਹੈ? ਇਸ ਤੋਂ ਬਾਅਦ ਦਾ ਸਭ ਕੁਝ ਵੱਖਰੇ ਨਿਯਮ ਤੈਅ ਕਰਦੇ ਹਨ, ਜੋ ਤੁਹਾਡਾ ਸਰਟੀਫਿਕੇਟ ਕਦੇ ਨਹੀਂ ਦੇਖਦੇ। ਜੋ ਸੈਸ਼ਨ ਪ੍ਰਮਾਣੀਕਰਨ ਪਾਸ ਕਰਦਾ ਹੈ ਅਤੇ ਜੋ ਪੈਕਟ ਪਹੁੰਚਦਾ ਹੈ, ਉਹ ਦੋ ਵੱਖਰੀਆਂ ਸਫਲਤਾਵਾਂ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰਲਾ ਪਾੜਾ ਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ VPN ਚਾਲੂ ਹੈ ਪਰ ਹੋਸਟ ਪਹੁੰਚ ਵਿੱਚ ਨਹੀਂ ਵਰਗੀਆਂ ਬਹੁਤੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਰਹਿੰਦੀਆਂ ਹਨ।
ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਉਹੀ ਕ੍ਰਮ ਹਨ ਜੋ ਮੈਂ ਹੁਣ ਵਰਤਦਾ ਹਾਂ।
ਜੁੜਿਆ ਸੈਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ
ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ endpoint ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਆਪਣੇ trust store ਦੇ ਸਾਹਮਣੇ ਜਾਂਚਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ SAML ਸੰਰਚਿਤ ਹੋਵੇ ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਤੁਹਾਡੇ ਪਛਾਣ ਪ੍ਰਦਾਤਾ ਕੋਲ ਭੇਜਦਾ ਹੈ। ਜੇ ਉਹ ਪਾਸ ਹੋ ਜਾਵੇ, ਤਾਂ ਕਲਾਇੰਟ ਨੂੰ endpoint ਦੇ ਕਲਾਇੰਟ CIDR ਤੋਂ ਪਤਾ ਮਿਲਦਾ ਹੈ ਅਤੇ ਕਨਸੋਲ ਸਰਗਰਮ ਕਨੈਕਸ਼ਨ ਦਿਖਾਉਂਦਾ ਹੈ। ਉਸ ਅਦਲਾ-ਬਦਲੀ ਵਿੱਚ ਕਦੇ ਵੀ ਕੋਈ ਨਹੀਂ ਪੁੱਛਦਾ ਕਿ ਤੁਸੀਂ 10.0.4.17 ਤੱਕ ਪੋਰਟ 27017 ਉੱਤੇ ਪਹੁੰਚ ਸਕਦੇ ਹੋ ਜਾਂ ਨਹੀਂ।
ਕਿਸੇ ਮੰਜ਼ਿਲ ਲਈ ਇਜਾਜ਼ਤ endpoint ਉੱਤੇ ਇੱਕ ਵੱਖਰੀ ਵਸਤੂ ਹੈ। ਹਰ ਫਲੋ ਨੂੰ ਅਧਿਕਾਰ ਨਿਯਮਾਂ ਨਾਲ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਹਰ ਨਿਯਮ ਮੰਜ਼ਿਲ CIDR ਨੂੰ ਉਸ ਗਰੁੱਪ ਨਾਲ ਜੋੜਦਾ ਹੈ ਜਿਸ ਨੂੰ ਨਿਯਮ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਜਦੋਂ ਕੋਈ ਨਿਯਮ ਮੰਜ਼ਿਲ ਨੂੰ ਨਹੀਂ ਢਕਦਾ, endpoint ਸੈਸ਼ਨ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦਾ ਹੈ ਅਤੇ ਟ੍ਰੈਫਿਕ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। ਕੋਈ ਬੈਨਰ ਨਹੀਂ, ਕੋਈ ਮੁੜ-ਕਨੈਕਟ ਲੂਪ ਨਹੀਂ, ਅਤੇ ਕਲਾਇੰਟ UI ਵਿੱਚ ਕੁਝ ਵੀ ਨਹੀਂ ਜੋ ਰੱਦ ਕੀਤਾ ਕਹੇ।
ਅਧਿਕਾਰ ਨਿਯਮ ਦੀ ਤੁਲਨਾ VPC ਨਾਲ ਨਹੀਂ, ਸਰੋਤ ਨਾਲ ਕਰੋ
ਨਿਯਮਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਉਸ ਪਤੇ ਦੇ ਕੋਲ ਰੱਖੋ ਜੋ ਇੰਸਟੈਂਸ ਕੋਲ ਅਸਲ ਵਿੱਚ ਹੈ:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8ਆਉਟਪੁੱਟ ਹਰ ਨਿਯਮ ਲਈ ਮੰਜ਼ਿਲ CIDR ਅਤੇ ਗਰੁੱਪ ID ਦਿਖਾਉਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਦੋ ਅਸਫਲਤਾਵਾਂ ਲੁਕੀਆਂ ਹੋਈਆਂ ਹਨ। ਨਿਯਮ 10.0.0.0/16 ਨੂੰ ਅਧਿਕਾਰ ਦੇ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇੰਸਟੈਂਸ 10.1.0.0/16 ਉੱਤੇ ਪੀਅਰ ਕੀਤੇ VPC ਵਿੱਚ ਬੈਠਾ ਹੈ; ਪੀਅਰਿੰਗ ਰੂਟ ਮੌਜੂਦ ਹੈ, ਪਰ ਕਿਸੇ ਨੇ ਦੂਜੀ ਰੇਂਜ ਲਈ ਅਧਿਕਾਰ ਨਿਯਮ ਨਹੀਂ ਲਿਖਿਆ। ਜਾਂ ਨਿਯਮ ਅਜਿਹੇ ਡਾਇਰੈਕਟਰੀ ਗਰੁੱਪ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਵਰਤੋਂਕਾਰ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹੈ ਪਰ ਉਸ ਗਰੁੱਪ ਵਿੱਚ ਨਹੀਂ ਜਿਸ ਦਾ endpoint ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ।
ਮੰਜ਼ਿਲ ਨੂੰ ਢਕਣ ਵਾਲਾ ਸਭ ਤੋਂ ਤੰਗ ਨਿਯਮ ਲਿਖੋ, ਅਤੇ ਦੂਜਾ ਨਿਯਮ ਤਦ ਹੀ ਜੋੜੋ ਜਦੋਂ ਦੂਜਾ CIDR ਸੱਚਮੁੱਚ ਲੋੜੀਂਦਾ ਹੋਵੇ। ਤੇਜ਼ ਸ਼ੁਰੂਆਤ ਤੋਂ ਆਇਆ ਚੌੜਾ 0.0.0.0/0 ਨਿਯਮ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਉਹ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਜੀਵਿਤ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ਲੁਕਾਉਂਦਾ ਹੈ।
ਦੋ ਰੂਟ ਟੇਬਲ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਪੈਕਟ ਅੱਗੇ ਵਧੇਗਾ ਜਾਂ ਨਹੀਂ
endpoint ਰੂਟ ਮੰਜ਼ਿਲ CIDR ਨੂੰ ਉਨ੍ਹਾਂ ਸਬਨੈੱਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਉੱਤੇ ਮੈਪ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ endpoint ਜੁੜਿਆ ਹੈ। ਇਹ ਅੱਧਾ ਰਾਹ ਹੈ। ਸਬਨੈੱਟ ਦੀ ਆਪਣੀ ਰੂਟ ਟੇਬਲ ਨੂੰ ਅਜੇ ਵੀ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਪੈਕਟ ਕਿਵੇਂ ਅੱਗੇ ਭੇਜਣਾ ਹੈ, ਅਤੇ ਇਹ ਉਸ ਪਲ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਮੰਜ਼ਿਲ ਪੀਅਰਿੰਗ ਕਨੈਕਸ਼ਨ, ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਜਾਂ ਸਾਈਟ-ਟੂ-ਸਾਈਟ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਆਨ-ਪ੍ਰੀਮਾਈਜ਼ਿਜ਼ ਰੇਂਜ ਦੇ ਪਿੱਛੇ ਹੋਵੇ।
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8ਅਜਿਹਾ ਰੂਟ ਲੱਭੋ ਜਿਸ ਦੀ ਮੰਜ਼ਿਲ ਸਰੋਤ ਦੇ CIDR ਨਾਲ ਮਿਲਦੀ ਹੈ ਅਤੇ ਜਿਸ ਦਾ ਟਾਰਗਟ ਜੁੜਿਆ ਸਬਨੈੱਟ ਹੈ। ਜੇ ਰੂਟ ਨਹੀਂ ਹੈ ਤਾਂ ਜੋੜੋ। ਜੇ ਹੈ ਅਤੇ ਹੋਸਟ ਅਜੇ ਵੀ ਚੁੱਪ ਹੈ, ਤਾਂ ਪਾੜਾ VPC ਵੱਲ ਹੈ, ਇਸ ਲਈ ਸੰਬੰਧਿਤ ਸਬਨੈੱਟ ਦੀ ਰੂਟ ਟੇਬਲ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
ਕਲਾਇੰਟ ਵੱਲ ਦੀ ਇੱਕ ਸੈਟਿੰਗ ਟਨਲ ਤੋੜੇ ਬਿਨਾਂ ਰਾਊਟਿੰਗ ਤੋੜ ਦਿੰਦੀ ਹੈ: route-nopull ਵਾਲੀ ਪਰੋਫਾਈਲ। ਇਹ ਹਦਾਇਤ OpenVPN ਅਧਾਰਿਤ ਕਲਾਇੰਟ ਨੂੰ ਸਰਵਰ ਵੱਲੋਂ ਧੱਕੇ ਜਾਂਦੇ ਰੂਟਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਲਈ ਕਹਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਇੰਟਰਫੇਸ ਸਿਰਫ਼ endpoint ਦੇ ਆਪਣੇ ਪਤੇ ਨਾਲ ਉੱਠਦਾ ਹੈ ਅਤੇ ਮੰਜ਼ਿਲ ਦਾ ਕੋਈ ਰੂਟ ਹੀ ਨਹੀਂ ਹੁੰਦਾ। Linux ਉੱਤੇ ip route show ਜਾਂ macOS ਉੱਤੇ netstat -rn ਨਾਲ ਜਾਂਚੋ ਕਿ tun ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਰੂਟ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇ ਨਹੀਂ, ਤਾਂ ਐਕਸਪੋਰਟ ਕੀਤੀ ਪਰੋਫਾਈਲ ਵਿੱਚੋਂ route-nopull ਹਟਾਓ ਅਤੇ ਮੁੜ ਕਨੈਕਟ ਕਰੋ ਤਾਂ ਜੋ ਧੱਕੇ ਗਏ ਰੂਟ ਲਾਗੂ ਹੋਣ।
ਸੁਰੱਖਿਆ ਗਰੁੱਪ ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਪਤਾ ਨਹੀਂ ਦੇਖਦੇ
ਇਹ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਮੈਂ ਅੱਧਾ ਦਿਨ ਗਲਤ ਰੱਖਿਆ। ਸਬਨੈੱਟ ਨਾਲ ਜੁੜੇ IPv4 endpoint ਲਈ, ਸੇਵਾ ਕਲਾਇੰਟ ਦੇ ਸਰੋਤ ਪਤੇ ਦਾ ਅਨੁਵਾਦ ਉਸ ਸਬਨੈੱਟ ਵਿੱਚ endpoint ਦੇ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਦੇ ਪਤੇ ਵਿੱਚ ਕਰਦੀ ਹੈ। ਇੰਸਟੈਂਸ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲਾ ਪੈਕਟ ਉਹ ਪਤਾ ਨਹੀਂ ਢੋਂਦਾ ਜੋ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਨੇ ਦਿਖਾਇਆ ਸੀ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਪੂਲ, ਮੰਨ ਲਓ 172.16.0.0/22, ਨੂੰ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਸੁਰੱਖਿਆ ਗਰੁੱਪ ਨਿਯਮ ਕਿਸੇ ਚੀਜ਼ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ।
ਪੋਰਟ ਨੂੰ ਕਲਾਇੰਟ CIDR ਤੋਂ ਨਹੀਂ, endpoint ਦੇ ਸੁਰੱਖਿਆ ਗਰੁੱਪ ਤੋਂ ਇਜਾਜ਼ਤ ਦਿਓ, ਜੋ ਸੰਬੰਧ ਦੇ ਇੰਟਰਫੇਸ ਨਾਲ ਜੁੜਿਆ ਹੈ। ਗਰੁੱਪ ਦਾ ਹਵਾਲਾ ਦੇਣਾ ਪਤਾ ਹਾਰਡਕੋਡ ਕਰਨ ਨਾਲੋਂ ਲੰਮਾ ਚੱਲਦਾ ਹੈ, ਕਿਉਂਕਿ ਇੰਟਰਫੇਸ ਦਾ ਪਤਾ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਵਿੱਚ ਨਹੀਂ। ਨੈੱਟਵਰਕ ACL ਸਟੇਟਲੈੱਸ ਹਨ, ਇਸ ਲਈ ਜਿੱਥੇ ਕਸਟਮ ਐਂਟਰੀਆਂ ਹਨ ਉੱਥੇ ਆਉਣ ਅਤੇ ਜਾਣ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਨੂੰ ਫਲੋ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣੀ ਪਵੇਗੀ।
ਇੰਸਟੈਂਸ ਦੇ ਨਿੱਜੀ ਪਤੇ ਨਾਲ ਵੀ ਕਨੈਕਟ ਕਰੋ। ਜਨਤਕ IP ਪੈਕਟ ਨੂੰ VPC ਤੋਂ ਬਾਹਰ ਲੈ ਜਾਂਦਾ ਹੈ ਅਤੇ ਹੋਰ ਨਿਯਮਾਂ ਵਾਲੇ ਹੋਰ ਰਾਹੀਂ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਜਨਤਕ ਪਤੇ ਉੱਤੇ ਕੀਤੀ ਜਾਂਚ ਨਿੱਜੀ ਰਾਹ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ।
ਪਹਿਲੀ ਅਸਫਲਤਾ ਉੱਤੇ ਰੁਕਣ ਵਾਲਾ ਅਲੱਗਾਉਣ ਕ੍ਰਮ
ਇਨ੍ਹਾਂ ਨੂੰ ਕ੍ਰਮ ਨਾਲ ਕਰੋ ਅਤੇ ਜਿੱਥੇ ਇੱਕ ਅਸਫਲ ਹੋਵੇ ਉੱਥੇ ਰੁਕੋ। ਹਰ ਕਦਮ ਸਾਰੀਆਂ ਪਰਤਾਂ ਨਹੀਂ, ਇੱਕ ਪਰਤ ਹਟਾਉਂਦਾ ਹੈ।
- ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੈਸ਼ਨ ਨੇ ਕਿਹੜੀ ਪਛਾਣ ਵਰਤੀ ਅਤੇ endpoint ਕਿਹੜੇ ਗਰੁੱਪ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ। ਇੱਕ trust store ਦਾ ਸਰਟੀਫਿਕੇਟ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਆਏ SAML ਦਾਅਵੇ ਵਾਂਗ ਇੱਕੋ ਪ੍ਰਿੰਸੀਪਲ ਨਹੀਂ ਹੈ।
- ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਅਧਿਕਾਰ ਨਿਯਮ ਉਸ ਗਰੁੱਪ ਲਈ ਸਰੋਤ ਦਾ CIDR ਢਕਦਾ ਹੈ।
- ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ endpoint ਰੂਟ ਮੌਜੂਦ ਹੈ ਅਤੇ ਜੁੜੇ ਸਬਨੈੱਟ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ, ਫਿਰ ਕਿ ਸਬਨੈੱਟ ਦੀ ਰੂਟ ਟੇਬਲ ਅੱਗੇ ਭੇਜ ਸਕਦੀ ਹੈ।
- ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੁਰੱਖਿਆ ਗਰੁੱਪ ਪੋਰਟ ਨੂੰ ਕਲਾਇੰਟ ਪੂਲ ਤੋਂ ਨਹੀਂ, endpoint ਇੰਟਰਫੇਸ ਤੋਂ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।
- ਐਪਲੀਕੇਸ਼ਨ ਸਮੱਸਿਆ ਨੂੰ ਕਲਾਇੰਟ ਰਾਹ ਦੀ ਸਮੱਸਿਆ ਤੋਂ ਵੱਖ ਕਰਨ ਲਈ VPC ਦੇ ਅੰਦਰੋਂ, ਉਸੇ ਸਬਨੈੱਟ ਦੇ ਕਿਸੇ ਹੋਰ ਇੰਸਟੈਂਸ ਉੱਤੇ SSM ਸੈਸ਼ਨ ਨਾਲ ਜਾਂਚ ਕਰੋ।
ਜਦੋਂ ਕਦਮ ਨਿਰਣਾਇਕ ਨਾ ਹੋਣ, ਤਾਂ ਮੈਂ ਇਸ ਟੇਬਲ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹਾਂ:
| Symptom | Layer to inspect |
|---|---|
| Client shows connected, host times out, no byte growth on the interface | Authorization rule, then security group |
| Ping fails but a TCP connect to the port succeeds | ICMP is blocked; not an access failure |
| Tunnel reconnects every few minutes | Two machines sharing one client certificate |
| Works on one laptop, fails on another | Local profile has route-nopull or stale pushed routes |
ਖਾਤੇ ਦੀਆਂ ਦੋ ਵਿਸਤਾਰਾਂ ਅਜਿਹੇ ਲੱਛਣ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ ਜੋ ਇਜਾਜ਼ਤ ਅਸਫਲਤਾ ਵਰਗੇ ਲੱਗਦੇ ਹਨ। ਹਰ ਵਰਤੋਂਕਾਰ ਨੂੰ ਵੱਖਰਾ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਚਾਹੀਦਾ ਹੈ; ਇੱਕ ਨੂੰ ਦੋ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਵੰਡਣ ਨਾਲ ਸੈਸ਼ਨ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਧੱਕਦੇ ਹਨ, ਅਤੇ ਨਤੀਜਾ ਇਨਕਾਰ ਨਹੀਂ ਸਗੋਂ ਮੁੜ-ਕਨੈਕਟ ਲੂਪ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਨਵਾਂ endpoint ਬਣਦਾ ਹੈ, ਕਨਸੋਲ ਇੱਕ DNS ਨਾਮ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕੁਝ ਕਲਾਇੰਟ ਸੰਸਕਰਣ ਸਿਰਫ਼ endpoint ਸਫ਼ੇ ਉੱਤੇ ਦਿਖਾਏ ਬੇਤਰਤੀਬ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਹੀ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਨਾਮ ਮੁੜ ਬਣਾਉਣ ਦੀ ਥਾਂ ਪੂਰਾ ਨਾਮ ਕਾਪੀ ਕਰੋ।
ਜੇ ਪੰਜਵਾਂ ਕਦਮ ਤੁਹਾਨੂੰ ਰੋਕਦਾ ਹੈ, ਤਾਂ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ endpoint ਦਾ ਕਨੈਕਸ਼ਨ ਲੌਗ ਕੱਢੋ ਅਤੇ ਅਧਿਕਾਰ ਐਂਟਰੀਆਂ ਪੜ੍ਹੋ। ਲੌਗ ਉਹ ਮੰਜ਼ਿਲ ਦੱਸਦਾ ਹੈ ਜਿਸ ਦੀ ਜਾਂਚ ਹੋਈ ਅਤੇ ਉਹ ਨਿਯਮ ਜੋ ਮਿਲਿਆ ਜਾਂ ਨਹੀਂ ਮਿਲਿਆ, ਅਤੇ ਇਹ ਚਾਰ ਪਰਤਾਂ ਵਾਲੇ ਸਵਾਲ ਨੂੰ ਇੱਕ ਜਵਾਬ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।