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-ით ამოდის, 1380 macOS-ის რამდენიმე ბილდში, და კლიენტმა შეიძლება გადააჭარბოს მას. ველების სია საკმარისად მოკლეა, რომ ერთხელ გადაავლოთ თვალი ifconfig-ის სახელმძღვანელოს, რომელსაც Apple აყოლებს.

იპოვეთ პროცესი ინტერფეისის უკან

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 პროფილი აჩვენებს link-local fe80:: ჩანაწერს და არაფერს inet ხაზში, და კლიენტი, რომელმაც ვერ გამოიყენა მიწოდებული მისამართი, ზუსტად იგივე ფორმას ტოვებს. თუ თქვენი დანიშნულება IPv4-ია და ტუნელს IPv4 მისამართი არ აქვს, მარშრუტიზაციის საკითხი უკვე გადაწყვეტილია.

MTU ცალკე შემოწმებას იმსახურებს, რადგან ეს წარუმატებლობა ზომის პრობლემად არ გამოიყურება. ის გამოიყურება როგორც კავშირი, რომელიც ავთენტიფიცირდება და შემდეგ ჩუმდება, როგორც კი დიდი გადაცემა იწყება. გაგზავნეთ პრობა, რომელიც არ უნდა ფრაგმენტდეს, ისე ზომით, რომ პაკეტი ინტერფეისის MTU-ს შეესაბამებოდეს; 1400 MTU-სთვის დატვირთვა 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 მალავს მას. შეამოწმეთ კლიენტის საკუთარი სტატუსი, შემდეგ სისტემისა: Network Extension, რომელიც არასდროს დამტკიცდა ან რომელიც macOS-მა განახლების შემდეგ გამორთო, ინტერფეისს არ ტოვებს. დამტკიცება ცხოვრობს System Settings-ში, Login Items & Extensions-ის ქვეშ, და იქ არსებული მოძველებული ჩანაწერი ღირს ხელახლა გადართვად, სანამ რამეს ხელახლა დააყენებთ.

utun-ის ნუმერაცია არ არის სტაბილური ხელახალი დაკავშირებებისას. შეიძლება მიიღოთ utun5 იქ, სადაც utun4 ათი წუთის წინ არსებობდა, რადგან ძველი ინტერფეისი იშლება და ბირთვი გასცემს შემდეგ თავისუფალ ინდექსს. სკრიპტები, რომლებიც სახელს მყარად წერენ, ჩუმად ტყდება იმ მომენტში; შეადარეთ მისამართს ან მარშრუტს.

წაკითხვის მხარე მხოლოდ-წასაკითხად დატოვეთ. sudo ifconfig utun4 down ტუნელს წყვეტს და სრული ტუნელის პროფილზე თქვენს დისტანციურ სეანსსაც წაიღებს, რაც ცუდი გარიგებაა, როცა მხოლოდ მტკიცებულებების შეგროვებას ცდილობდით. აქ არაფერი მოითხოვს root-ს: დროშების, მისამართებისა და მრიცხველების წაკითხვა თქვენი ჩვეულებრივი მომხმარებლით მუშაობს.

შემდეგ ჯერზე, როცა Mac-ის ტუნელი ცუდად მოიქცევა, შემოწმებები რიგზე შეასრულეთ: დაადასტურეთ, რომ utun გამოჩნდა ifconfig -l არგუმენტით, წაიკითხეთ მისი დროშები, მისამართები და MTU, მიაკუთვნეთ ის პროცესს, ჰკითხეთ route -n get რომელ ინტერფეისს იყენებს დანიშნულება, შემდეგ დააკვირდით netstat -ib მოძრაობას. ყოველი ნაბიჯი გამორიცხავს სხვადასხვა შრეს, და პირველი, რომელიც არასწორად ბრუნდება, არის ის ადგილი, სადაც გასწორება უნდა მოხდეს.