ನೀವು 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 ಚಲನೆಯನ್ನು ಗಮನಿಸಿ. ಪ್ರತಿ ಹೆಜ್ಜೆ ಬೇರೆ ಪದರವನ್ನು ತಳ್ಳಿಹಾಕುತ್ತದೆ, ಮತ್ತು ಮೊದಲು ತಪ್ಪಾಗಿ ಬಂದದ್ದೇ ಸರಿಪಡಿಸಬೇಕಾದ ಸ್ಥಳ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು