การแชร์อินเทอร์เน็ตทำให้อุปกรณ์อื่นอยู่ใน VPN หรือไม่
การแชร์เลือกอัปสตรีมและดาวน์สตรีม ไม่ใช่ทันเนล อุปกรณ์ที่สองจะได้รับ VPN ต่อหรือไม่ขึ้นอยู่กับการกำหนดเส้นทาง นโยบาย และไคลเอนต์
การเปิดการแชร์อินเทอร์เน็ตไม่ได้ขยาย VPN ไปยังทุกสิ่งบนโต๊ะของคุณ คุณสมบัติสองอย่างนี้ตอบคำถามคนละข้อ การแชร์ตัดสินว่า connection ใดเลี้ยง Mac และ interface ใดส่ง connection นั้นออกไป ขณะที่ VPN ตัดสินว่า traffic ของ Mac เองจะไปที่ใด อุปกรณ์ที่สองจะได้รับทันเนลต่อหรือไม่นั้นขึ้นอยู่กับการกำหนดเส้นทาง นโยบายของไคลเอนต์ และสิ่งที่เกตเวย์ยินดีส่งต่อ ซึ่งเป็นสามสิ่งที่แผงการแชร์ไม่รู้เลย
ความเชื่อผิด: การแชร์ connection คือการแชร์ทันเนล
เมื่อมีคนบอกว่ามันได้ผล สิ่งที่พวกเขามักสังเกตเห็นคือแท็บเล็ตหลัง Mac โหลดหน้าเว็บได้ การสังเกตนั้นสอดคล้องกับเส้นทางที่แตกต่างกันหลายแบบ รวมถึงแบบที่หน้าเว็บออกไปทาง uplink กายภาพโดยตรงขณะที่เบราว์เซอร์ของ Mac ใช้ทันเนล การโหลดหน้าสำเร็จหนึ่งครั้งไม่ได้แยกความแตกต่างใด ๆ มันพิสูจน์เพียงว่ามีเส้นทางบางอย่างอยู่
อุปกรณ์ที่สองไม่ได้รับ session ต่อ มันได้รับ address จาก Mac ส่ง packet ไปยัง Mac และ Mac ตัดสินว่าจะทำอะไรกับ packet เหล่านั้นตาม routing table ของตัวเองและสถานะ firewall ของตัวเอง การตัดสินนั้นเกิดขึ้นต่อ connection ไม่ใช่ต่ออุปกรณ์ อุปกรณ์สองเครื่องหลัง Mac เดียวกันสามารถใช้เส้นทางต่างกันได้เมื่อกฎต่างกัน
สิ่งที่แผงการแชร์เลือกจริง ๆ
ใน System Settings ตัวควบคุมการแชร์อินเทอร์เน็ตถามหา connection ต้นทางและ interface ที่อุปกรณ์อื่นจะใช้ ต้นทางคือ uplink ของ Mac และคู่มือของ Apple เองเตือนว่า การแชร์อย่างไม่ระวังอาจรบกวน network ที่คุณเชื่อมต่ออยู่
ไม่มีสิ่งใดในไดอะล็อกนั้นระบุ VPN เป็นเกตเวย์สำหรับ traffic ที่ส่งต่อ การเลือก Ethernet เป็นต้นทางไม่ได้หมายความว่าทันเนลถูกเพิกเฉย และไม่ได้หมายความว่าทันเนลถูกใช้เช่นกัน มันหมายความว่า interface กายภาพของ Mac คือ uplink ที่ประกาศไว้ และ routing table ยังคงเป็นตัวตัดสิน
ตัวเลือกที่มีให้ยังขึ้นอยู่กับฮาร์ดแวร์ด้วย Mac ที่ไม่มีพอร์ต Ethernet หรือเครื่องที่ไม่ได้ต่อ dock จะไม่เสนอตัวเลือกที่บทช่วยสอนคาดไว้ ตรวจสอบแผงที่คุณมีจริงก่อนออกแบบสิ่งใดรอบ ๆ มัน
packet ที่ถูกส่งต่อหาเส้นทางของมันอย่างไร
อุปกรณ์ปลายน้ำถูกซ่อนอยู่หลัง NAT และ Mac เขียน address ของมันใหม่ก่อนส่งสิ่งใดขึ้นต้นทาง หากในขณะนั้นทันเนลถือ default route อยู่ packet ที่เขียนใหม่ก็อาจผ่านมันไปได้ ซึ่งเป็นเหตุให้การจัดวางดูเหมือนได้ผลในการทดสอบเร็ว ๆ
รูปลักษณ์ไม่ใช่นโยบาย ไคลเอนต์ VPN บนเดสก์ท็อปถูกสร้างขึ้นรอบ traffic ของ Mac เอง และ kill switch ของมันมักบังคับใช้กฎสำหรับแอปพลิเคชันในเครื่องมากกว่า LAN ที่อยู่หลังเครื่อง เมื่อทันเนลล่ม Mac อาจส่งต่อให้แขกของมันต่อไปได้โดยไม่มีกฎบล็อกใด ๆ
ยังมีคำถามเรื่องเวอร์ชัน ผู้ให้บริการที่เคยเขียนเอกสารรองรับการแชร์บน macOS รุ่นเก่าอาจเปลี่ยนพฤติกรรมไปแล้ว และบทช่วยสอนที่แสดงรายการ VPN แบบเนทีฟในรายการต้นทางอาจอธิบาย interface ที่ไคลเอนต์ปัจจุบันของคุณไม่เคยสร้าง
ดังนั้นจงทดสอบเส้นทางแทนการเชื่อมั่นในการออกแบบ รันคำขอจากอุปกรณ์ที่สองและดูทั้งสองปลาย เพราะนั่นคือหลักฐานเดียวที่อยู่รอดหลังการอัปเดตไคลเอนต์ การทดสอบที่คุณทำซ้ำได้หลังการอัปเดตครั้งต่อไปมีค่ามากกว่าการตั้งค่าที่คุณเพียงเชื่อ
เลือกขอบเขตความครอบคลุมอย่างตั้งใจ
หากอุปกรณ์ที่สองรันไคลเอนต์ที่ได้รับอนุมัติได้ นั่นคือการจัดวางที่แข็งแรงกว่า มันได้โปรไฟล์ของตัวเอง ตัวตนของตัวเอง และนโยบายของตัวเอง และ Mac เพียงจัดหา network ที่รองรับ
หากมันรันไคลเอนต์ไม่ได้ คุณต้องมีฟีเจอร์การแชร์ที่ผู้ให้บริการ VPN เขียนเอกสารไว้ หรือเกตเวย์ที่ได้รับอนุมัติซึ่งส่งต่อในนามของอุปกรณ์ ทั้งสองมาพร้อมเจ้าของและจุดสิ้นสุดที่กำหนดไว้ ซึ่งมากกว่าที่ checkbox ให้ได้
นายจ้างมักกำหนดโมเดลต่ออุปกรณ์อยู่แล้ว เพราะ session ของเครื่องหนึ่งแทนอีกสี่เครื่องเป็นการตัดสินใจเรื่องความเชื่อถือที่ต่างจากการลงทะเบียนอุปกรณ์สี่เครื่อง
สิ่งที่ต้องตรวจสอบก่อนให้สัญญา
ตรวจสอบปลายทางจริงของอุปกรณ์ที่สอง ไม่ใช่ของ Mac บริการส่วนตัวและทางออกสาธารณะเป็นการทดสอบที่ต่างกัน และการผ่านอย่างหนึ่งไม่ได้บอกอะไรเกี่ยวกับอีกอย่าง
ตรวจสอบทั้งสองตระกูล address และการแปลงชื่อ การตั้งค่าที่ tunnelling IPv4 ไว้ขณะปล่อย IPv6 ไว้บนลิงก์กายภาพทำให้เกิดอุปกรณ์ที่ดูเหมือนได้รับการปกป้องในเบราว์เซอร์และรั่วในทุกอย่างอื่น
จากนั้นตรวจสอบสถานะที่ตัดการเชื่อมต่อ ปิดทันเนลและทำการทดสอบซ้ำจากอุปกรณ์ที่สอง หากมันยังเข้าถึงอินเทอร์เน็ตได้ การจัดวางนั้นเป็นการแชร์ connection และไม่เคยแชร์ VPN ซึ่งเป็นผลลัพธ์ที่ดีตราบใดที่ไม่มีใครเขียนมันลงไปว่าเป็นอีกอย่าง