VPN ਪਿੱਛੇ SaaS ਐਡਮਿਨ ਖੇਤਰ: ਕਿਹੜੇ ਪਤੇ ’ਤੇ ਭਰੋਸਾ ਕਰੀਏ?

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

ਟਨਲ ਤੋਂ ਬਾਅਦ ਓਰੀਜਨ ਅਸਲ ਵਿੱਚ ਕੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ

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

curl -s https://ifconfig.me
dig +short admin.example.com

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

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

ਸਿਰਫ਼ ਉਸ ਪ੍ਰੌਕਸੀ ’ਤੇ ਭਰੋਸਾ ਕਰੋ ਜੋ ਪਤਾ ਮੁੜ ਲਿਖਦਾ ਹੈ

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

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

ਇਹੀ ਤਰਕ PROXY ਪ੍ਰੋਟੋਕੋਲ ’ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਇਹ ਸਿਰਫ਼ ਤਦ ਭਰੋਸੇਯੋਗ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਰੋਤਾ ਅਜਿਹੇ ਇੰਟਰਫ਼ੇਸ ਨਾਲ ਬੱਝਾ ਹੋਵੇ ਜਿੱਥੇ ਪ੍ਰੌਕਸੀ ਪਹੁੰਚ ਸਕੇ ਅਤੇ ਹੋਰ ਕੋਈ ਨਾ ਪਹੁੰਚ ਸਕੇ। ਗ਼ੈਰਹਾਜ਼ਰ ਪਤਾ ਸੰਦਰਭ ਨੂੰ ਸੁਰੱਖਿਅਤ ਜਾਂਚ ਫੇਲ੍ਹ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਡਿਫ਼ਾਲਟ ਮਨਜ਼ੂਰੀ ਵਿੱਚ ਡਿੱਗਣਾ ਚਾਹੀਦਾ ਹੈ। ਗ਼ੈਰਹਾਜ਼ਰ ਹੈਡਰ ਭਰੋਸੇਯੋਗ ਰਾਹ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ।

ਸ਼ਰਤ ਨੂੰ ਹਰ ਸੁਰੱਖਿਅਤ ਕਾਰਵਾਈ ਨਾਲ ਜੋੜੋ

ਜਾਂਚ ਨੂੰ ਹਰ ਸੁਰੱਖਿਅਤ ਕਾਰਵਾਈ ਲੰਘਣ ਵਾਲੀ ਅਧਿਕਾਰ ਸੀਮਾ ’ਤੇ ਰੱਖੋ, ਮੀਨੂ ਰੈਂਡਰ ਕਰਨ ਵਾਲੇ ਪੰਨੇ ’ਤੇ ਨਹੀਂ। ਰੂਟ ਸਮੂਹ, ਮਿਡਲਵੇਅਰ ਜਾਂ ਨੀਤੀ ਪਰਤ ਸਾਰੇ ਕੰਮ ਕਰਦੇ ਹਨ; ਪ੍ਰਤੀ ਹੈਂਡਲਰ ਕਾਪੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਅਗਲੀ ਤਿਮਾਹੀ ਵਿੱਚ ਕੋਈ ਜੋੜੇਗਾ ਉਸ ਹੈਂਡਲਰ ਕੋਲ ਇਹ ਨਹੀਂ ਹੋਵੇਗੀ।

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

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

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

ਤੁਸੀਂ ਹੁਣੇ ਬੰਦ ਕੀਤੇ ਬਾਈਪਾਸ ਦੀ ਜਾਂਚ ਕਰੋ

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

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

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

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