ਇੱਕ ਜਨਤਕ VPN ਹੋਸਟਨਾਮ ਕੀ ਸਾਬਤ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

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

ਨਾਮ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਹੋਰ ਕੁਝ ਵੀ ਤੈਅ ਨਹੀਂ

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

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

dig +short vpn.example.net A
dig +short vpn.example.net AAAA
dig +short vpn.example.net A @1.1.1.1

ਟ੍ਰਾਂਸਪੋਰਟ ਅਤੇ ਪਛਾਣ ਵੱਖਰੇ ਸਵਾਲ ਹਨ

ਹੋਸਟਨਾਮ 'ਤੇ ਖੁੱਲ੍ਹਿਆ ਵੈੱਬ ਪੇਜ ਇੱਕ ਪੋਰਟ 'ਤੇ ਇੱਕ ਸਰੋਤੇ ਦੀ ਪਰਖ ਕਰਦਾ ਹੈ। OpenVPN, IPsec ਅਤੇ SSTP ਕਿਤੇ ਹੋਰ, ਆਪਣੇ ਪੋਰਟਾਂ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲਾਂ 'ਤੇ ਸੁਣਦੇ ਹਨ, ਇਸ ਲਈ ਪਹੁੰਚਯੋਗ ਵੈੱਬ ਸਰਵਰ ਉਹਨਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

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

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates

ਦੇਸ਼ਾਂ ਦੇ ਸ਼ਬਦ ਸਥਾਨ ਦੀ ਜਾਂਚ ਨਹੀਂ

ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ jp ਜਾਂ de ਲੇਬਲ ਇੱਕ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਹੈ, ਅਤੇ IP ਭੂ-ਸਥਾਨ ਡੇਟਾਬੇਸ ਕਾਫ਼ੀ ਵਾਰ ਨਹੀਂ ਮਿਲਦੇ, ਇਸ ਲਈ ਕਿਸੇ ਨੂੰ ਵੀ ਪੂਰਨ ਸੱਚ ਨਹੀਂ ਮੰਨਣਾ ਚਾਹੀਦਾ। ਸਾਂਝੀ ਹੋਸਟਿੰਗ, anycast ਅਤੇ ਸਧਾਰਨ ਗਲਤ ਸੰਰਚਨਾ ਸਾਰੇ ਦੇਖੇ ਗਏ ਸਥਾਨ ਨੂੰ ਲੇਬਲ ਤੋਂ ਦੂਰ ਲੈ ਜਾਂਦੇ ਹਨ।

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

ਪੇਸ਼ ਕੀਤੀ ਸੇਵਾ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਆਪਰੇਟਰ ਦੀ

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

ਜਨਤਕ ਜਾਂ ਸਵੈਸੇਵਕਾਂ ਵੱਲੋਂ ਚਲਾਏ ਨੋਡ ਲਈ, ਮੰਨ ਲਓ ਕਿ ਨਿਕਾਸ ਸਾਂਝਾ ਹੈ ਅਤੇ ਜੋ ਇਸਨੂੰ ਚਲਾਉਂਦਾ ਹੈ ਉਹ ਦੇਖ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਲੰਘਦਾ ਹੈ। ਹੋਸਟਨਾਮ ਨਹੀਂ, ਇਹ ਧਾਰਨਾ ਹੀ ਤੈਅ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਸੁਰੰਗ ਰਾਹੀਂ ਕੀ ਭੇਜਦੇ ਹੋ।

curl -sSI https://vpn.example.net/ | head -n 5
whois 203.0.113.25 | grep -i -E 'orgname|netname'

ਨਾਮ ਨੂੰ ਉਸ ਕੰਮ ਲਈ ਰੱਖੋ ਜਿਸ ਵਿੱਚ ਇਹ ਚੰਗਾ ਹੈ: ਅੰਤ ਬਿੰਦੂ ਲੱਭਣਾ ਅਤੇ ਉਸ ਨਾਲ ਜੁੜਨਾ। ਇਸ ਤੋਂ ਅੱਗੇ ਦਾ ਸਭ ਕੁਝ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਪਰਖਣਾ ਪਵੇਗਾ, ਜਿਸ ਦਿਨ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ।