ਸਥਾਨਕ ਡੇਟਾਬੇਸ ਕਲਾਇੰਟ ਅਤੇ ਨਿੱਜੀ RDS: ਕਨੈਕਸ਼ਨ ਦਾ ਸਮਾਂ ਕਿਉਂ ਖਤਮ ਹੁੰਦਾ ਹੈ

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

ਅਸਫਲਤਾ ਨੂੰ ਸਹੀ ਪਰਤ ਉੱਤੇ ਪੜ੍ਹੋ

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

dig +short db.internal.example
nc -vz db.internal.example 5432

ਜੇ ਨਾਮ ਜਨਤਕ ਪਤਾ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਕੁਝ ਵੀ ਨਹੀਂ ਦਿੰਦਾ, ਤਾਂ ਟਨਲ ਅਜੇ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ।

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

ਟਨਲ ਨੂੰ ਰੂਟ ਤੋਂ ਵੱਖ ਕਰੋ

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

ip route get 10.20.40.15
ip addr show tun0

ਟਨਲ ਇੰਟਰਫੇਸ ਵੱਲ ਦਿਸਦਾ ਰੂਟ ਜ਼ਰੂਰੀ ਹੈ; ਉਹ ਕਾਫੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਦੂਜੇ ਪਾਸੇ ਨੂੰ ਅਜੇ ਵੀ ਟ੍ਰੈਫਿਕ ਸਵੀਕਾਰ ਕਰਨਾ ਹੈ।

ਸਪਲਿਟ-ਟਨਲ ਪ੍ਰੋਫਾਈਲ ਇਸ ਅੱਧੀ ਅਸਫਲਤਾ ਦਾ ਆਮ ਸਰੋਤ ਹਨ। ਉਹ ਉਸ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਿਸ ਲਈ ਪ੍ਰੋਫਾਈਲ ਬਣੀ ਸੀ ਅਤੇ ਡੇਟਾਬੇਸ ਦੀ ਰੇਂਜ ਨੂੰ ਟਨਲ ਤੋਂ ਬਾਹਰ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ, ਜੋ ਫਾਇਰਵਾਲ ਵੱਲੋਂ ਪੈਦਾ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਉਹੀ ਸਮਾਂ-ਸਮਾਪਤੀ ਪੈਦਾ ਕਰਦੀ ਹੈ।

ਸੁਰੱਖਿਆ ਗਰੁੱਪ ਨੂੰ ਅਸਲ ਸਰੋਤ ਨਾਲ ਮਿਲਾਓ

RDS ਸੁਰੱਖਿਆ ਗਰੁੱਪ ਲੋਕਾਂ ਨੂੰ ਨਹੀਂ, ਸਰੋਤਾਂ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ। ਆਰਕੀਟੈਕਚਰ ਅਨੁਸਾਰ ਸਰੋਤ VPN ਕਲਾਇੰਟ ਪੂਲ, ਬੈਸਟੀਅਨ ਦਾ ਨਿੱਜੀ ਪਤਾ, ਜਾਂ ਉਹ NAT ਪਤਾ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਦਾ ਅਨੁਵਾਦ ਹੁੰਦਾ ਹੈ। ਨਿਯਮ ਅਤੇ ਪੈਕੇਟ ਦਾ ਅਸਲ ਸਰੋਤ ਇਕੱਠੇ ਪੜ੍ਹੋ।

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

ਇੱਕ ਲੈਪਟਾਪ ਦੇ ਘਰ ਦੇ ਪਤੇ ਲਈ ਨਿਯਮ ਐਕਸੈਸ ਡਿਜ਼ਾਈਨ ਨਹੀਂ, ਸੰਭਾਲ ਦੀ ਸਮੱਸਿਆ ਹੈ।

ਜਦੋਂ ਰਾਹ ਵਿੱਚ ਕਲਾਇੰਟ VPN ਜਾਂ NAT ਗੇਟਵੇ ਹੋਵੇ, ਤਾਂ ਡੇਟਾਬੇਸ ਡਿਵੈਲਪਰ ਦੇ ਟਨਲ ਪਤੇ ਦੀ ਥਾਂ ਅਨੁਵਾਦਕ ਦਾ ਪਤਾ ਦੇਖ ਸਕਦਾ ਹੈ। ਇਸੇ ਲਈ ਕੰਮ ਕਰਦੇ ਬੈਸਟੀਅਨ ਸੈਟਅਪ ਤੋਂ ਕਾਪੀ ਕੀਤਾ ਨਿਯਮ ਲੈਪਟਾਪ ਲਈ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ: ਦੋਵੇਂ ਰਾਹ ਵੱਖਰੇ ਸਰੋਤਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਭਾਵੇਂ ਦੋਵੇਂ ਅੰਦਰੂਨੀ ਦਿਸਦੇ ਹਨ।

ਚੌੜੇ ਰਾਹ ਤੋਂ ਤੰਗ ਰਾਹ ਨੂੰ ਤਰਜੀਹ ਦਿਓ

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

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

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

ਪੂਰੀ ਟਨਲ ਅਤੇ ਤੰਗ ਫਾਰਵਰਡਿੰਗ ਵਿਚਕਾਰ ਚੋਣ ਸੁਰੱਖਿਆ-ਨਾਟਕ ਨਹੀਂ, ਦਾਇਰੇ ਦਾ ਫੈਸਲਾ ਹੈ।

ਪਿੱਛੇ ਦੁਹਰਾਉਣ ਯੋਗ ਰਾਹ ਛੱਡੋ

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

ਫਿਰ ਨਕਾਰਾਤਮਕ ਕੇਸ ਇੱਕ ਵਾਰ ਜਾਂਚੋ: ਮਨਜ਼ੂਰ ਸਰੋਤ ਤੋਂ ਬਾਹਰਲਾ ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਇਨਕਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

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