Mac VPN utun ਇੰਟਰਫ਼ੇਸ ਚਾਲੂ ਹੈ ਪਰ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਜਾਂਦਾ? ifconfig ਵੇਖੋ

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

utun ਲਾਈਨ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ

ਪੂਰੀ ਤਸਵੀਰ ਚਾਹੀਦੀ ਹੋਵੇ ਤਾਂ ifconfig -a ਚਲਾਓ। ਬਿਨਾਂ ਆਰਗਿਊਮੈਂਟ ਬੁਲਾਉਣ 'ਤੇ, ifconfig ਸਿਰਫ਼ ਉਹ ਇੰਟਰਫ਼ੇਸ ਛਾਪਦਾ ਹੈ ਜੋ ਹੁਣ ਚਾਲੂ ਹਨ, ਇਸ ਲਈ ਸ਼ੁਰੂ ਨਾ ਹੋ ਸਕਿਆ ਟਨਲ ਲੋਕ ਟਿਕਟਾਂ ਵਿੱਚ ਚਿਪਕਾਉਂਦੇ ਆਉਟਪੁੱਟ ਵਿੱਚੋਂ ਗੁੰਮ ਹੋ ਸਕਦਾ ਹੈ। ifconfig -l ਸਿਰਫ਼ ਨਾਮ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੋੜਨ ਤੋਂ ਬਾਅਦ ਨਵਾਂ utun ਆਇਆ ਜਾਂ ਨਹੀਂ ਇਹ ਜਾਣਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹੀ ਹੈ।

ਇੱਕ ਇੰਟਰਫ਼ੇਸ ਪੜ੍ਹਨਾ ਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਲਾਭਦਾਇਕ ਵੇਰਵਾ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਜੁੜਿਆ ਟਨਲ ਆਮ ਤੌਰ 'ਤੇ ਇੰਝ ਦਿਸਦਾ ਹੈ।

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

ਤਿੰਨ ਖੇਤਰ ਜਵਾਬ ਲੈ ਕੇ ਚੱਲਦੇ ਹਨ। UP ਅਤੇ RUNNING ਕਹਿੰਦੇ ਹਨ ਕਿ ਕਰਨਲ ਇੰਟਰਫ਼ੇਸ ਵਰਤਣ ਲਈ ਤਿਆਰ ਹੈ। POINTOPOINT ਨਾਲ --> ਪੀਅਰ ਪਤਾ ਭੌਤਿਕ ਲਿੰਕ ਨਹੀਂ, ਟਨਲ ਦਾ ਦਸਤਖਤ ਹੈ। mtu ਮੁੱਲ "ਜੁੜਦਾ ਹੈ, ਫਿਰ ਅਟਕ ਜਾਂਦਾ ਹੈ" ਵਾਲੀਆਂ ਰਿਪੋਰਟਾਂ ਦੀ ਪੂਰੀ ਸ਼੍ਰੇਣੀ ਸਮਝਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ utun ਇੰਟਰਫ਼ੇਸ ਆਮ ਤੌਰ 'ਤੇ ਘਟੇ MTU ਨਾਲ ਉੱਠਦੇ ਹਨ, ਕਈ macOS ਬਿਲਡਾਂ ਵਿੱਚ 1380, ਅਤੇ ਕਲਾਇੰਟ ਇਸਨੂੰ ਲੰਘ ਸਕਦਾ ਹੈ। ਖੇਤਰਾਂ ਦੀ ਸੂਚੀ ਇੱਕ ਵਾਰ ਵੇਖਣ ਲਈ ਕਾਫ਼ੀ ਛੋਟੀ ਹੈ, Apple ਵੱਲੋਂ ਦਿੱਤੇ ifconfig ਦਸਤਾਵੇਜ਼ ਵਿੱਚ।

ਇੰਟਰਫ਼ੇਸ ਪਿੱਛੇ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲੱਭੋ

ifconfig ਨੂੰ ਮਾਲਕ ਐਪ ਦੀ ਧਾਰਨਾ ਨਹੀਂ। ਦੋ VPN ਕਲਾਇੰਟ, ਇੱਕ ਸਿਸਟਮ ਸੇਵਾ ਅਤੇ ਪਿਛਲੇ ਹਫ਼ਤੇ ਦਾ ਬਾਕੀ ਟਨਲ ਸਾਰੇ ਇਸ ਪੱਧਰ 'ਤੇ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਣ ਵਾਲੀਆਂ ਐਂਟਰੀਆਂ ਬਣਾਉਂਦੇ ਹਨ। ਮੇਰੇ Mac 'ਤੇ ਵੀ, utun0 ਤੋਂ utun3 ਤੱਕ ਕੁਝ ਵੀ ਸੰਰਚਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਸਨ; Continuity ਅਤੇ iCloud Private Relay ਵੀ ਟਨਲ ਵਰਤਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਉਹ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਜਾਂਚ ਰਹੇ ਹੋ।

