macOS ’ਤੇ OpenVPN TAP: ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਦੀ ਜਾਂਚ ਕਰੋ

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

ਕਦਮ 1: ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪ੍ਰੋਫਾਈਲ ਸੱਚਮੁੱਚ TAP ਮੰਗਦਾ ਹੈ

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

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

ਜੇ ਫਾਈਲ ਵਿੱਚ dev tap ਜਾਂ dev tap0 ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਨੂੰ TAP ਇੰਟਰਫੇਸ ਲਾਗੂ ਕਰਨਾ ਪਵੇਗਾ। ਜੇ ਇਸ ਵਿੱਚ dev tun ਹੈ, ਤਾਂ ਇਸ ਲੇਖ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਖਰਾਬੀ ਕਿਤੇ ਹੋਰ ਹੈ।

ਕਲਾਇੰਟ ਦਾ ਨਾਮ ਅਤੇ ਸੰਸਕਰਣ, macOS ਸੰਸਕਰਣ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਕਿੱਥੋਂ ਆਇਆ, ਲਿਖ ਲਓ। ਇਹ ਤਿੰਨ ਤੱਥ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਹੇਠਾਂ ਦਿੱਤੇ ਦੋ ਰਾਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਰਾਹ ਸੰਭਵ ਵੀ ਹੈ।

ਕਦਮ 2: ਜਾਣੋ ਕਿ ਡਿਵਾਈਸ ਮੋਡ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ

TUN ਇੰਟਰਫੇਸ IP ਪੈਕੇਟ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ। ਕਲਾਇੰਟ IP ਸਾਥੀ ਨੂੰ ਭੇਜੇ ਪੈਕੇਟ ਪੜ੍ਹਦਾ ਅਤੇ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਉਹਨਾਂ ਨੂੰ ਕਿਸੇ ਹੋਰ ਇੰਟਰਫੇਸ ਵਾਂਗ ਰੂਟ ਕਰਦਾ ਹੈ।

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

ਕੀਮਤ ਇਹ ਹੈ ਕਿ TAP ਨੂੰ ਇੱਕ ਡਰਾਈਵਰ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸਿਸਟਮ ਨੂੰ Ethernet ਇੰਟਰਫੇਸ ਦਿਖਾਵੇ। Apple ਨੇ ਉਹ ਕਰਨਲ ਐਕਸਟੈਂਸ਼ਨ ਮਾਡਲ ਬੰਦ ਕਰ ਦਿੱਤਾ ਹੈ ਜਿਸ ਉੱਤੇ ਪੁਰਾਣੇ Mac TAP ਡਰਾਈਵਰ ਨਿਰਭਰ ਸਨ, ਅਤੇ ਉਸਦਾ ਬਦਲਵਾਂ API ਉਹਨਾਂ ਕਲਾਇੰਟਾਂ ਵਿੱਚ ਜਾਦੂਈ ਢੰਗ ਨਾਲ ਨਹੀਂ ਆਉਂਦਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਦੇ ਇਸਨੂੰ ਵਰਤਣ ਲਈ ਅੱਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ। ਪਲੇਟਫਾਰਮ ਦੀ ਸਮਰੱਥਾ ਅਤੇ ਭੇਜਿਆ ਉਤਪਾਦ ਦੋ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ।

ਕਦਮ 3: ਅਨੁਕੂਲ ਕਲਾਇੰਟ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵਿੱਚੋਂ ਚੁਣੋ

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

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

ਜੋ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਉਹ ਹੈ ਆਪਣੀ ਸਥਾਨਕ ਕਾਪੀ ਵਿੱਚ tap ਨੂੰ tun ਬਣਾਉਣਾ ਅਤੇ ਆਸ ਕਰਨਾ। ਸਰਵਰ ਅਜੇ ਵੀ ਬ੍ਰਿਜ ਕਰ ਰਿਹਾ ਹੈ, ਕਲਾਇੰਟ ਹੁਣ IP ਬੋਲਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਵੀ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।

ਕਦਮ 4: ਚੱਲ ਰਹੀ ਸੇਵਾ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਤੱਥ ਇਕੱਠੇ ਕਰੋ

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

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

ਇਹਨਾਂ ਦੇ ਜਵਾਬ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਅੱਜ ਦੁਪਹਿਰ ਕਲਾਇੰਟ ਦੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਅਗਲੇ ਹਫ਼ਤੇ ਨੈੱਟਵਰਕ ਬਦਲਾਅ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹੋ।

ਕਦਮ 5: ਦੋਵੇਂ ਸਿਰਿਆਂ ਤੋਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

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

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

ਜੇ ਫਿਰ ਵੀ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਪਹਿਲੀ ਗਲਤੀ ਪੜ੍ਹੋ

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

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