VPN ਰਾਹੀਂ NAS ਪ੍ਰਸ਼ਾਸਨ: ਨਾਮ ਰੱਖੋ, ਜਨਤਕ ਪੋਰਟ ਛੱਡੋ
ਪ੍ਰਸ਼ਾਸਨ ਪੰਨੇ ਤੱਕ ਸੁਰੰਗ ਰਾਹੀਂ ਪਹੁੰਚੋ, ਨਵੀਂ ਜਨਤਕ ਪੋਰਟ ਰਾਹੀਂ ਨਹੀਂ। ਅਸਲ ਨਾਮ ਹੱਲ ਕਰੋ, ਉਸ ਨਾਲ ਸਰਟੀਫਿਕੇਟ ਮਿਲਾਓ ਅਤੇ ਇੱਕ ਸਰੋਤ ਤੋਂ ਇੱਕ ਸੇਵਾ ਦੀ ਆਗਿਆ ਦਿਓ।
NAS ਪ੍ਰਸ਼ਾਸਨ ਪੰਨਾ ਘਰ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕ ਦੇ ਸਫ਼ਰ ਤੇ ਜਾਣ ਵਾਲੇ ਪਲ ਹੀ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਪੋਰਟ ਖੋਲ੍ਹ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਮੱਸਿਆ ਪਰਦੇਦਾਰੀ ਨਾਲ ਹੀ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਸ ਲਈ ਇੱਕ ਬਿਹਤਰ ਰੂਪ ਹੈ। ਪੰਨੇ ਨੂੰ ਉੱਥੇ ਹੀ ਰਹਿਣ ਦਿਓ, ਸੁਰੰਗ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰੇ, ਅਤੇ ਜੋ ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ ਕਰਦੇ ਹੋ ਉਸ ਨੂੰ ਨਾਮਿਤ ਆਗਿਆ-ਮਾਰਗ ਵਾਲਾ ਪੂਰਾ URL ਬਣਾਓ, ਨਾ ਕਿ ਕੋਈ ਅਜਿਹਾ ਡਿਵਾਈਸ ਪਤਾ ਜੋ ਸੰਜੋਗ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਹੇਠਾਂ ਦਾ ਹਰ ਫ਼ੈਸਲਾ, ਨਾਮ ਤੋਂ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਇਕਲੌਤੀ ਮਨਜ਼ੂਰ ਪੋਰਟ ਤੱਕ, ਇਸ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖਣ ਤੋਂ ਹੀ ਨਿਕਲਦਾ ਹੈ।
ਡਿਜ਼ਾਈਨ ਦੀ ਇਕਾਈ URL ਹੈ, ਪਤਾ ਨਹੀਂ
ਪ੍ਰਵੇਸ਼ ਨੂੰ ਇਸ ਦੀ ਪੋਰਟ ਅਤੇ ਸਕੀਮ ਸਮੇਤ ਪੂਰਾ URL ਲਿਖੋ, ਫਿਰ ਸ਼ਰਤਾਂ ਜੋੜੋ: ਕੌਣ ਵਰਤ ਸਕਦਾ ਹੈ, ਕਿਹੜੇ ਨੈੱਟਵਰਕ ਤੋਂ ਅਤੇ ਕਿਹੜੇ ਮਾਰਗ ਰਾਹੀਂ। ਉਦਾਹਰਨ https://nas.corp.example:8443 ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਮਨਜ਼ੂਰ ਪ੍ਰਾਈਵੇਟ ਕਲਾਇੰਟਾਂ ਲਈ ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਨਾਮ ਅਤੇ ਪੋਰਟ ਉਸ ਚੀਜ਼ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਦੇ ਹਨ ਜਿਸ ਉੱਤੇ ਡਿਵਾਈਸ ਅਸਲ ਵਿੱਚ ਸੁਣਦਾ ਹੈ।
ਉਹ ਢਾਂਚਾ ਫ਼ੈਸਲਿਆਂ ਨੂੰ ਜਲਦੀ ਲਾਜ਼ਮੀ ਬਣਾ ਦਿੰਦਾ ਹੈ। URL ਨਾਮ ਦਾ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ, ਨਾਮ ਸਰਟੀਫਿਕੇਟ ਦਾ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਭਰੋਸਾ-ਪ੍ਰਬੰਧ ਦਾ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ। ਪਤਾ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਨਹੀਂ ਦਿੰਦਾ, ਅਤੇ ਇਸੇ ਲਈ ਸਿਰਫ਼-ਪਤਾ ਵਾਲਾ ਸੰਸਕਰਣ ਪਹਿਲੀ ਬ੍ਰਾਊਜ਼ਰ ਚੇਤਾਵਨੀ ਤੱਕ ਟਿਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਇਸ ਨੂੰ ਕਲਿੱਕ ਕਰਕੇ ਅੱਗੇ ਵਧਣ ਦੀ ਆਦਤ ਬਣ ਜਾਂਦਾ ਹੈ।
| Entry point | What it costs | When it fits |
|---|---|---|
| Private name over the tunnel | A private DNS zone and a certificate for that name | Administrators who already hold VPN access |
| Public reverse proxy | An exposed front end to patch and monitor | A documented, reviewed need for public reach |
| Vendor relay service | Trust in a third party path | A supported product design, not a workaround |
ਉਹ ਨਾਮ ਰੱਖੋ ਜਿਸ ਲਈ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਹੋਇਆ ਸੀ
ਕਲਾਇੰਟ ਨੂੰ NAS ਦੇ ਪ੍ਰਾਈਵੇਟ ਪਤੇ ਤੱਕ ਮਨਜ਼ੂਰ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਾਈਵੇਟ DNS ਪ੍ਰਬੰਧ ਲੋੜੀਂਦੇ ਹੋਸਟਨਾਮ ਨੂੰ ਉਸ ਪਤੇ ਉੱਤੇ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਨਾਲ ਹੀ ਉਹ ਨਾਮ ਸੰਭਾਲ ਸਕਦਾ ਹੈ ਜਿਸ ਦੀ HTTPS ਸੇਵਾ ਉਮੀਦ ਕਰਦੀ ਹੈ। ਦੋਵੇਂ ਅੱਧੇ ਜ਼ਰੂਰੀ ਹਨ: ਮਾਰਗ ਪੈਕਟ ਉੱਥੇ ਪਹੁੰਚਾਉਂਦਾ ਹੈ, ਨਾਮ ਕਲਾਇੰਟ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਪਛਾਣ ਪਰਖਣੀ ਹੈ।
ਇਸ ਦੀ ਥਾਂ ਸੰਖਿਆਤਮਕ ਪਤਾ ਲਿਖਣ ਨਾਲ ਪਛਾਣ ਦੀ ਲੋੜ ਬਦਲ ਜਾਂਦੀ ਹੈ। RFC 9525 ਉਸ ਨਾਮ ਨੂੰ ਜਿਸ ਨਾਲ ਕਲਾਇੰਟ ਸੰਪਰਕ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਉਸ ਪਛਾਣ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ ਜੋ ਸੇਵਾ ਪੇਸ਼ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ nas.corp.example ਲਈ ਜਾਰੀ ਸਰਟੀਫਿਕੇਟ ਕਾਨੂੰਨੀ ਤੌਰ ਤੇ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਬ੍ਰਾਊਜ਼ਰ 10.20.0.15 ਵੱਲ ਇਸ਼ਾਰਾ ਕੀਤਾ ਗਿਆ ਹੋਵੇ। ਚੇਤਾਵਨੀ ਸਹੀ ਹੈ, ਅਤੇ ਹੱਲ ਨਾਮ ਹੈ, ਕੋਈ ਅਪਵਾਦ ਨਹੀਂ।
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleਸੁਰੰਗ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਚਲਾਓ। ਪਹਿਲਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪ੍ਰਾਈਵੇਟ ਨਾਮ ਉੱਥੇ ਹੱਲ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਜਿੱਥੇ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ, ਅਤੇ ਦੂਜਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸੇਵਾ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਕਿਹੜੇ ਬਦਲਵੇਂ ਵਿਸ਼ਾ-ਨਾਮ ਪੇਸ਼ ਕਰਦੀ ਹੈ। ਪ੍ਰਾਈਵੇਟ CA ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਚਾਰੂ ਚੋਣ ਹੋ ਸਕਦਾ ਹੈ; ਆਦਤ ਨਹੀਂ ਬਣਨੀ ਚਾਹੀਦੀ ਇਹ ਹੈ ਕਿ ਲੋਕਾਂ ਨੂੰ ਪਛਾਣ-ਚੇਤਾਵਨੀਆਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ ਸਿਖਾਇਆ ਜਾਵੇ।
ਪ੍ਰਬੰਧਨ ਮਾਰਗ ਸੀਮਿਤ ਕਰੋ
ਗੇਟਵੇ ਅਤੇ NAS ਦੋਵਾਂ ਉੱਤੇ, ਲੋੜੀਂਦੇ ਸਰੋਤ ਤੋਂ ਠੀਕ ਪ੍ਰਬੰਧਨ ਸੇਵਾ ਦੀ ਆਗਿਆ ਦਿਓ। ਉਹ ਵਾਕ ਇੱਕ ਅਜਿਹਾ ਵੇਰਵਾ ਲੁਕਾਉਂਦਾ ਹੈ ਜੋ ਡੰਗਦਾ ਹੈ: ਰਾਊਟ ਕੀਤਾ ਕਲਾਇੰਟ ਪੂਲ ਅਤੇ ਸਰੋਤ-ਅਨੁਵਾਦ ਕਰਨ ਵਾਲਾ ਗੇਟਵੇ ਵੱਖ-ਵੱਖ ਸਰੋਤ ਪਤਿਆਂ ਨਾਲ NAS ਉੱਤੇ ਪਹੁੰਚਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਲਈ ਲਿਖਿਆ ਆਗਿਆ-ਨਿਯਮ ਦੂਜੇ ਲਈ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ।
NAS ਨੂੰ ਵਾਪਸੀ ਮਾਰਗ ਵੀ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਫੋਰਮ ਪੋਸਟ ਤੋਂ ਮਿਲੇ ਵਿਕਰੇਤਾ ਡਿਫ਼ਾਲਟ ਦੀ ਥਾਂ ਸੰਰਚਿਤ ਪੋਰਟ ਅਤੇ ਸਕੀਮ ਵਰਤਣੀ ਚਾਹੀਦੀ ਹੈ। ਡਿਵਾਈਸ ਤੱਕ ਪਹੁੰਚਣਾ ਉਸ ਦੀ ਹਰ ਪੋਰਟ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਆਗਿਆ ਨਹੀਂ ਹੈ। ਪਿੰਗ ਦਾ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਡਿਵਾਈਸ ਅਤੇ ਲੋਡ ਹੋਣ ਵਾਲੇ ਪ੍ਰਸ਼ਾਸਨ ਪੰਨੇ ਵਿਚਕਾਰਲਾ ਫ਼ਾਸਲਾ ਦੋ ਵੱਖਰੇ ਨਿਯਮਾਂ ਵਿਚਕਾਰਲਾ ਫ਼ਾਸਲਾ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਦੋ ਟਿੱਪਣੀਆਂ ਨਾਲ ਦੋ ਨਿਯਮਾਂ ਵਜੋਂ ਲਿਖੋ, ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਦੇਖ ਸਕੇ ਕਿ ਦੋਵੇਂ ਕਿਉਂ ਹਨ।
VPN ਪ੍ਰਵੇਸ਼ ਨੂੰ NAS ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਤੋਂ ਵੱਖ ਕਰੋ
ਸੁਰੰਗ ਰਾਹੀਂ ਲੰਘਣ ਦੇਣਾ ਡਿਵਾਈਸ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਆਗਿਆ ਹੋਣ ਵਰਗਾ ਨਹੀਂ ਹੈ। ਜਿਸ ਨੂੰ ਕਾਨੂੰਨੀ ਤੌਰ ਤੇ ਫ਼ਾਈਲ ਸਟੋਰੇਜ ਚਾਹੀਦੀ ਹੈ, ਉਸ ਨੂੰ ਸਿਰਫ਼ ਇਸ ਲਈ ਡਿਵਾਈਸ ਪ੍ਰਬੰਧਨ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਮਿਲਣਾ ਚਾਹੀਦਾ ਕਿ ਦੋਵੇਂ ਇੱਕੋ ਗੇਟਵੇ ਪਿੱਛੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ NAS ਦਾ ਖਾਤਾ ਮਾਡਲ ਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇਹ ਵੱਖਰਾਉ ਲਾਗੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਾਂਝਾ ਜਾਂ ਅਨੁਵਾਦਿਤ ਨਿਕਾਸ ਪਤਾ ਵੀ ਕਿਸੇ ਵਿਅਕਤੀਗਤ ਪ੍ਰਸ਼ਾਸਕ ਦੀ ਪਛਾਣ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਜੇ ਆਡਿਟ ਟ੍ਰੇਲ ਨੂੰ ਕਿਸੇ ਵਿਅਕਤੀ ਦਾ ਨਾਮ ਲੈਣਾ ਹੈ, ਤਾਂ ਪਛਾਣ ਪ੍ਰਮਾਣਿਤ ਖਾਤੇ ਤੋਂ ਆਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਵੱਲੋਂ ਵਰਤੀ ਜਾਂਦੀ ਸੁਰੰਗ ਦੇ ਸਰੋਤ ਪਤੇ ਤੋਂ ਨਹੀਂ।
ਕੀ ਗਲਤੀ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾ ਕਰੋ
ਜਨਤਕ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਅਤੇ ਵਿਕਰੇਤਾ ਰਿਲੇ ਦੋਵੇਂ ਅਸਲ ਆਰਕੀਟੈਕਚਰ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਆਪਣੇ ਭਰੋਸੇ ਅਤੇ ਖੁਲਾਸੇ ਦੇ ਫ਼ੈਸਲੇ ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ। ਪ੍ਰਸ਼ਾਸਕ ਦੇ ਘਰ ਤੋਂ ਦੂਰ ਹੋਣ ਕਰਕੇ ਕੋਈ ਵੀ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਮੀਡੀਆ ਸਰਵਰ ਜਾਂ ਫ਼ਾਈਲ ਸਾਂਝ ਨੂੰ ਖੋਲ੍ਹਣ ਦੇ ਮਾੜੇ ਪ੍ਰਭਾਵ ਵਜੋਂ ਵੀ ਕੋਈ ਨਹੀਂ ਦਿਖਣਾ ਚਾਹੀਦਾ।
ਚਾਰ ਚੀਜ਼ਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਅਤੇ ਰੁਕੋ: ਪ੍ਰਾਈਵੇਟ ਨਾਮ, ਉਹ ਲਿਸਨਰ ਜਿਸ ਉੱਤੇ ਇਹ ਮੈਪ ਹੁੰਦਾ ਹੈ, ਉਹ ਸਮੂਹ ਜਿਸ ਨੂੰ ਇਸ ਦੀ ਵਰਤੋਂ ਦੀ ਆਗਿਆ ਹੈ, ਅਤੇ ਸੁਰੰਗ ਉਪਲਬਧ ਨਾ ਹੋਣ ਤੇ ਬਹਾਲੀ ਦਾ ਮਾਰਗ। ਉਹ ਚਾਰ ਉਹਨਾਂ ਸਵਾਲਾਂ ਦਾ ਵੀ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਜੋ ਘਟਨਾ-ਸਮੀਖਿਆ ਪੁੱਛੇਗੀ, ਜੋ ਪੋਰਟ-ਫਾਰਵਰਡਿੰਗ ਪੰਨੇ ਦੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਬਾਰੇ ਸੱਚ ਨਹੀਂ ਹੈ। ਅੰਤ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਥਿਰ ਪ੍ਰਸ਼ਾਸਕੀ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਹੁੰਦਾ ਹੈ, ਹਰ ਸੁਵਿਧਾ ਇੰਟਰਨੈੱਟ ਵੱਲ ਵਾਲਾ ਡਿਵਾਈਸ ਨਹੀਂ।