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 เท่านั้นจะแสดงรายการ fe80:: แบบลิงก์โลคัลและไม่มีอะไรในบรรทัด inet และไคลเอนต์ที่ใช้ที่อยู่ที่ถูกดันมาไม่สำเร็จก็ทิ้งรูปร่างแบบเดียวกันไว้ ถ้าปลายทางของคุณเป็น IPv4 และอุโมงค์ไม่มีที่อยู่ IPv4 คำถามเรื่องเส้นทางก็จบแล้ว

MTU สมควรได้รับการตรวจแยก เพราะความล้มเหลวนี้ดูไม่เหมือนปัญหาเรื่องขนาด มันดูเหมือนการเชื่อมต่อที่พิสูจน์ตัวตนได้แล้วก็เงียบไปทันทีที่การถ่ายโอนก้อนใหญ่เริ่ม ส่งโพรบที่ไม่ควรถูกแบ่งส่วน ขนาดให้แพ็กเก็ตพอดีกับ MTU ของอินเทอร์เฟซ สำหรับ MTU 1400 เพย์โหลดคือ 1372 ไบต์:

ping -D -s 1372 10.8.0.5

การตอบกลับหมายความว่าแพ็กเก็ตขนาดนั้นผ่านอุโมงค์ได้ ความเงียบขณะที่ ping เล็ก ๆ สำเร็จชี้ไปที่ 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 ตัดการเชื่อมต่ออุโมงค์ และในโปรไฟล์แบบ full tunnel มันพาเซสชันระยะไกลของคุณไปด้วย ซึ่งเป็นการแลกเปลี่ยนที่แย่เมื่อคุณแค่พยายามเก็บหลักฐาน ไม่มีอะไรที่คุณต้องการตรงนี้ต้องใช้ root การอ่านแฟล็ก ที่อยู่ และตัวนับทำได้ด้วยผู้ใช้ปกติของคุณ

ทำการตรวจตามลำดับในครั้งถัดไปที่อุโมงค์บน Mac ทำงานผิดปกติ: ยืนยันว่ามี utun ปรากฏด้วย ifconfig -l อ่านแฟล็ก ที่อยู่ และ MTU ของมัน ระบุว่าเป็นของโปรเซสใด ถาม route -n get ว่าปลายทางใช้อินเทอร์เฟซไหน แล้วดู netstat -ib เคลื่อนที่ แต่ละขั้นตัดชั้นต่าง ๆ ออก และขั้นแรกที่ออกมาผิดคือจุดที่ต้องแก้