VPN 'ਤੇ Nmap ਦਾ ਕੱਚਾ ਸਕੈਨ ਫੇਲ੍ਹ, ਪਰ -sT ਕਨੈਕਸ਼ਨ ਕੰਮ ਕਰਦਾ ਹੈ?

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

ਸਮਰੱਥਾ ਨੂੰ ਸੁਰੰਗ ਤੋਂ ਵੱਖ ਕਰੋ

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

ਇਹੀ ਫ਼ਰਕ ਆਮ ਅਸਮਾਨਤਾ ਸਮਝਾਉੰਦਾ ਹੈ। curl ਸਫ਼ਲ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਸਾਕਟ ਮਾਰਗ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ SYN ਸਕੈਨ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰਕਿਰਿਆ ਸੁਰੰਗ ਇੰਟਰਫੇਸ 'ਤੇ ਕੱਚਾ ਸਾਕਟ ਨਹੀਂ ਖੋਲ ਸਕਦੀ। ਇਹ ਉਲਟੀ ਸਥਤੀ ਵੀ ਸਮਝਾਉੰਦਾ ਹੈ, ਜਿੱਥੇ ਕੱਚਾ ਸਕੈਨ ਫਿਲਟਰਡ ਦੱਸਦਾ ਹੈ ਕਿਉਂਕਿ ਮਾਰਗ ਪ੍ਰੋਬ ਸੁੱਟ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਮਾਰਗ ਠੀਕ ਰਹਿੰਦਾ ਹੈ।

ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਤੀਜਾ ਦੂਰਸਥ ਸੇਵਾ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦਾ। ਦੋਵੇਂ ਇੱਕ ਹੀ ਢੰਗ ਹੇਠ ਇੱਕ ਹੀ ਮਾਰਗ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਢੰਗ ਨੂੰ ਨਤੀਜੇ ਨਾਲ ਜੋੜੀ ਰੱਖੋ।

ਕਨੈਕਸ਼ਨ ਜਾੰਚ ਇੱਕ ਮੰਜੂਰ ਹੋਸਟ 'ਤੇ ਚਲਾਓ

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

ਇੱਕ ਲਾਈਨ, ਇੱਕ ਹੋਸਟ, ਇੱਕ ਪੋਰਟ, ਕੋਈ ਖੋਜ ਪੜਾਅ ਨਹੀਂ:

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

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

ਹਰ ਫਲੈਗ ਨੂੰ ਇੱਕ ਬਦਲਾਅ ਵਜੋਂ ਪੱੜ੍ਹੋ, ਮੁਰੰਮਤ ਵਜੋਂ ਨਹੀਂ

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

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

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

ਟ੍ਰਾੰਸਪੋਰਟ ਨਤੀਜੇ 'ਤੇ ਰੁਕੋ, ਫਿਰ ਸੇਵਾ ਦੀ ਜਾੰਚ ਕਰੋ

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

ਇਸ ਨੂੰ ਸੇਵਾ ਦੇ ਆਪਣੇ ਕਲਾਇਂਟ ਨਾਲ ਅੱਗੇ ਵਧਾਓ ਤਾਂ ਜੋ TLS ਪਹਚਾਣ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਵੱਖਰੇ ਤਥ ਵਜੋਂ ਦੇਖੇ ਜਾ ਸਕਣ:

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

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

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