สิ่งที่เครือข่ายท้องถิ่นยังเห็นผ่าน VPN ของคุณ

ทุกครั้งที่มีคนถามว่า VPN ซ่อนทราฟฟิกของตนหรือไม่ ผู้สังเกตสามฝ่ายจะรวมเป็นคำถามเดียว คือ เครือข่ายที่เชื่อมต่ออยู่ เครื่องที่อยู่ในมือ และผู้ดำเนินการอุโมงค์ แต่ละฝ่ายเรียนรู้สิ่งที่ต่างกัน และอุโมงค์เปลี่ยนแต่ละมุมมองนั้นต่างกัน การเริ่มจากข้อกล่าวอ้างที่ตั้งขึ้นแล้วย้อนกลับไปจึงมีประโยชน์ เพราะข้อกล่าวอ้างคือสิ่งที่ต้องผ่านการตรวจสอบ ตัดสินใจว่าคุณต้องการข้อกล่าวอ้างใด แล้วเปรียบเทียบเครื่องมือกับข้อนั้น

ข้อที่หนึ่ง ไม่มีใครอ่านทราฟฟิกได้

เริ่มจากข้อที่แคบที่สุด คือ เพย์โหลดยังอ่านไม่ได้ ผู้สังเกตแบบพาสซีฟบนเส้นทางมองเข้าไปในเซสชัน TLS ไม่ได้ อุโมงค์จึงเพิ่มอะไรให้เว็บที่ใช้ HTTPS อยู่แล้วเพียงเล็กน้อย และไม่ได้เพิ่มอะไรต่อปลายทั้งสอง ฝ่ายที่ทำให้ข้อนี้แตกคือผู้ควบคุมอุปกรณ์ เพราะพร็อกซีตรวจสอบจะปิดการเชื่อมต่อและลงนามใหม่ด้วยรากที่เครื่องนั้นเชื่อถืออยู่แล้ว นั่นคือเหตุที่ไอคอนกุญแจยังปรากฏขณะที่ห่วงโซ่ใบรับรองมีชื่อองค์กรที่ติดตั้งรากนั้น

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

บน macOS ท่อคำสั่งนั้นพิมพ์บรรทัดหัวข้อหนึ่งบรรทัดต่อใบรับรองแต่ละใบในพวงกุญแจของเครื่อง โดยไม่เปิดหน้าต่าง ส่วนบน Windows certutil -store Root จะแสดงรายการที่เก็บเดียวกันกับที่ certlm.msc แสดงเป็นภาพ รากที่เป็นของโรงเรียน นายจ้าง หรือผลิตภัณฑ์ความปลอดภัยเครือข่ายคือรายการที่ควรค้นหา การพบหนึ่งรายการพิสูจน์เพียงว่าการดักจับเป็นไปได้ ไม่ได้พิสูจน์ว่ากำลังเกิดขึ้น

สิ่งที่คุณทำได้เกี่ยวกับเรื่องนี้เป็นคำถามเชิงนโยบายไม่ใช่เชิงเทคนิค การลบโปรไฟล์หรือรากตรวจสอบออกจากฮาร์ดแวร์ที่ไม่ใช่ของคุณมักละเมิดข้อตกลงการใช้งานที่ยอมรับได้ และระบบจัดการมักสังเกตเห็นแล้วนำกลับมาใช้อีก ดังนั้นข้อกำหนดที่ว่าเจ้าของอุปกรณ์ต้องไม่อ่านทราฟฟิกของคุณจึงต้องใช้อุปกรณ์อื่น ไม่ใช่การตั้งค่าอื่น

ข้อที่สอง ไม่มีใครเห็นว่าคุณไปที่ไหน

ปลายทางเป็นข้อที่ยากกว่า เพราะการเปิดเผยสองอย่างเกิดขึ้นก่อนที่หน้าจะโหลด คำค้นหาจะไปยังตัวแก้ชื่อที่ระบบตั้งค่าไว้ และคำตอบนั้นมองเห็นได้โดยเครือข่ายที่ขนส่งมัน จากนั้นการจับมือ TLS จะพาชื่อเซิร์ฟเวอร์ที่ร้องขอมาแบบเปิดเผย เว้นแต่ Encrypted Client Hello จะได้รับการสนับสนุนทั้งสองฝั่ง การเปิดเผยทั้งสองไม่ต้องถอดรหัส อุโมงค์จึงไม่มีผลกับทั้งคู่

resolvectl status | grep -A2 "Link"
nslookup example.com