ਉਹਨਾਂ ਟਨਲਾਂ ਲਈ ਜੋ ਸਿਸਟਮ ਵਿੱਚ ਸੰਰਚਨਾ ਦਰਜ ਕਰਦੇ ਹਨ, scutil --nc list ਸਭ ਤੋਂ ਤੇਜ਼ ਸਬੰਧ ਹੈ, ਇਹ ਹਰ ਸੰਰਚਨਾ ਨੂੰ ਇਸਦੀ ਸਥਿਤੀ ਅਤੇ ਸੇਵਾ ID ਨਾਲ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਜੁੜੀ ਹੋਈ ਅਜਿਹੀ ਚਿੰਨ੍ਹਿਤ ਹੁੰਦੀ ਹੈ।

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

ਜੋ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਦਰਜ ਕਰਨ ਦੀ ਥਾਂ ਆਪਣੀ ਟਨਲ ਪ੍ਰਕਿਰਿਆ ਚਲਾਉਂਦੇ ਹਨ ਉਹ ਕਦੇ ਉੱਥੇ ਨਹੀਂ ਦਿਸਦੇ। Tunnelblick ਅਤੇ ਕਮਾਂਡ ਲਾਈਨ openvpn ਵਾਲਾ ਨਮੂਨਾ ਉਸ ਗਰੁੱਪ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਕਿਰਿਆ ਸਾਰਣੀ ਵੀ ਵੇਖੋ: ps -Ao pid,comm | grep -i openvpn। ਜਦੋਂ ਪ੍ਰਕਿਰਿਆ ਟਨਲ ਦੀ ਮਾਲਕ ਹੋ ਜਾਂਦੀ ਹੈ, utun ਨੰਬਰ ਸਿਰਫ਼ ਉਸ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕਿਸੇ ਦਾ ਨਹੀਂ।

ਰੂਟ ਜਾਂਚਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਜਾਂਚੋ

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

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

ping -D -s 1372 10.8.0.5

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

ਸਾਬਤ ਕਰੋ ਕਿ ਟਿਕਾਣਾ ਟਨਲ ਚੁਣਦਾ ਹੈ

ਅਹਿਮ ਸਵਾਲ utun4 ਹੋਣ ਦਾ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਕਿ ਇੱਕ ਖਾਸ ਪਤੇ ਵੱਲ ਟ੍ਰੈਫਿਕ ਇਸ ਵਿੱਚੋਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। route -n get ਇੱਕ ਟਿਕਾਣੇ ਲਈ ਇਸਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਵਰਤਣ ਵਾਲਾ ਗੇਟਵੇ ਅਤੇ ਇੰਟਰਫ਼ੇਸ ਛਾਪਦਾ ਹੈ:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

ਜੇ ਉਹੀ ਕਮਾਂਡ en0 ਦੱਸਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ split tunneling ਸੰਰਚਨਾ ਉਹ ਕਰ ਰਹੀ ਹੈ ਜੋ ਉਸਨੂੰ ਕਿਹਾ ਗਿਆ ਸੀ ਅਤੇ ਇੰਟਰਫ਼ੇਸ ਦੀ ਕਿੰਨੀ ਵੀ ਜਾਂਚ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲੇਗੀ। netstat -rn -f inet ਵਰਤੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਡਿਫ਼ਾਲਟ ਰੂਟ ਅਤੇ ਪੂਰੀ ਸਾਰਣੀ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਚਾਹੀਦੀ ਹੋਵੇ।

ਪੈਕੇਟ ਸੱਚਮੁੱਚ ਹਿਲਦੇ ਹਨ ਜਾਂ ਨਹੀਂ ਇਹ ਕਾਊਂਟਰ ਤੈਅ ਕਰਦੇ ਹਨ। netstat -ib utun ਐਂਟਰੀਆਂ ਸਮੇਤ ਹਰ ਇੰਟਰਫ਼ੇਸ ਦੇ ਪੈਕੇਟ ਅਤੇ ਬਾਈਟ ਜੋੜ ਦੱਸਦਾ ਹੈ; ਸੰਖਿਆਵਾਂ ਸੰਚਿਤ ਹਨ, ਇਸ ਲਈ ਵਿਰਾਮ ਨਾਲ ਦੋ ਵਾਰ ਪੜ੍ਹੋ ਅਤੇ ਤੁਲਨਾ ਕਰੋ:

netstat -ib | grep utun4

