AirDrop หายเมื่อเปิด VPN? ตรวจสอบเส้นทางในเครื่อง
VPN ที่พาการรับส่งอินเทอร์เน็ตยังทำให้การค้นพบ AWDL เสียหายหรือซ่อนเครือข่ายย่อยในเครื่องได้ ตรวจสอบรูปร่างของเส้นทางและนโยบายของไคลเอนต์ก่อนแตะตัวกรอง
AirDrop ทำงาน จากนั้น VPN เชื่อมต่อ และ Mac หรือ iPhone อีกเครื่องหายไปจากแผ่นแชร์ ไม่มีอะไรในบันทึก VPN พูดถึงการค้นพบ เพราะความล้มเหลวมักเกี่ยวกับการเข้าถึงในเครื่องมากกว่าการเข้ารหัส หน้าสนับสนุนของ Apple ยอมรับว่าการตั้งค่า VPN ที่จำกัดเครือข่ายในเครื่องอาจรบกวน Continuity และ AirDrop นี่เป็นเบาะแสที่มีประโยชน์ ไม่ใช่การวินิจฉัย เริ่มด้วยการตรวจสอบราคาถูก จากนั้นอ่านตารางเส้นทาง และถือว่าสวิตช์การเข้าถึงในเครื่องเป็นการตัดสินใจเกี่ยวกับความเป็นส่วนตัวของคุณ ไม่ใช่ค่าตั้งต้นที่ต้องสลับ.
อะไรเสียก่อนที่อุโมงค์จะเข้ามาเกี่ยวข้อง
อุปกรณ์ทั้งสองต้องเปิด Wi-Fi หรือ Bluetooth ไว้ AirDrop ต้องรับจากรายชื่อติดต่อหรือจากทุกคนภายในหน้าต่างการรับ และบัญชีทั้งสองต้องค้นพบกันได้ การตั้งเครื่องรับเป็นทุกคนเป็นเวลาสิบนาทีเป็นการทดลองที่ชอบด้วยเหตุผล หากอุปกรณ์อีกเครื่องปรากฏที่นั่น แสดงว่าการตั้งค่าเป็นปัญหาและอุโมงค์ไม่ผิด ทดสอบกับผู้รับที่รู้จักแทนการตัดสินจากสิ่งที่แผ่นแชร์เสนอให้
เบราว์เซอร์ที่โหลดหน้าเว็บได้พิสูจน์ว่าเส้นทางอินเทอร์เน็ตทำงาน ไม่ได้พิสูจน์ว่าการค้นพบในเครื่องทำงาน ปล่อยอุปกรณ์ทั้งสองและจุดที่คุณยืนอยู่ไว้ไม่เปลี่ยน จากนั้นเปิดและปิด VPN แล้วสังเกตว่าอุปกรณ์อีกเครื่องหายไปเฉพาะตอนที่อุโมงค์ขึ้นหรือไม่ หากการค้นพบตายไปพร้อมอุโมงค์และกลับมาเมื่อไม่มีอุโมงค์ แสดงว่าอุโมงค์คือตัวแปร และส่วนที่เหลือของรายการนี้ใช้ได้ หากล้มเหลวทั้งสองสถานะ เงื่อนไขเบื้องต้นต้องผ่านอีกรอบก่อนจะเปลี่ยนนโยบายเครือข่ายใด ๆ
แผ่นแชร์ว่างเปล่าเมื่อเส้นทางเริ่มต้นเคลื่อนที่
ไคลเอนต์อุโมงค์เต็มรูปแบบมักติดตั้งเส้นทางเริ่มต้นผ่านอุโมงค์พร้อมเส้นทางครึ่งสองเส้นที่ดักจุดหมายส่วนใหญ่ เครือข่ายย่อยในเครื่องจะอยู่รอดได้ในการจัดวางนั้นก็ต่อเมื่อมี เส้นทางที่เจาะจงกว่า มิฉะนั้นมันจะหายเข้าไปในอุโมงค์ ตัว AirDrop เองวิ่งผ่านอินเทอร์เฟซ AWDL ดังนั้นไคลเอนต์ที่กรองหรือกำหนดเส้นทางอินเทอร์เฟซในเครื่องอย่างรุนแรงอาจรบกวนได้แม้เส้นทางอินเทอร์เน็ตจะสมบูรณ์ สี่คำสั่งครอบคลุมอินเทอร์เฟซ เส้นทาง การเชื่อมต่อที่ใช้งาน และตัวกรองแพ็กเก็ต
ifconfig awdl0 | grep -E "status|inet"
netstat -rn | grep -E '^default|^0/1|^128.0/1|awdl'
scutil --nc list
sudo pfctl -s rules | head -40อ่านบรรทัดเริ่มต้นก่อน หากชี้ไปที่อินเทอร์เฟซ utun และไม่มีเส้นทางที่เจาะจงกว่าครอบเครือข่ายย่อยของคุณ การรับส่งในเครื่องจะเข้าไปในอุโมงค์และความรับรู้ก็หายไปด้วย คู่ 0/1 และ 128.0/1 เป็นรูปแบบอุโมงค์เต็มที่พบบ่อย เพราะเส้นทางเหล่านั้นชนะเส้นทางเริ่มต้นจริงโดยไม่แทนที่มัน บรรทัด awdl0 ที่แสดงสถานะใช้งานและที่อยู่ตัดความเป็นไปได้ที่อินเทอร์เฟซเพื่อนจะล่ม เมื่อทั้งสามดูปกติ ข้อจำกัดมาจากนโยบายไคลเอนต์หรือตัวกรองบนโฮสต์ ไม่ใช่จากตารางเส้นทาง
รูปแบบหนึ่งน่าพูดถึง เพราะมันจับคนในเครือข่ายแขก และไม่ใช่เส้นทางครึ่ง DHCP ติดตั้งที่อยู่ที่คุณเพิ่งได้รับเป็นเส้นทางบนลิงก์ และรายการนั้นเจาะจงกว่าครึ่งใดก็ตาม เครือข่ายย่อยของแขกจึงผ่านอุโมงค์ได้เหมือนเครือข่ายที่บ้าน สิ่งที่เอาออกคือ นโยบาย ไม่ใช่การกำหนดเส้นทาง: การตั้งค่าที่บล็อกเครือข่ายในเครื่องและใส่กฎปฏิเสธ ตัวกรองบนโฮสต์ที่ทิ้งเครือข่ายย่อย หรือสิทธิ์เครือข่ายในเครื่องของ macOS สำหรับไคลเอนต์ ตารางที่ดูปกติพร้อมแผ่นแชร์ที่ตายแล้วจึงเป็นลายเซ็นของส่วนถัดไป ไม่ใช่รูปร่างของเส้นทาง
Mac ที่ถูกจัดการอาจไม่เสนอสวิตช์การเข้าถึงในเครื่อง
ไคลเอนต์หลายตัวแสดงการตั้งค่าที่อนุญาตให้เข้าถึงเครือข่ายในเครื่องขณะอุโมงค์ขึ้น แต่การตั้งค่านั้นถูกบังคับใช้โดยไคลเอนต์และโดยโปรไฟล์การจัดการ จึงอาจถูกล็อก ซ่อน หรือถูกเขียนทับบน Mac ที่ถูกจัดการ กฎไฟร์วอลล์บนโฮสต์หรือเอเจนต์ความปลอดภัยอาจบล็อกการรับส่งระหว่างเพื่อนไม่ว่าอุโมงค์จะเสนออะไร มองหาสวิตช์ก่อนสรุปว่ามันไม่ได้ทำอะไร สวิตช์นั้นอยู่ในค่ากำหนดของไคลเอนต์เอง ไม่ใช่ในการตั้งค่าเครือข่ายของ macOS จึงเป็นเหตุผลที่ไคลเอนต์ที่แผงไม่แสดงสวิตช์มักถูกกำกับโดยโปรไฟล์การจัดการ
การเอาการจัดการออกหรือปิดทุกตัวกรองเพื่อให้ผู้รับหนึ่งรายปรากฏ เป็นการแลกการตั้งค่าที่ควบคุมได้กับสิ่งที่ไม่รู้จัก เปิดตัวเลือกการเข้าถึงในเครื่องเฉพาะเมื่อตรงกับนโยบายที่คุณทำงานภายใต้ และปิดไว้ในเครือข่ายแขกที่ไม่มีใครต้องการการค้นพบในเครื่อง
พิสูจน์ด้วยไฟล์ ไม่ใช่ด้วยไอคอน
หลังจากเปลี่ยนเส้นทางหรือนโยบาย ให้ส่งไฟล์จริงไปยังผู้รับที่ตั้งใจและยืนยันว่าการถ่ายโอนเสร็จสมบูรณ์ ชื่อที่ปรากฏบนแผ่นคือการค้นพบ และการกลับมาของการค้นพบไม่เหมือนกับการถ่ายโอนที่เสร็จแล้ว
หากอุปกรณ์ยังไม่ปรากฏ ให้เทียบอุปกรณ์คู่อื่นในเครือข่ายเดียวกันเพื่อแยกปัญหาของโฮสต์ออกจากปัญหาทั้งเครือข่าย การเทียบนั้นเร็วกว่าการสลับตัวเลือก VPN ทีละตัว และให้ข้อเท็จจริงสำหรับตั๋ว บันทึกอินเทอร์เฟซเริ่มต้น รูปร่างของเส้นทาง และสถานะของสวิตช์การเข้าถึงในเครื่องไว้ขณะที่ความล้มเหลวเกิดขึ้นซ้ำได้ มิฉะนั้นคนถัดไปจะทำการตรวจทั้งสี่ซ้ำตั้งแต่ต้น