ตัวแก้ชื่อใดถูกใช้จริงเป็นตัวกำหนดการเปิดเผย และเรื่องนี้วัดได้แทนที่จะเถียงกัน บน Linux resolvectl status พิมพ์เซิร์ฟเวอร์ DNS ต่อลิงก์ และผลลัพธ์บอกคุณว่าตัวแก้ชื่อของเว็บหรือตัวที่ถูกผลักเข้ามาเป็นฝ่ายตอบ บน Windows ตอบคำถามเดียวกันด้วย nslookup example.com โดยบล็อกแรกของผลลัพธ์คือเซิร์ฟเวอร์ DNS ที่ตอบ

เมื่อแล็ปท็อปถามตัวแก้ชื่อของเว็บก่อนที่อุโมงค์จะขึ้น หรือโปรไฟล์มาถึงโดยไม่มีเซิร์ฟเวอร์ทดแทน ทำให้ตัวเก่ายังถูกใช้อยู่ ผู้ดูแลระบบก็ยังเก็บชื่อโฮสต์ได้โดยไม่ต้องถอดรหัสอะไร DNS ที่เข้ารหัสในเบราว์เซอร์จะหลบเลี่ยงตัวแก้ชื่อที่ถูกผลักเข้ามา หรือถูกบล็อกทั้งหมดและล้มเหลวแบบปิด เมื่อผู้ดำเนินการขาออกเห็นชื่อเดียวกันจากฝั่งของตน การเปลี่ยนตัวแก้ชื่อจึงไม่ได้ย้ายการเปิดเผยนั้นออกจากผู้ให้บริการอุโมงค์

ข้อที่สาม ไม่มีใครรู้ว่าคุณเชื่อมต่อ

ข้อที่สามคือข้อที่อุโมงค์ไม่อาจรองรับได้ เพราะ แพ็กเก็ตยังข้ามเครือข่ายท้องถิ่นอยู่ เครือข่ายนั้นเรียนรู้ที่อยู่ปลายทาง ปริมาณโดยประมาณ เวลา และการมีอยู่ของเซสชันที่เข้ารหัสอายุยาวหนึ่งเซสชัน ซึ่งเพียงพอจะบล็อก จำกัด หรือเพียงสังเกตเห็น การถูกเฝ้ามองไม่เหมือนกับการที่ไม่มีใครเฝ้ามอง คุณย้ายผู้สังเกต ไม่ได้ลบมัน

การทำอุโมงค์แบบแยกส่วน และ แอปพลิเคชันใดที่เพิกเฉยต่อเส้นทางที่ถูกผลักเข้ามา ทำให้เกิดการไหลนอกอุโมงค์ที่ดูเหมือนเดิมทุกประการ ผู้สังเกตที่ระมัดระวังจะสังเกตเห็นการไหลเหล่านั้นก่อน และตารางเส้นทางของไคลเอนต์แสดงว่าเป้าหมายใดถูกยกเว้น

ผู้ดำเนินการอีกฝั่งถือภาพสะท้อนของมุมมองนั้น คือ ที่อยู่ขาออก เวลา ปริมาณ และโดยปกติชื่อเว็บ ผู้ให้บริการของคุณกลายเป็นฝ่ายที่มีจุดมอง ซึ่งเป็นข้อตกลงที่ต่างจากความล่องหน การเลือกผู้ให้บริการที่คุณไว้วางใจเป็นการตัดสินใจจริง แต่การเรียกผลลัพธ์ว่าไม่ถูกเฝ้ามองไม่ใช่

ตัดสินใจว่าคุณต้องการข้อกล่าวอ้างใด

เขียนข้อกำหนดเป็นบรรทัดเดียวก่อนแตะไคลเอนต์ คือ ซ่อนเนื้อหา ซ่อนปลายทาง หรือซ่อนว่าคุณเชื่อมต่อหรือไม่ เนื้อหาจัดการโดย HTTPS พร้อมกับอุโมงค์อยู่แล้ว ส่วนปลายทางต้องใช้ตัวแก้ชื่อและเส้นทางที่ข้ามอุปกรณ์ของเว็บไปทั้งหมด

ข้อกำหนดที่สามคือข้อที่อึดอัด เพราะมีบางสิ่งยังเชื่อมต่ออยู่ให้เห็นที่ใดที่หนึ่ง ไม่ว่าจะเข้ารหัสหรือไม่ การตั้งค่าไคลเอนต์ใดก็ไม่เปลี่ยนสิ่งนั้น หากข้อกำหนดกับนโยบายแยกจากกัน ช่องว่างนั้นเป็นเรื่องของการพูดคุยกับเจ้าของนโยบาย ไม่ใช่ตัวเลือกในไคลเอนต์ ผู้ที่ตอบได้คือผู้ที่เขียนนโยบาย