ਕਲਾਉਡ ਸੀਮਾ ਉੱਤੇ VPN ਕਲਾਇੰਟ ਦੇ IP ਸੰਭਾਲੋ ਜਾਂ SNAT ਕਰੋ
ਸਰੋਤ ਸੰਭਾਲਣ ਨਾਲ ਹਰ ਲੌਗ ਵਿੱਚ ਕਲਾਇੰਟ ਦੀ ਪਛਾਣ ਰਹਿੰਦੀ ਹੈ, SNAT ਰਾਊਟਿੰਗ ਟੇਬਲ ਛੋਟਾ ਰੱਖਦਾ ਹੈ। ਤਿੰਨ ਸ਼ਰਤਾਂ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਿਹੜੀ ਚਾਹੀਦੀ ਹੈ।
VPN ਕਲਾਇੰਟ ਦਾ ਪਤਾ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਰੱਖਣ ਨਾਲ ਹਰ ਲੌਗ ਲਾਈਨ ਅਤੇ ਮਨਜ਼ੂਰੀ ਸੂਚੀ ਦੀ ਹਰ ਐਂਟਰੀ ਦਾ ਇੱਕੋ ਅਰਥ ਹੁੰਦਾ ਹੈ। ਕਲਾਉਡ ਕਿਨਾਰੇ ਉੱਤੇ ਇਸਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਨਾਲ ਰਾਊਟਿੰਗ ਟੇਬਲ ਸਰਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਲੌਗ ਘੱਟ ਲਾਭਦਾਇਕ ਰਹਿੰਦੇ ਹਨ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਚੋਣ ਆਪਣੇ ਆਪ ਵਿੱਚ ਗਲਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਤੈਅ ਕਰਨ ਵਾਲੀ ਦਲੀਲ ਘੱਟ ਹੀ ਪ੍ਰਦਰਸ਼ਨ ਬਾਰੇ ਹੁੰਦੀ ਹੈ। ਤਿੰਨ ਸ਼ਰਤਾਂ ਇਹ ਤੈਅ ਕਰਦੀਆਂ ਹਨ: ਕੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਜਾਣਨਾ ਹੈ ਕਿ ਕਿਹੜਾ ਇਨਸਾਨ ਜੁੜਿਆ, ਕੀ ਕਲਾਉਡ ਫੈਬਰਿਕ ਉਹ ਸਰੋਤ ਸਵੀਕਾਰ ਕਰੇਗਾ ਜੋ ਤੁਸੀਂ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਵਾਪਸੀ ਮਾਰਗ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਕੌਣ ਲਵੇਗਾ।
ਤਿੰਨ ਸ਼ਰਤਾਂ ਇਹ ਤੈਅ ਕਰਦੀਆਂ ਹਨ
ਨੈੱਟਵਰਕ ਡਾਇਗ੍ਰਾਮ ਨਾਲ ਨਹੀਂ, ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਲੋੜ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਅਧਿਕਾਰ ਜਾਂ ਆਡਿਟ ਵਿਅਕਤੀਗਤ ਕਲਾਇੰਟ ਪਤੇ ਉੱਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਸੰਭਾਲਣਾ ਕਾਰਜਸ਼ੀਲ ਲੋੜ ਹੈ ਅਤੇ ਅਨੁਵਾਦ ਕਰਨਾ ਇੱਕ ਗਿਰਾਵਟ ਹੈ। ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਿਰਫ਼ ਇਹ ਜਾਣਨਾ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਦੂਰਸਥ ਪਹੁੰਚ ਮਾਰਗ ਰਾਹੀਂ ਆਇਆ, ਤਾਂ ਅਨੁਵਾਦਿਤ ਪਤਾ ਕਾਫ਼ੀ ਹੈ ਅਤੇ ਚਲਾਉਣ ਲਈ ਕਾਫ਼ੀ ਸਸਤਾ ਹੈ।
ਦੂਜੀ ਸ਼ਰਤ ਯੰਤਰਿਕ ਹੈ। ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਉਸ ਪੈਕੇਟ ਉੱਤੇ ਆਪਣੇ ਆਪ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ ਜੋ ਅਜਿਹੇ ਪਤੇ ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ ਜੋ ਭੇਜਣ ਵਾਲੇ ਇੰਟਰਫ਼ੇਸ ਨੂੰ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ। ਜ਼ਿਆਦਾਤਰ ਕਲਾਉਡ ਫੈਬਰਿਕ ਇਸਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਅਤੇ ਨਾਵਾਂ ਨਾਲ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਸਨੂੰ ਅਣਡਿੱਠਾ ਕਰਨ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਡਾਇਗ੍ਰਾਮ ਵਿੱਚ ਸਹੀ ਦਿਸੇਗਾ ਅਤੇ ਉਤਪਾਦਨ ਵਿੱਚ ਚੁੱਪਚਾਪ ਡਿੱਗ ਜਾਵੇਗਾ।
ਤੀਜੀ ਸੰਗਠਨਾਤਮਕ ਹੈ। ਸਰੋਤ ਸੰਭਾਲਣ ਦਾ ਅਰਥ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸਬਨੈੱਟ ਦੀ ਰਾਊਟਿੰਗ ਟੇਬਲ ਨੂੰ ਕਲਾਇੰਟ ਪ੍ਰੀਫਿਕਸ ਲਈ ਗੇਟਵੇ ਵੱਲ ਵਾਪਸ ਦਿਖਾਉਣਾ ਪਵੇਗਾ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸਬਨੈੱਟ ਜੋੜਨ ਵਾਲੀ ਹਰ ਟੀਮ ਨੂੰ ਉਹ ਮਾਰਗ ਇਕਸਾਰ ਰੱਖਣਾ ਪਵੇਗਾ। ਇਹ ਇੱਕ ਵਾਰ ਦਾ ਛੋਟਾ ਖਰਚ ਹੈ ਅਤੇ ਦਰਜਨਾਂ ਖਾਤਿਆਂ ਵਿੱਚ ਦੁਹਰਾਉਣ ਵਾਲਾ ਖਰਚ ਹੈ। ਇਸ ਵਿਵਹਾਰ ਦਾ ਵਾਅਦਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਇਹ ਕੌਣ ਭਰੇਗਾ।
ਮਾਰਗ ਨਕਲੀ ਬਣਾਉਣ ਦੀ ਮਨਜ਼ੂਰੀ ਨਹੀਂ ਹੈ
ਵਾਪਸੀ ਮਾਰਗ ਜੋੜਨ ਨਾਲ ਤੁਹਾਡੇ ਸਬਨੈੱਟ ਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਜਵਾਬ ਕਿੱਥੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਹ ਫੈਬਰਿਕ ਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਉਹ ਪੈਕੇਟ ਅੱਗੇ ਭੇਜਣ ਵਾਲੇ ਇੰਸਟੈਂਸ ਨੂੰ ਉਹ ਵਿਦੇਸ਼ੀ ਸਰੋਤ ਨਾਲ ਭੇਜਣ ਦਾ ਅਧਿਕਾਰ ਹੈ। AWS ਵਿੱਚ ਸੰਬੰਧਿਤ ਨਿਯੰਤਰਣ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਜਾਂਚ ਹੈ, ਅਤੇ ਇਹ ਹਰ ਇੰਸਟੈਂਸ ਲਈ ਦਿਸਦੀ ਹੈ:
aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
--query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
--no-source-dest-checkਇਸਨੂੰ ਸਿਰਫ਼ ਉਸ ਇੰਸਟੈਂਸ ਲਈ ਬੰਦ ਕਰੋ ਜਿਸਦਾ ਦਸਤਾਵੇਜ਼ੀ ਕੰਮ ਅੱਗੇ ਭੇਜਣਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਹੋਰ ਲਈ ਨਹੀਂ। ਜਾਂਚ ਚਾਲੂ ਰੱਖਣ ਵਾਲੀ ਹਰ ਐਪਲੀਕੇਸ਼ਨ VM ਇੱਕ ਮਸ਼ੀਨ ਘੱਟ ਹੈ ਜੋ ਉਧਾਰ ਲਏ ਸਰੋਤ ਨਾਲ ਟ੍ਰੈਫਿਕ ਭੇਜਣ ਲਈ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫ਼ਾਰਮ AWS ਨਹੀਂ ਹੈ, ਤਾਂ ਵਿਵਹਾਰ ਦੇ ਤਬਦੀਲ ਹੋਣ ਦੀ ਧਾਰਨਾ ਰੱਖਣ ਦੀ ਥਾਂ ਸਮਾਨ ਐਂਟੀ-ਸਪੂਫਿੰਗ ਜਾਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪਤਾ ਸੈਟਿੰਗ ਲੱਭੋ।
ਤੇਜ਼ ਪੈਕੇਟ ਕੈਪਚਰ ਕੰਸੋਲ ਪੜ੍ਹਨ ਨਾਲੋਂ ਛੇਤੀ ਸਵਾਲ ਤੈਅ ਕਰਦਾ ਹੈ। ਜੇ ਜਵਾਬ ਬਾਹਰ ਚਲੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕਲਾਇੰਟ ਉਨ੍ਹਾਂ ਨੂੰ ਕਦੇ ਨਹੀਂ ਦੇਖਦਾ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਫੇਲ੍ਹ ਨਹੀਂ ਹੋ ਰਹੀ, ਫੈਬਰਿਕ ਨਕਲੀ ਸਰੋਤ ਸੁੱਟ ਰਿਹਾ ਹੈ।
ਅਨੁਵਾਦ ਕੀ ਖਰੀਦਦਾ ਹੈ ਅਤੇ ਕੀ ਖਰਚ ਕਰਾਉਂਦਾ ਹੈ
ਗੇਟਵੇ ਉੱਤੇ ਸਰੋਤ ਦੁਬਾਰਾ ਲਿਖਣ ਨਾਲ ਵਾਪਸੀ ਮਾਰਗ ਦੀ ਸਮੱਸਿਆ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਅਜਿਹਾ ਪਤਾ ਦੇਖਦੀ ਹੈ ਜਿਸ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਤਰੀਕਾ ਉਸਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਕਦੇ ਕਲਾਉਡ ਰਾਊਟ ਟੇਬਲ ਵਿੱਚ ਆਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। Linux ਵਿੱਚ ਨਿਯਮ ਇੱਕ ਲਾਈਨ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਜੋ ਸਭ ਤੋਂ ਸੰਖੇਪ ਸੰਸਕਰਣ ਲਿਖ ਸਕਦੇ ਹੋ ਉਹ ਲਿਖਣਾ ਯੋਗ ਹੈ:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10ਧਿਆਨ ਦਿਓ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਹੁਣ ਕੀ ਦਰਜ ਕਰਦੀ ਹੈ: ਹਰ ਵਰਤੋਂਕਾਰ ਲਈ 10.40.3.10, ਹਰ ਕਨੈਕਸ਼ਨ ਉੱਤੇ, ਹਮੇਸ਼ਾ ਲਈ। ਉਸ ਮੁੱਲ ਉੱਤੇ ਬਣੀ ਕੋਈ ਵੀ ਪਤਾ-ਮਨਜ਼ੂਰੀ ਸੂਚੀ ਹੁਣ ਪੂਰੀ ਦੂਰਸਥ ਪਹੁੰਚ ਅਬਾਦੀ ਨੂੰ ਪਹੁੰਚ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਕਿਸੇ ਵੀ ਘਟਨਾ ਦੀ ਸਮੀਖਿਆ ਨੂੰ ਇਹ ਦੱਸਣ ਲਈ ਕਿ ਇਹ ਕੌਣ ਸੀ, ਗੇਟਵੇ ਵੱਲ ਵਾਪਸ ਜਾਣਾ ਪੈਂਦਾ ਹੈ।
ਹੱਲ ਅਨੁਵਾਦ ਛੱਡਣਾ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਇਹ ਦਿਖਾਵਾ ਕਰਨਾ ਛੱਡਣਾ ਹੈ ਕਿ ਪਤਾ ਹੀ ਪਛਾਣ ਹੈ। ਕਲਾਇੰਟ ਦੀ ਪਛਾਣ ਪ੍ਰਮਾਣਿਤ ਖੇਤਰ ਵਿੱਚ ਰੱਖੋ, ਗੇਟਵੇ ਉੱਤੇ ਅਨੁਵਾਦਿਤ ਟਿਊਪਲ ਨਾਲ ਉਸਨੂੰ ਲੌਗ ਕਰੋ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਉਸ ਉੱਤੇ ਜੁੜਨ ਦਿਓ। ਜੁੜਨ ਕੁੰਜੀ ਤੋਂ ਬਿਨਾਂ, ਅਨੁਵਾਦ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆ ਨੂੰ ਪੱਕੀ ਫੋਰੈਂਸਿਕ ਸਮੱਸਿਆ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਰਿਲੇ ਇੱਕ ਵੱਖਰਾ ਇੰਟਰਫ਼ੇਸ ਹੈ
ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸਾਹਮਣੇ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਰਾਊਟ ਕੀਤੇ ਮਾਰਗ ਦੇ ਸਵਾਲ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਟਾਲ ਦਿੰਦੀ ਹੈ। ਪ੍ਰੌਕਸੀ ਆਪਣਾ ਬੈਕਐਂਡ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦੀ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਅੰਦਰ ਕਦੇ ਰਾਊਟਯੋਗ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੌਕਸੀ ਵੱਲੋਂ ਸੈੱਟ ਕੀਤੇ ਹੈਡਰ ਵਿੱਚ ਪਛਾਣ ਲੈ ਸਕਦੀ ਹੈ।
ਉਹ ਹੈਡਰ ਸਿਰਫ਼ ਤਦ ਭਰੋਸੇਯੋਗ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਬੈਕਐਂਡ ਉਸਨੂੰ ਪ੍ਰੌਕਸੀ ਤੋਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕਿਸੇ ਤੋਂ ਨਹੀਂ। nginx ਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਇਸਦਾ ਅਰਥ ਹੈ ਭਰੋਸੇਯੋਗ ਸਾਥੀ ਦਾ ਨਾਮ ਸਪੱਸ਼ਟ ਰੱਖਣਾ, ਬਜਾਇ ਹਰ ਆਉਣ ਵਾਲੀ ਚੀਜ਼ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਦੇ:
set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;ਕੋਈ ਵੀ ਕਲਾਇੰਟ ਜੋ ਬੈਕਐਂਡ ਤੱਕ ਸਿੱਧਾ ਪਹੁੰਚ ਸਕਦਾ ਹੈ ਉਹੀ ਹੈਡਰ ਨਕਲੀ ਬਣਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਬੈਕਐਂਡ ਪ੍ਰੌਕਸੀ ਤੋਂ ਬਿਨਾਂ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਫਾਇਰਵਾਲ ਦਾ ਤੱਥ ਹੈ, ਸੰਰਚਨਾ ਦੀ ਰਾਏ ਨਹੀਂ, ਅਤੇ ਸਨਿੱਪਟ ਕਾਪੀ ਕਰਦੇ ਸਮੇਂ ਲੋਕ ਇਹੀ ਧਾਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਰਿਲੇ ਇਹ ਵੀ ਬਦਲਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਖਰੀਦ ਰਹੇ ਹੋ। ਤੁਹਾਨੂੰ ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੀ ਪਛਾਣ ਅਤੇ ਉਸਨੂੰ ਲੌਗ ਕਰਨ ਦੀ ਕੁਦਰਤੀ ਥਾਂ ਮਿਲਦੀ ਹੈ; ਤੁਸੀਂ ਸਰਵਵਿਆਪਕਤਾ ਛੱਡ ਦਿੰਦੇ ਹੋ, ਕਿਉਂਕਿ ਹਰ ਨਵੇਂ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਆਪਣਾ ਪ੍ਰੌਕਸੀ ਸਮਰਥਨ ਚਾਹੀਦਾ ਹੈ। HTTP ਸੇਵਾਵਾਂ ਲਈ ਇਹ ਵਟਾਂਦਰਾ ਆਮ ਤੌਰ ਉੱਤੇ ਚੰਗਾ ਹੈ, ਅਤੇ ਜੋ HTTP ਨਹੀਂ ਹੈ ਉਸ ਲਈ ਆਮ ਤੌਰ ਉੱਤੇ ਇਹ ਬਿਲਕੁਲ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦਾ।
ਲਿਖੋ ਕਿ ਹਰ ਸੀਮਾ ਕੀ ਦੇਖਦੀ ਹੈ
ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਡਿਜ਼ਾਈਨ ਸਮੀਖਿਆ ਇੱਕ ਅਜਿਹੀ ਟੇਬਲ ਨਾਲ ਖ਼ਤਮ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਹਰ ਹੌਪ ਉੱਤੇ ਸਰੋਤ ਪਤਾ ਅਤੇ ਸਾਬਤ ਕਰਨ ਯੋਗ ਪਛਾਣ ਦਾ ਨਾਮ ਦੱਸੇ। ਇਸ ਤੋਂ ਬਿਨਾਂ, ਪਹਿਲੀ ਘਟਨਾ ਤਿੰਨ ਟੀਮਾਂ ਪੈਦਾ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰੇ ਕਲਾਇੰਟ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ।
| Boundary | Source the next hop sees | What is actually proven |
|---|---|---|
| Client to gateway | 172.20.8.14 | A certificate or credential was presented |
| Gateway to app subnet, preserved | 172.20.8.14 | The same session, if the return route exists |
| Gateway to app subnet, translated | 10.40.3.10 | Only that traffic came through the gateway |
| Proxy to backend | 10.40.3.10 plus a header | The proxy asserted an identity it authenticated |
ਫਿਰ ਚੁਣੋ। ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਅਧਿਕਾਰ ਸੱਚਮੁੱਚ ਕਲਾਇੰਟ ਪਤੇ ਉੱਤੇ ਨਿਰਭਰ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਮਾਰਗ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈ ਸਕੋ ਤਾਂ ਸਰੋਤ ਸੰਭਾਲੋ। ਜਦੋਂ ਅਜਿਹਾ ਨਾ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਪਛਾਣ ਬੈਂਡ ਤੋਂ ਬਾਹਰ ਲੈ ਜਾ ਸਕੋ ਤਾਂ ਅਨੁਵਾਦ ਕਰੋ, ਅਤੇ ਪਲੇਟਫ਼ਾਰਮ-ਵਿਸ਼ੇਸ਼ ਅੱਗੇ ਭੇਜਣ ਸੈਟਿੰਗਾਂ ਲਈ AWS ਅੱਗੇ ਭੇਜਣ ਵਾਲੇ ਇੰਸਟੈਂਸ ਮਾਰਗਦਰਸ਼ਕ ਵਰਤੋ। ਜਦੋਂ ਸੇਵਾ HTTP ਬੋਲਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਪਛਾਣ ਬਿਲਕੁਲ ਪਤਾ ਨਾ ਰਹੇ ਤਾਂ ਰਿਲੇ ਵੱਲ ਜਾਓ।