OpenVPN ਘਰ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਇੱਕ ਨੈੱਟਵਰਕ ਉੱਤੇ ਨਹੀਂ: UDP ਜਾਂ TCP?

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

ਕਿਹੜਾ ਪੜਾਅ ਫੇਲ੍ਹ ਹੋਇਆ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਤੁਲਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ

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

ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ, ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਮੇਂ ਕੈਪਚਰ ਕਰੋ। ਕਲਾਇੰਟ ਉੱਤੇ tcpdump -ni any udp port 1194 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੋਈ ਜਵਾਬ ਵਾਪਸ ਆਉਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਤੁਸੀਂ ਜਿਸ ਸਰਵਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ ਉਸ ਦੇ WAN ਇੰਟਰਫੇਸ ਉੱਤੇ ਦੁਹਰਾਓ, ਜੋ ਖੁਲਾਸਾ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਪੈਕਟ ਦੂਰਲੇ ਸਿਰੇ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ ਜਾਂ ਨਹੀਂ।

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

UDP ਫਿਲਟਰਿੰਗ ਬਨਾਮ ਬੰਦ ਪੋਰਟ

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

ਪੋਰਟ 443 ਉੱਤੇ TCP ਪਰੋਫਾਈਲ ਆਮ ਹੱਲ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਆਮ HTTPS ਪ੍ਰਵਾਹ ਵਰਗਾ ਦਿਖਦਾ ਹੈ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਕੈਪਟਿਵ ਪੋਰਟਲ ਅਤੇ ਬਾਹਰੀ ਫਿਲਟਰ ਪਾਰ ਕਰਦਾ ਹੈ। ਦੋ ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਸਰਵਰ ਨੂੰ proto tcp-server ਨਾਲ ਸੁਣਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ proto tcp-client ਨਾਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਆਪਰੇਟਰ ਨੂੰ ਉਹ ਵਿਕਲਪਕ ਐਂਡਪੌਇੰਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਕੰਮ ਕਰਦੇ UDP ਪਰੋਫਾਈਲ ਨੂੰ TCP 443 ਦੱਸਣ ਲਈ ਮੁੜ ਲਿਖਣਾ ਉਦੋਂ ਕੁਝ ਨਹੀਂ ਕਰਦਾ ਜਦੋਂ ਦੂਜੇ ਪਾਸੇ ਕੋਈ ਨਹੀਂ ਸੁਣਦਾ।

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

ਪੁਰਾਣੇ ਪ੍ਰੋਟੋਕੋਲ ਇਸ ਧੁਰੇ ਉੱਤੇ ਮਾੜੇ ਦਿਖਦੇ ਹਨ। PPTP ਨੂੰ TCP 1723 ਪਲੱਸ GRE ਚਾਹੀਦਾ ਹੈ, ਅਤੇ GRE ਪੋਰਟ ਨਹੀਂ, IP ਪ੍ਰੋਟੋਕੋਲ 47 ਹੈ, ਇਸ ਲਈ ਆਮ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਇਸ ਨੂੰ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰ ਸਕਦੀ।

ਜਦੋਂ ਸਵਿੱਚ ਪੈਕਟ ਛੱਡ ਰਿਹਾ ਹੋਵੇ

ਪ੍ਰਬੰਧਿਤ ਸਵਿੱਚ ਟਨਲ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਛੱਡ ਸਕਦਾ ਹੈ। ਕੁਝ HPE ਅਤੇ Aruba ਮਾਡਲ ਆਪਣੇ ਉੱਨਤ ਸੁਰੱਖਿਆ ਭਾਗ ਵਿੱਚ UDP ਫਲੱਡ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਦਿੰਦੇ ਹਨ, ਕਈ ਵਾਰ Prevent UDP Blat Attack ਲੇਬਲ ਵਾਲਾ। ਉਹ ਨਿਯੰਤਰਣ ਸਰਗਰਮ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਸਵਿੱਚ ਪਿੱਛੇ ਬੈਠਾ ਸਰਵਰ ਕਿਸੇ ਨੂੰ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ ਅਤੇ ਹਰ ਕਲਾਇੰਟ ਇਸੇ ਤਰ੍ਹਾਂ ਸਮਾਂ ਖਤਮ ਕਰਦਾ ਹੈ। ਇਸ ਨੂੰ ਹਟਾਉਣਾ ਅਤੇ ਚੱਲ ਰਹੀ ਸੰਰਚਨਾ ਸੰਭਾਲਣਾ ਹੀ ਪੂਰੀ ਮੁਰੰਮਤ ਹੈ, ਪਰ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕਿ ਸਵਿੱਚ ਸੱਚਮੁੱਚ ਮਾਰਗ ਵਿੱਚ ਹੈ।

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

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

DNS ਨਾਕਾਮੀ ਵਰਗਾ ਦਿਖਣ ਵਾਲਾ ਪਤਾ ਓਵਰਲੈਪ

10.0.0.0/8 ਦੇ ਅੰਦਰ ਨੰਬਰ ਵਾਲਾ ਪਹੁੰਚ ਨੈੱਟਵਰਕ ਟਨਲ ਪੂਲ ਨਾਲ ਓਵਰਲੈਪ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਆਮ ਤੌਰ ਤੇ ਉਸੇ ਪੂਲ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਜਦੋਂ ਲੈਪਟਾਪ ਨੂੰ Wi-Fi ਉੱਤੇ 10.184.178.50 ਵਰਗਾ ਪਤਾ /8 ਮਾਸਕ ਨਾਲ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਹਰ 10.x ਟਿਕਾਣਾ ਪਰਿਭਾਸ਼ਾ ਅਨੁਸਾਰ ਸਥਾਨਕ ਹੁੰਦਾ ਹੈ। 10.4.0.1 ਲਈ ਪੈਕਟ ਫਿਰ LAN ਵੱਲ ਜਾਂਦੇ ਹਨ, ਟਨਲ ਚਾਲੂ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਨਾਮ ਹੱਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।

ip addr ਓਵਰਲੈਪ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ip route get 10.4.0.1 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪੈਕਟ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਪਹੁੰਚਾਇਆ ਜਾਵੇਗਾ। ਕਿਉਂਕਿ ਦਿਖਣ ਵਾਲਾ ਲੱਛਣ ਰਿਜ਼ੋਲਵਰ ਨਾਕਾਮੀ ਹੈ, ਇਹ ਅਕਸਰ ਕਈ ਦੌਰ ਦੇ DNS ਬਦਲਾਵਾਂ ਤੋਂ ਬਾਅਦ ਵੀ ਬਚਦਾ ਹੈ।

ਪੂਲ ਨੂੰ ਮੁੜ ਨੰਬਰ ਦਿਓ ਜਾਂ ਉਸ ਪਹੁੰਚ ਨੈੱਟਵਰਕ ਨੂੰ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਰੱਖੋ। ਕੋਈ ਵੀ ਕਲਾਇੰਟ-ਸਾਈਡ ਸੈਟਿੰਗ ਓਵਰਲੈਪ ਤੋਂ ਸੁਧਰਦੀ ਨਹੀਂ।

TCP ਬੈਕਅੱਪ ਅਤੇ ਮਾਰਗ ਸੁਧਾਰ ਵਿਚਕਾਰ ਚੋਣ

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

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