ਐਪ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ ਪਰ ਕਾਊਂਟਰ ਥਿਰ ਹਨ ਤਾਂ ਕਰਨਲ ਨੇ ਕਦੇ ਵੀ ਪੈਕੇਟ ਇੰਟਰਫ਼ੇਸ ਨੂੰ ਨਹੀਂ ਦਿੱਤਾ। ਐਪ ਅਜੇ ਵੀ ਅਸਫਲ ਹੁੰਦੀ ਹੈ ਪਰ ਕਾਊਂਟਰ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਵਧਦੇ ਹਨ ਤਾਂ ਜਾਂਚ ਟਨਲ ਦੇ ਪਾਰਲੇ ਸਿਰੇ ਵੱਲ ਤੁਰ ਪੈਂਦੀ ਹੈ।

ਜਦੋਂ utun ਬਿਲਕੁਲ ਨਹੀਂ ਦਿਸਦਾ

ਸਫਲ ਦਿਸਣ ਵਾਲੇ ਲਾਗਇਨ ਤੋਂ ਬਾਅਦ ਇੰਟਰਫ਼ੇਸ ਸੂਚੀ ਖਾਲੀ ਹੋਵੇ ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਟਨਲ ਸ਼ੁਰੂ ਹੀ ਨਹੀਂ ਹੋਇਆ, ifconfig ਇਸਨੂੰ ਲੁਕਾ ਰਿਹਾ ਨਹੀਂ। ਕਲਾਇੰਟ ਦੀ ਆਪਣੀ ਸਥਿਤੀ ਵੇਖੋ, ਫਿਰ ਸਿਸਟਮ ਦੀ: ਕਦੇ ਮਨਜ਼ੂਰ ਨਾ ਹੋਇਆ ਜਾਂ ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ macOS ਵੱਲੋਂ ਬੰਦ ਕੀਤਾ Network Extension ਪਿੱਛੇ ਕੋਈ ਇੰਟਰਫ਼ੇਸ ਨਹੀਂ ਛੱਡਦਾ। ਮਨਜ਼ੂਰੀ System Settings ਵਿੱਚ, Login Items & Extensions ਹੇਠ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਉੱਥੇ ਪਈ ਪੁਰਾਣੀ ਐਂਟਰੀ ਕੁਝ ਵੀ ਦੁਬਾਰਾ ਇੰਸਟਾਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਵਾਰ ਦੁਬਾਰਾ ਟੌਗਲ ਕਰਨ ਯੋਗ ਹੈ।

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

ਪੜ੍ਹਨ ਵਾਲਾ ਪਾਸਾ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਰੱਖੋ। sudo ifconfig utun4 down ਟਨਲ ਵਿੱਚ ਰੁਕਾਵਟ ਪਾਉਂਦਾ ਹੈ, ਅਤੇ ਪੂਰੇ-ਟਨਲ ਪ੍ਰੋਫ਼ਾਈਲ 'ਤੇ ਇਹ ਤੁਹਾਡਾ ਰਿਮੋਟ ਸੈਸ਼ਨ ਵੀ ਲੈ ਜਾਂਦਾ ਹੈ, ਜੋ ਸਿਰਫ਼ ਸਬੂਤ ਇਕੱਠੇ ਕਰਦਿਆਂ ਮਾੜਾ ਸੌਦਾ ਹੈ। ਇੱਥੇ ਲੋੜੀਂਦੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਲਈ root ਨਹੀਂ ਚਾਹੀਦਾ: ਫਲੈਗ, ਪਤੇ ਅਤੇ ਕਾਊਂਟਰ ਪੜ੍ਹਨਾ ਤੁਹਾਡੇ ਆਮ ਉਪਭੋਗਤਾ ਨਾਲ ਚੱਲਦਾ ਹੈ।

ਅਗਲੀ ਵਾਰ Mac ਟਨਲ ਗਲਤ ਵਿਵਹਾਰ ਕਰੇ ਤਾਂ ਜਾਂਚਾਂ ਕ੍ਰਮ ਨਾਲ ਕਰੋ: ifconfig -l ਨਾਲ utun ਆਇਆ ਜਾਂ ਨਹੀਂ ਪੱਕਾ ਕਰੋ, ਇਸਦੇ ਫਲੈਗ, ਪਤੇ ਅਤੇ MTU ਪੜ੍ਹੋ, ਇਸਨੂੰ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਜੋੜੋ, route -n get ਨੂੰ ਪੁੱਛੋ ਕਿ ਟਿਕਾਣਾ ਕਿਹੜਾ ਇੰਟਰਫ਼ੇਸ ਵਰਤਦਾ ਹੈ, ਫਿਰ netstat -ib ਦੀ ਚਾਲ ਵੇਖੋ। ਹਰ ਕਦਮ ਵੱਖਰੀ ਪਰਤ ਹਟਾਉਂਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਗਲਤ ਆਉਣ ਵਾਲੀ ਥਾਂ ਹੀ ਸੁਧਾਰ ਦੀ ਥਾਂ ਹੈ।