VPN ਪਿੱਛੇ IoT ਸੈਂਸਰ ਲਗਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਪਤਾ ਫੈਸਲੇ
ਤਿੰਨ ਪਤੇ ਤਿੰਨ ਕੰਮ ਕਰਦੇ ਹਨ: ਜਨਤਕ ਹੱਬ, ਪ੍ਰਮਾਣਿਤ ਸਾਈਟ ਪੀਅਰ ਅਤੇ ਸੈਂਸਰ ਦਾ ਨਿੱਜੀ ਪਤਾ। ਕੁਝ ਵੀ ਜਨਤਕ ਵੰਡਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਇੱਕ ਦੀ ਯੋਜਨਾ ਬਣਾਓ।
ਹਰ IoT-ਤੋਂ-VPN ਯੋਜਨਾ ਵਿੱਚ ਤਿੰਨ ਪਤੇ ਉਲਝ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇਹ ਇੱਕੋ ਕਿਸਮ ਦਾ ਫੈਸਲਾ ਨਹੀਂ ਹਨ। ਇੱਕ ਇਹ ਹੈ ਕਿ ਦੂਰ ਬੈਠਾ ਆਪਰੇਟਰ ਟਨਲ ਦਾ ਅੰਤ ਬਿੰਦੂ ਕਿਵੇਂ ਲੱਭਦਾ ਹੈ, ਦੂਜਾ ਇਹ ਹੈ ਕਿ ਸਾਈਟ ਕਿਵੇਂ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਉਹੀ ਸਾਈਟ ਹੈ, ਅਤੇ ਤੀਜਾ ਇਹ ਹੈ ਕਿ ਸੈਂਸਰ ਦੀ ਸੇਵਾ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਸੁਣਦੀ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਜਵਾਬ ਦਿਓ ਅਤੇ ਡਿਜ਼ਾਈਨ ਲਗਭਗ ਆਪਣੇ ਆਪ ਨਿਕਲ ਆਉਂਦਾ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਸਵਾਲ ਵਜੋਂ ਜਵਾਬ ਦਿਓ ਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਉਪਕਰਣਾਂ ਨੂੰ ਜਨਤਕ ਪਤੇ ਵੰਡਣ ਤੱਕ ਪਹੁੰਚ ਜਾਓਗੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਦੇ ਇਸ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਸਾਈਟ ਟਨਲ ਪਿੱਛੇ ਬੈਠਾ ਸੈਂਸਰ ਸੈਂਸਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ ਅੰਦਰ ਆਉਣ ਵਾਲੇ ਨਿਯਮ ਤੋਂ ਬਿਨਾਂ ਅਧਿਕਾਰਤ ਆਪਰੇਟਰ ਲਈ ਪਹੁੰਚਯੋਗ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਕੌਣ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ
ਕੌਣ ਡਾਇਲ ਕਰਦਾ ਹੈ ਇਹ ਬਾਕੀ ਲਗਭਗ ਸਭ ਕੁਝ ਤੈਅ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਸਾਈਟ ਹੱਬ ਵੱਲ ਡਾਇਲ ਕਰਦੀ ਹੈ, ਸਾਈਟ ਨੂੰ ਕੋਈ ਅੰਦਰ ਆਉਣ ਵਾਲੀ ਪਹੁੰਚ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਹੱਬ ਨੂੰ ਉਹ ਨਾਮ ਜਾਂ ਪਤਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸਾਈਟ ਹੱਲ ਕਰ ਸਕੇ। ਇਹ ਇੱਕ ਚੋਣ ਸਥਿਰ ਜਨਤਕ ਪਤਾ-ਨਿਰਧਾਰਨ ਦੀ ਬਹਿਸ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਹਟਾ ਦਿੰਦੀ ਹੈ।
ਫਿਰ ਤਿੰਨ ਭੂਮਿਕਾਵਾਂ ਸਾਫ਼ ਵੱਖ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਫੈਸਲੇ ਦਾ ਸਭ ਤੋਂ ਛੋਟਾ ਰੂਪ ਹੈ।
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
ਹਰ ਕਤਾਰ ਦਾ ਵੱਖਰਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਅਸਲ ਗੱਲ ਹੈ। ਹੱਬ ਉਸ ਦਾ ਹੈ ਜੋ VPN ਸੇਵਾ ਚਲਾਉਂਦਾ ਹੈ, ਸਾਈਟ ਪੀਅਰ ਨੈੱਟਵਰਕ ਟੀਮ ਦਾ, ਅਤੇ ਸੈਂਸਰ ਦਾ ਪਤਾ ਉਸ ਦਾ ਜੋ ਉਪਕਰਣ ਰੱਖਦਾ ਹੈ।
ਹੱਬ ਦਾ ਪਤਾ ਬੂਟਸਟ੍ਰੈਪ ਹੈ, ਮੰਜ਼ਿਲ ਨਹੀਂ
ਜਨਤਕ ਪਤੇ ਵੱਲ ਹੱਲ ਹੁੰਦਾ ਨਾਮ ਹੱਬ ਲਈ ਕਾਫ਼ੀ ਹੈ। DNS ਰਿਕਾਰਡ ਅੰਤ ਬਿੰਦੂ ਦੇ ਹਿਲਣ ’ਤੇ ਉਸ ਦਾ ਪਿੱਛਾ ਕਰ ਸਕਦਾ ਹੈ, ਹਰ ਸਾਈਟ ਸੰਰਚਨਾ ਨੂੰ ਹੱਥ ਨਾਲ ਸੋਧੇ ਬਿਨਾਂ। DNS ਜੋ ਨਹੀਂ ਕਰਦਾ ਉਹ ਹੈ ਪਹੁੰਚ ਬਣਾਉਣਾ ਜਾਂ ਪੁਰਾਣਾ ਜਵਾਬ ਕੈਸ਼ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟ ਨੂੰ ਤਾਜ਼ਾ ਕਰਨਾ, ਅਤੇ ਇਹ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ ਵੱਖਰੇ ਹੱਲਾਂ ਨਾਲ।
ਜੇ ਤੁਸੀਂ ਹੱਬ ਤੋਂ ਬਿਨਾਂ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਟਨਲ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਉਹੀ ਤਰਕ ਦੂਜੇ ਰੂਪ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਪਾਸੇ ਨੂੰ ਪਹੁੰਚਯੋਗ ਅੰਤ ਬਿੰਦੂ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਦੋਵੇਂ ਪਾਸੇ ਕਿਸੇ ਤੀਜੇ ਪੱਖ ਨੂੰ ਡਾਇਲ ਕਰਦੇ ਹਨ। ਕਿਸੇ ਨੂੰ ਫਿਰ ਵੀ ਉਸ ਪਤੇ ਅਤੇ ਉਸ ਦੇ ਨਵੀਨੀਕਰਨ ਦਾ ਮਾਲਕ ਹੋਣਾ ਪੈਂਦਾ ਹੈ।
ਸਾਈਟ ਪੀਅਰ ਪ੍ਰੀਫਿਕਸ ਜੋੜੀ ਪਛਾਣ ਹੈ
ਪੀਅਰ ਪਹਿਲਾਂ ਪਛਾਣ ਹੈ ਅਤੇ ਦੂਜੇ ਪ੍ਰੀਫਿਕਸ। WireGuard ਦੀਆਂ ਸ਼ਰਤਾਂ ਵਿੱਚ ਪੀਅਰ ਕੁੰਜੀ-ਜੋੜੀ ਰੱਖਦਾ ਹੈ ਅਤੇ ਹੱਬ ਦੀ AllowedIPs ਐਂਟਰੀ ਉਸ ਕੁੰਜੀ ਨੂੰ ਸਾਈਟ ਦੇ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਬੰਨ੍ਹਦੀ ਹੈ। IKEv2 ਦੀਆਂ ਸ਼ਰਤਾਂ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੀਤੀ ਕੁੰਜੀ ਸਾਈਟ ਦੀ ਪਛਾਣ ਕਰਦੀ ਹੈ ਅਤੇ ਉਸ ਦੇ ਟਰੈਫਿਕ ਚੋਣਕਾਰ ਦੱਸਦੇ ਹਨ ਕਿ ਉਹ ਕੀ ਢੋ ਸਕਦੀ ਹੈ। ਸਿਰਫ਼ ਇੱਕ ਅੱਧ ਬਦਲਣ ਨਾਲ ਪ੍ਰਬੰਧ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਪਤਾ ਬਦਲਣ ਨੂੰ ਕਦੇ ਵੀ ਪਛਾਣ ਬਦਲਣ ਨਹੀਂ ਸਮਝਣਾ ਚਾਹੀਦਾ।
ਕੁੰਜੀ ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਦੀ ਮਾਲਕੀ ਹੱਬ ਆਪਰੇਟਰ ਕੋਲ ਨਹੀਂ, ਸਾਈਟ ਕੋਲ ਰੱਖੋ, ਤਾਂ ਜੋ ਸਪਲਾਇਰ ਬਦਲਣਾ ਪਛਾਣ ਬਦਲਣਾ ਨਾ ਬਣ ਜਾਵੇ।
ਪ੍ਰੀਫਿਕਸ ਉਹ ਹਿੱਸਾ ਹੈ ਜਿਸ ਦੀ ਯੋਜਨਾ ਲੋਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ। ਹੱਬ ਨੂੰ ਸੈਂਸਰ ਦਾ ਸਬਨੈੱਟ ਸਹੀ ਪੀਅਰ ਨਾਲ ਜੋੜਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਆਪਰੇਟਰ ਦੇ ਕਲਾਇੰਟ ਨੂੰ ਉੱਥੇ ਤੱਕ ਰੂਟ ਚਾਹੀਦਾ ਹੈ; ਸਿਰਫ਼ ਕਲਾਇੰਟ ਉੱਤੇ ਮੌਜੂਦ ਰੂਟ ਟਰੈਫਿਕ ਨੂੰ ਅਜਿਹੀ ਟਨਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ ਜੋ ਉਸ ਨੂੰ ਚੁੱਪਚਾਪ ਸੁੱਟ ਦਿੰਦੀ ਹੈ। ਕੁੰਜੀ ਦੇ ਫਿੰਗਰਪ੍ਰਿੰਟ ਦੇ ਕੋਲ ਸਾਈਟ ਰਿਕਾਰਡ ਵਿੱਚ ਪ੍ਰੀਫਿਕਸ ਲਿਖੋ, ਤਾਂ ਜੋ ਬਦਲਿਆ ਗਿਆ ਗੇਟਵੇ ਬਿਨਾਂ ਧਿਆਨ ਦਿੱਤੇ ਵੱਖਰੀ ਕਵਰੇਜ ਨਾਲ ਨਾ ਆ ਸਕੇ।
ਸੈਂਸਰ ਦਾ ਪਤਾ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਹੈ
ਸਾਈਟ ਦੀ ਯੋਜਨਾ ਤੋਂ ਨਿੱਜੀ ਪਤਾ ਕਾਫ਼ੀ ਹੈ, ਅਤੇ ਉਸ ਨੂੰ ਜਨਤਕ ਪਹੁੰਚ ਨਹੀਂ ਸਗੋਂ ਸਥਿਰਤਾ ਚਾਹੀਦੀ ਹੈ: DHCP ਰਿਜ਼ਰਵੇਸ਼ਨ, ਸਥਿਰ ਨਿਰਧਾਰਨ, ਜਾਂ ਸਾਈਟ ਦੇ ਆਪਣੇ ਜ਼ੋਨ ਵਿੱਚ ਨਾਮ। ਜੇ ਉਪਕਰਣ ਨੂੰ ਮੁੜ-ਸੰਖਿਆ ਦਿੱਤੀ ਨਹੀਂ ਜਾ ਸਕਦੀ, ਤਾਂ ਸਾਈਟ ਗੇਟਵੇ ਉੱਤੇ ਅਨੁਵਾਦ ਜਾਇਜ਼ ਜਵਾਬ ਹੈ, ਜਿੰਨਾ ਚਿਰ ਅਨੁਵਾਦ ਦਸਤਾਵੇਜ਼ੀ ਹੈ ਅਤੇ ਵਾਪਸੀ ਟਰੈਫਿਕ ਉਸ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ।
ਇੱਕ ਹੋਰ ਆਦਤ ਜੋ ਰੱਖਣ ਯੋਗ ਹੈ: ਸੈਂਸਰ ਦੇ ਹੋਸਟ ਉੱਤੇ ਅਗਲੇ-ਹੌਪ ਖੇਤਰ ਵਿੱਚ ਕਦੇ ਵੀ ਜਨਤਕ ਹੱਬ ਪਤਾ ਨਾ ਚਿਪਕਾਓ। VPN ਆਪਣਾ ਰਾਹ ਲਗਾਉਂਦਾ ਹੈ, ਅਤੇ ਜਨਤਕ ਅੰਤ ਬਿੰਦੂ ਨਾਲ ਆਮ ਈਥਰਨੈੱਟ ਨੇੜਤਾ ਇੱਕ ਕਲਪਨਾ ਹੈ ਜੋ ਭਰੋਸੇਯੋਗ ਦਿਖਣ ਵਾਲੀ ਸੰਰਚਨਾ ਬਣਾਉਂਦੀ ਹੈ।
ਜਵਾਬ ਉਹ ਅੱਧ ਹਨ ਜੋ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਉਪਕਰਣ ਨੂੰ ਆਪਣਾ ਜਵਾਬ ਟਨਲ ਵੱਲ ਵਾਪਸ ਭੇਜਣਾ ਪੈਂਦਾ ਹੈ, ਭਾਵੇਂ ਆਪਰੇਟਰ ਦੇ ਕਲਾਇੰਟ ਤੱਕ ਰੂਟ ਰਾਹੀਂ ਜਾਂ ਉਸੇ ਗੇਟਵੇ ਰਾਹੀਂ ਜਿਸ ਨੇ ਬੇਨਤੀ ਦਾ ਅਨੁਵਾਦ ਕੀਤਾ। ਗਲਤ ਡਿਫਾਲਟ ਗੇਟਵੇ ਵਾਲਾ ਸੈਂਸਰ ਬੇਨਤੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਖਾਲੀ ਵਿੱਚ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਨੋਟਸ ਦੱਸਦੇ ਹਨ ਕਿ ਆਗਮਨ ਅਤੇ ਜਵਾਬ ਰੂਟਿੰਗ ਇੱਕ ਨਹੀਂ ਦੋ ਲੋੜਾਂ ਕਿਉਂ ਹਨ।
ਫੈਸਲਾ ਕਰੋ, ਫਿਰ ਸੀਮਾ ਲਿਖੋ
ਕੋਈ ਜੁੜੇ ਤੋਂ ਪਹਿਲਾਂ ਪਹੁੰਚ ਸੀਮਾ ਲਿਖੋ। ਗੇਟਵੇ ਨੂੰ IoT ਹਿੱਸੇ ਅਤੇ ਆਪਰੇਟਰ ਨੂੰ ਲੋੜੀਂਦੀਆਂ ਖਾਸ ਸੇਵਾਵਾਂ ਤੱਕ ਸੀਮਤ ਰੱਖੋ, ਕਿਉਂਕਿ ਕੰਮ ਕਰਦਾ ਰੂਟ ਹਾਦਸੇ ਨਾਲ ਆਮ ਪਹੁੰਚ ਬਣ ਜਾਂਦਾ ਹੈ। ਸਿਰਫ਼-ਪੜ੍ਹਨ ਨਿਗਰਾਨੀ ਅਤੇ ਸੰਰਚਨਾ ਅਧਿਕਾਰ ਨੂੰ ਵੱਖਰੀ ਪਛਾਣ ਵਾਲੀਆਂ ਵੱਖਰੀਆਂ ਭੂਮਿਕਾਵਾਂ ਵਜੋਂ ਰੱਖੋ, ਅਤੇ ਇਕਰਾਰਨਾਮਾ ਖ਼ਤਮ ਹੋਣ ’ਤੇ ਪਹੁੰਚ ਹਟਾਉਣ ਵਾਲੇ ਵਿਅਕਤੀ ਦਾ ਨਾਮ ਲਿਖੋ।
ਮਨਜ਼ੂਰੀ ਨੈੱਟਵਰਕ ਮਾਲਕ ਦੀ ਹੈ, ਅਤੇ DMZ ਵਿੱਚ ਹੋਣਾ ਪਹੁੰਚ ਨੀਤੀ ਨਹੀਂ ਹੈ।
ਤੈਨਾਤੀ ਤੋਂ ਬਾਅਦ ਦਾ ਟੈਸਟ ਉਬਾਊ ਅਤੇ ਨਿਰਣਾਇਕ ਹੈ: ਮਨਜ਼ੂਰ ਪ੍ਰੀਫਿਕਸ ਦੇ ਅੰਦਰ ਇੱਕ ਬੇਨਤੀ ਜੋ ਸਫਲ ਹੁੰਦੀ ਹੈ, ਗੇਟਵੇ ਉੱਤੇ ਵਧਦਾ ਇੱਕ ਕਾਊਂਟਰ, ਅਤੇ ਪ੍ਰੀਫਿਕਸ ਤੋਂ ਬਾਹਰ ਇੱਕ ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤਾ ਯਤਨ ਜੋ ਅਸਫਲ ਹੁੰਦਾ ਹੈ।