VPN ਉੱਤੇ Cassandra: ਕਲਾਇੰਟਾਂ ਅਤੇ ਨੋਡਾਂ ਲਈ ਵੱਖਰੀ ਪਹੁੰਚ

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

ਤਿੰਨਾਂ ਦਰਸ਼ਕਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣਾ ਜਵਾਬ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਹੇਠਾਂ ਦਿੱਤੇ ਭਾਗ ਉਨ੍ਹਾਂ ਨੂੰ ਖੁੱਲ੍ਹ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਲੈਂਦੇ ਹਨ।

ਤਿੰਨ ਦਰਸ਼ਕ, ਤਿੰਨ ਫ਼ੈਸਲੇ

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

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

ਕਲਾਇੰਟਾਂ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ

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

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

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

ਕਲਾਇੰਟ-ਤੋਂ-ਨੋਡ ਅਤੇ ਇੰਟਰਨੋਡ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ਤੇ ਇਨਕ੍ਰਿਪਟ ਕਰੋ

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

ਇੱਕ ਸੰਰਚਨਾ ਜੋ ਦੋਵਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ ਤੇ ਚਾਲੂ ਕਰਦੀ ਹੈ, ਟੈਂਪਲੇਟ ਡਿਫ਼ਾਲਟ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਣ ਦੀ ਥਾਂ, ਲਗਭਗ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦੀ ਹੈ:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

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

ਪ੍ਰਬੰਧਨ ਨੂੰ ਆਪਣੇ ਵੱਖਰੇ ਰਾਹ ਉੱਤੇ ਰੱਖੋ

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

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

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

ਡਿਜ਼ਾਈਨ ਕੀ ਵਾਅਦਾ ਕਰਦਾ ਹੈ

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

ਡਿਜ਼ਾਈਨ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਤਿੰਨ ਵਾਕਾਂ ਨਾਲ ਸਮਾਪਤ ਕਰੋ: ਕਿਹੜੇ ਕਲਾਇੰਟ ਕਿਊਰੀ ਕਰ ਸਕਦੇ ਹਨ, ਕਿਹੜੇ ਨੋਡ ਸੰਚਾਰ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਕਿਹੜੇ ਆਪਰੇਟਰ ਪ੍ਰਬੰਧਨ ਕਰ ਸਕਦੇ ਹਨ। VPN ਦੇ ਪਿੱਛੇ ਹੋਣਾ ਲਾਭਦਾਇਕ ਟੋਪੋਲੋਜੀ ਜਾਣਕਾਰੀ ਹੈ, ਪਰ ਇਹ ਉਨ੍ਹਾਂ ਤਿੰਨ ਸਵਾਲਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦਾ ਜਵਾਬ ਨਹੀਂ ਹੈ।