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

ਦੋ ਸਾਕਟ, ਦੋ ਮਾਲਕ, ਇੱਕ ਜਨਤਕ

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

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

ਫਾਰਵਰਡ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਉਤਰਦਾ ਹੈ

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

HopListens onMust reachSymptom when it points elsewhere
Client machineA local plaintext portThe wrapper's public TLS addressPlain text offered to a TLS endpoint
Router forwardPublic TCP 443The wrapper host on its translated portWrapper records no connection at all
Wrapper, server modeIts accepted port, 8443 hereThe native VPN socket on loopbackHandshake completes, then silence
Native VPN listenerLoopback TCP portIts peer, over TCP onlyA UDP socket behind a byte-stream relay

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

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

ਤੁਹਾਨੂੰ ਇਨਕਾਰ ਕਰਨ ਵਾਲਾ ਬਾਈਂਡ ਪਤਾ

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

ਦੋਵਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਕੰਮ ਕਰਦਾ ਰੈਪਰ ਬਾਹਰੋਂ ਅਪਹੁੰਚ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਹਰ ਫ਼ਾਈਲ ਸਹੀ ਦਿਸਦੀ ਹੈ। ਹੇਠਲੀ ਜਾਂਚ ਇੱਕ ਕਮਾਂਡ ਹੈ, ਅਤੇ ਇਹ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜੋ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਦੀ ਸਮੀਖਿਆ ਨਹੀਂ ਦੇ ਸਕਦੀ। ਜੇ ਆਉਟਪੁੱਟ loopback ਪਤਾ ਦਿਖਾਉਂਦੀ ਹੈ ਜਦੋਂ ਕਿ ਫਾਰਵਰਡ LAN ਪਤੇ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਸੁਧਾਰ accept ਕਤਾਰ ਵਿੱਚ ਹੈ, ਪੈਕਟ ਫਿਲਟਰ ਵਿੱਚ ਨਹੀਂ।

ss -lntp '( sport = :8443 )'

ਸਥਾਨਕ ਟੈਸਟ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕੀਤਾ

ਜਿਸ ਛਾਲ ਨੂੰ ਉਸ ਨੇ ਢਕਿਆ ਸੀ ਉਹ ਦਰਜ ਕੀਤੇ ਬਿਨਾਂ ਰਿਕਾਰਡ ਕੀਤੀ ਸਫਲਤਾ ਹੋਰ ਛਾਲਾਂ ਬਾਰੇ ਸਬੂਤ ਨਹੀਂ ਹੈ। ਟੈਸਟ ਨੇ ਕਿਹੜਾ ਪਤਾ ਵਰਤਿਆ ਅਤੇ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਨੇ ਜਵਾਬ ਦਿੱਤਾ, ਇਹ ਲਿਖੋ। ਫਿਰ ਉਸੇ Wi-Fi ਦੇ ਫ਼ੋਨ ਤੋਂ ਨਹੀਂ, ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਹਰੋਂ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਹੇਅਰਪਿਨ ਵਿਵਹਾਰ ਰਾਊਟਰਾਂ ਵਿੱਚ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ ਅਤੇ LAN ਕਦੇ ਨਾ ਛੱਡਿਆ ਕਨੈਕਸ਼ਨ ਵੀ ਫਾਰਵਰਡ ਬਿਲਕੁਲ ਸ਼ਾਮਲ ਨਾ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਕਲਾਇੰਟ ਨੂੰ ਸੰਤੁਸ਼ਟ ਕਰ ਸਕਦਾ ਹੈ। ਸਿਰਫ਼ ਉਹੀ ਦੂਜੀ ਕੋਸ਼ਿਸ਼ ਬਾਹਰਲੇ ਬੰਦੇ ਵੱਲੋਂ ਲਏ ਰਾਹ ਦਾ ਅਭਿਆਸ ਕਰਦੀ ਹੈ।

ਜੇ ਕੋਸ਼ਿਸ਼ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇੱਕ ਕਨੈਕਸ਼ਨ ਨੂੰ ਦੋਵਾਂ ਲੌਗਾਂ ਵਿੱਚ ਟਰੈਕ ਕਰੋ: ਰੈਪਰ ਦੀਆਂ ਸਵੀਕਾਰ ਅਤੇ ਜੁੜੀਆਂ ਕਤਾਰਾਂ, ਫਿਰ VPN ਡੀਮਨ ਦਾ ਆਪਣਾ ਸੈਸ਼ਨ ਲੌਗ। ਜੋ ਪਹਿਲੀ ਹੱਦ ਕੁਝ ਵੀ ਦਰਜ ਨਹੀਂ ਕਰਦੀ, ਅਗਲੀ ਤਬਦੀਲੀ ਦੀ ਥਾਂ ਉਹੀ ਹੈ। ਜਦੋਂ OpenVPN ਸਾਥੀ ਦੇ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲੱਗੇ, ਤਾਂ ਉਹਨਾਂ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਉਸ ਲਾਗੂਕਰਨ ਦੇ ਨਿਯਮਾਂ ਨਾਲ ਜਾਂਚੋ। link-mtu ਅਸੰਗਤੀ ਦੀ ਚੇਤਾਵਨੀ ਆਪਣੇ ਆਪ ਘਾਤਕ ਨਹੀਂ ਹੈ, link-mtu ਨੂੰ 1500 ਉੱਤੇ ਪਿੰਨ ਕਰਨਾ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਖੰਡਨ ਰੁਕ ਗਿਆ, ਅਤੇ ਸਾਈਫਰ ਵਾਰਤਾ ਰਾਊਟਰ ਦੇ ਫਾਰਵਰਡ ਦੀ ਨਹੀਂ ਬਲਕਿ ਅੰਦਰੂਨੀ OpenVPN ਕਾਨਫਿਗਰੇਸ਼ਨ ਦੀ ਗੱਲ ਹੈ।

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

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

ਦੋ ਪਛਾਣਾਂ, ਦੋ ਫੇਲ੍ਹਤਾ ਕ੍ਰਮ

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

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

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

ਸੰਬੰਧਿਤ ਲੇਖ