หากคุณเห็นอาการใดๆ ด้านล่างแม้จะเปิด VPN แล้ว ให้สงสัยว่า DNS รั่วไหลหรือ WebRTC รั่วไหล การรั่วไหลเกิดขึ้นเมื่อข้อมูลที่ควรจะผ่านเส้นทาง VPN ออกจากเส้นทางนั้น (หรือที่เรียกว่าการกรอง)
- IP ของเซิร์ฟเวอร์ VPN จะแสดงบนหน้าการตรวจสอบ IP แต่เซิร์ฟเวอร์ DNS ของบริษัทโทรคมนาคมหรือเราเตอร์จะแสดงในการทดสอบ DNS
- ที่อยู่ IPv4 มีการเปลี่ยนแปลง แต่ที่อยู่ IPv6 เหมือนเดิมก่อนที่จะปิด VPN
- ในหน้าทดสอบ WebRTC IP สาธารณะจะปรากฏเหมือนเดิมก่อนที่จะปิด VPN
- IP ดั้งเดิมจะมองเห็นได้ทันทีหลังจากเปลี่ยนจาก Wi-Fi เป็นข้อมูลมือถือหรือตื่นจากโหมดสลีป
- ฉันเปิดใช้งาน StageVPN สำหรับ Chrome แต่เบราว์เซอร์และโปรแกรมพีซีอื่น ๆ เชื่อมต่อโดยใช้ IP ดั้งเดิม
- แม้จะเปิดใช้งาน VPN แล้ว ไซต์ก็แสดงภาษาและเนื้อหาตามภูมิภาคดั้งเดิม (ซึ่งอาจเป็นเพราะการตั้งค่าบัญชี/คุกกี้)
การรั่วไหลของ DNS เป็นปรากฏการณ์ที่การสื่อสารทางเว็บผ่านอุโมงค์เมื่อเปิด VPN แต่มีเพียงการสืบค้น DNS เท่านั้นที่จะออกจากอุโมงค์ และชื่อโดเมนจะปรากฏให้เห็นในเซิร์ฟเวอร์ DNS ของบริษัทโทรคมนาคมหรือ Wi-Fi การรั่วไหลของ WebRTC เป็นปรากฏการณ์ที่ WebRTC ของเบราว์เซอร์ส่งคำขอ STUN โดยตรงจาก VPN/พรอกซี ทำให้หน้าเว็บค้นพบ IP สาธารณะจริงได้ ไม่มีปรากฏการณ์ใดที่ทำให้เนื้อหาของหน้ารั่วไหล อย่างไรก็ตาม มันเผยให้เห็นว่า 'ใครกำลังเข้าถึงที่ไหน' บทความนี้เริ่มต้นด้วยอาการและดำเนินการผ่านขั้นตอนการวินิจฉัย 6 ขั้นตอน การแก้ไขตามสาเหตุ และการตรวจซ้ำ
การวินิจฉัย: วิธีตรวจสอบรอยรั่วใน 6 ขั้นตอน
หลักการตรวจสอบการรั่วไหลคือการเปรียบเทียบค่ากับ VPN ที่ปิดและเปิดอยู่ เปรียบเทียบ IP ที่แสดงบนไซต์ เซิร์ฟเวอร์ที่ได้รับการสอบถาม DNS และที่อยู่ตัวเลือก WebRTC หากมองเห็นค่าดั้งเดิมแม้ว่าจะเปิด VPN แล้วก็ตาม แสดงว่ามีการรั่วไหล การทดสอบมีผลเฉพาะกับอุปกรณ์และเบราว์เซอร์ที่คุณใช้จริงเท่านั้น แม้ว่าคุณจะไม่มีไซต์ทดสอบเฉพาะเจาะจง แต่คุณสามารถตรวจสอบสิ่งต่างๆ ส่วนใหญ่ได้โดยใช้เบราว์เซอร์ หน้าการตรวจสอบ IP คือหน้าเว็บที่แสดงที่อยู่ IP สาธารณะของบุคคลที่เชื่อมต่อบนหน้าจอ คุณสามารถค้นหาได้ในเครื่องมือค้นหาในชื่อ 'ตรวจสอบ IP' ค้นหาหน้าทดสอบการรั่วไหลของ DNS และหน้าทดสอบ WebRTC ในลักษณะเดียวกัน หลักการจะเหมือนกันไม่ว่าคุณจะใช้เพจใดก็ตาม ดังนั้นคุณจึงไม่จำเป็นต้องพึ่งพาไซต์ใดไซต์หนึ่งโดยเฉพาะ
- ปิด VPN และบันทึก IP ของคุณ เปิดหน้าการตรวจสอบ IP และจดที่อยู่ IPv4 สาธารณะ และที่อยู่ IPv6 ถ้ามี ค่านี้เป็นพื้นฐานสำหรับการเปรียบเทียบในภายหลังทั้งหมด
- เปิด VPN ของคุณและเปรียบเทียบ IP หลังจากตรวจสอบตัวบ่งชี้การเชื่อมต่อเสร็จสมบูรณ์บนแอป StageVPN หรือไฟแสดงสถานะสีเขียวบนไอคอน StageVPN สำหรับ Chrome แล้ว ให้เปิดหน้าเดิมอีกครั้ง ควรแทนที่ IPv4 ด้วยที่อยู่เซิร์ฟเวอร์ VPN ของคุณ
- ตรวจสอบเซิร์ฟเวอร์ DNS ของคุณ เปิดหน้าการทดสอบการรั่วไหลของ DNS เพจเหล่านี้จะค้นหาโดเมนย่อยแบบสุ่ม จากนั้นแสดงเซิร์ฟเวอร์ DNS ที่ส่งข้อความค้นหา หากคุณเห็นผู้ให้บริการหรือเซิร์ฟเวอร์ของเราเตอร์ แสดงว่ามี DNS รั่วไหล
- เปิด chrome://webrtc-internals การป้อนที่อยู่นี้ในแถบที่อยู่ของ Chrome จะแสดงการเชื่อมต่อ WebRTC ที่กำลังดำเนินอยู่และที่อยู่ของผู้สมัคร รายการดังกล่าวจะปรากฏขึ้นหากคุณเปิดหน้าทดสอบ WebRTC หรือหน้าแฮงเอาท์วิดีโอไว้ในแท็บอื่น
- ตรวจสอบ IP ของผู้สมัคร หากที่อยู่ของผู้สมัคร srflx (การสะท้อนเซิร์ฟเวอร์) เหมือนกับ IP สาธารณะดั้งเดิมจากขั้นตอนที่ 1 แสดงว่า WebRTC รั่วไหล หากเป็น IP เซิร์ฟเวอร์ VPN หรือมองเห็นเฉพาะชื่อ .local และ IP ส่วนตัว IP สาธารณะจะไม่ถูกเปิดเผย
- ตรวจสอบ IPv6 หากคุณมีที่อยู่ IPv6 ในขั้นตอนที่ 1 ให้เปิด VPN และดูว่าที่อยู่นั้นหายไปหรือเปลี่ยนแปลงหรือไม่ หากเป็นกรณีนี้ IPv6 กำลังออกจากอุโมงค์ สลับระหว่าง Wi-Fi และข้อมูลมือถือ และทำซ้ำเพื่อดูว่าผลลัพธ์เหมือนกันหรือไม่หลังจากรีสตาร์ทเบราว์เซอร์
| ผลการสังเกต | ความหมาย | สาเหตุต่อไป |
|---|---|---|
| IP เซิร์ฟเวอร์ VPN มองเห็นได้บนเว็บไซต์ | การสื่อสารทางเว็บต้องใช้เส้นทาง VPN | ปกติ ขั้นตอนต่อไป |
| IPv4 มีการเปลี่ยนแปลง แต่ IPv6 เป็นที่อยู่เดิม | IPv6 ออกจากอุโมงค์ | สาเหตุที่ 2 |
| เซิร์ฟเวอร์ DNS มาจากบริษัทโทรคมนาคมหรือเราเตอร์ | DNS รั่วไหล | สาเหตุที่ 1, 3, 4, 5 |
| เซิร์ฟเวอร์ DNS เป็นผู้ให้บริการ DNS สาธารณะ | DNS ในการกำหนดค่า VPN ของคุณหรือ DNS ที่ปลอดภัยที่คุณระบุเอง | อย่าคิดว่าเป็นการรั่วไหลเพียงเพราะชื่อธุรกิจ ตรวจสอบสาเหตุที่ 4 |
| IP สาธารณะดั้งเดิมสามารถมองเห็นได้ใน WebRTC | WebRTC รั่วไหล | สาเหตุที่ 6 และ 7 |
| เฉพาะชื่อ .local หรือ IP ส่วนตัวเท่านั้นที่จะมองเห็นได้ใน WebRTC | IP สาธารณะไม่ถูกเปิดเผย | โดยทั่วไปแล้วปกติ |
| IP ดั้งเดิมทันทีหลังจากการสลับเครือข่าย | ช่องว่างในช่วงเวลาแห่งการเปลี่ยนแปลง | สาเหตุที่ 8 |
ผลลัพธ์อาจแตกต่างกันไปตามสถานที่ทดสอบ มีสถานที่ที่ดูเฉพาะ IPv4 และสถานที่ที่ดู IPv6 และวิธีการค้นหาเซิร์ฟเวอร์ DNS ก็แตกต่างกันเช่นกัน เปรียบเทียบได้มากกว่าหนึ่งแห่งและโดยการสลับไปยังหลายเครือข่าย
แบบสอบถาม DNS เปิดเผยอะไร
แบบสอบถาม DNS มีชื่อโดเมน ไม่รวมเนื้อหาของหน้าหรือค่าที่ป้อน DNS คือระบบสมุดที่อยู่ของอินเทอร์เน็ตที่แปลงชื่อโดเมนที่มนุษย์อ่านให้เป็นที่อยู่ IP ที่คอมพิวเตอร์ใช้ ทุกครั้งที่คุณพิมพ์ที่อยู่ในเบราว์เซอร์หรือแอปติดต่อกับเซิร์ฟเวอร์ อุปกรณ์ของคุณจะถามเซิร์ฟเวอร์ DNS ก่อนว่า 'ที่อยู่ของชื่อนี้คืออะไร' ดังนั้น เพียงดูที่ประวัติการค้นหา คุณก็สามารถบอกได้มากมายว่าคุณพยายามเข้าถึงเมื่อใดและบริการใด
- อุปกรณ์ของฉันแอพ/เบราว์เซอร์
- แบบสอบถาม DNS ข้อความธรรมดา
- Wi-Fi สาธารณะเราเตอร์คาเฟ่
- แบบสอบถาม DNS ข้อความธรรมดา
- DNS ของผู้ให้บริการเซิร์ฟเวอร์ที่มีอยู่
- พื้นที่ที่อาจสัมผัสได้
- อุปกรณ์ของฉันแอพ/เบราว์เซอร์
- DNS ในทันเนล
- Wi-Fi สาธารณะเราเตอร์คาเฟ่
- DNS ในทันเนล
- เซิร์ฟเวอร์วีพีเอ็นStageVPN
- ค้นหาโดย IP เซิร์ฟเวอร์ VPN
- เซิร์ฟเวอร์ DNSระบุในการกำหนดค่า VPN
- การเข้ารหัส VPN
การสืบค้น DNS แบบดั้งเดิมไปที่พอร์ต UDP 53 ที่ไม่ได้เข้ารหัส เพื่อชดเชยสิ่งนี้ DoH (RFC 8484) ซึ่งล้อมการสืบค้นใน HTTPS และ DoT (RFC 7858) ซึ่งล้อมการสืบค้นใน TLS ได้ถูกสร้างขึ้น อย่างไรก็ตาม แม้ว่าคุณจะใช้ DNS ที่เข้ารหัส ชื่อเซิร์ฟเวอร์ (SNI) ที่ส่งเมื่อเชื่อมต่อกับไซต์ผ่าน HTTPS อาจปรากฏให้เห็นบนเครือข่ายหากไซต์และเบราว์เซอร์ไม่รองรับ ECH (Hello ไคลเอ็นต์ที่เข้ารหัส)
| วิธีการจัดส่ง | ผู้สังเกตการณ์บน Wi-Fi เดียวกัน | ผู้ให้บริการ Wi-Fi/บริษัทสื่อสาร | เซิร์ฟเวอร์ DNS ได้รับการสอบถาม |
|---|---|---|---|
| DNS ธรรมดา (ข้อความธรรมดา) | สามารถมองเห็นได้ | สามารถมองเห็นได้ | มองเห็นได้ด้วย IP สาธารณะของฉัน |
| DoH/DoT (DNS ที่เข้ารหัส) | ไม่สามารถมองเห็นได้ | ไม่สามารถมองเห็นได้ ที่อยู่เซิร์ฟเวอร์ DNS สามารถมองเห็นได้ | มองเห็นได้ด้วย IP สาธารณะของฉัน |
| DNS ภายในอุโมงค์ VPN | ไม่สามารถมองเห็นได้ | ไม่สามารถมองเห็นได้แต่เห็นว่ากำลังสื่อสารกับเซิร์ฟเวอร์ VPN | มองเห็นได้ด้วย IP เซิร์ฟเวอร์ VPN |
| สถานะการรั่วไหลของ DNS | หากเป็นข้อความธรรมดาคุณสามารถดูได้ | สามารถมองเห็นได้ | มองเห็นได้ด้วย IP สาธารณะของฉัน |
Secure DNS (DoH) และ VPN มีวัตถุประสงค์ที่แตกต่างกัน DoH เข้ารหัสการสืบค้น DNS เท่านั้น การเข้าถึงไซต์และ IP ที่ไซต์เห็นยังคงเหมือนเดิม VPN เข้ารหัสการสื่อสารทั้งหมดระหว่างอุปกรณ์หรือเบราว์เซอร์ของคุณกับเซิร์ฟเวอร์ VPN และเปลี่ยน IP ที่ไซต์เห็น โหมดไม่ระบุตัวตนไม่ได้หยุดการรั่วไหลเช่นกัน โหมดไม่ระบุตัวตนเป็นฟังก์ชันที่ไม่ทิ้งประวัติหรือคุกกี้ไว้ในอุปกรณ์ และไม่เปลี่ยนการสืบค้น DNS หรือเส้นทาง WebRTC
WebRTC กำหนดที่อยู่ IP อย่างไร
WebRTC ค้นหาที่อยู่ของตัวเองในหลายวิธีในการเชื่อมต่ออุปกรณ์สองเครื่องผ่านเส้นทางที่สั้นที่สุดและส่งผลลัพธ์ไปยังสคริปต์บนหน้าเว็บ WebRTC เป็นเทคโนโลยีมาตรฐานเว็บที่ช่วยให้คุณสามารถโทรวิดีโอ โทรเสียง และถ่ายโอนไฟล์ได้โดยไม่ต้องใช้ปลั๊กอินในเบราว์เซอร์ กระบวนการรวบรวมที่อยู่เรียกว่า ICE (RFC 8445) แม้แต่เพจที่ไม่ได้ทำแฮงเอาท์วิดีโอก็สามารถเริ่มกระบวนการนี้ด้วยสคริปต์ได้
- สร้างวัตถุการเชื่อมต่อสคริปต์ของเว็บเพจสร้าง RTCPeerConnection
- รวบรวมผู้สมัครในพื้นที่เบราว์เซอร์ของคุณรวบรวมที่อยู่ของอุปกรณ์เครือข่ายของอุปกรณ์ของคุณ
- แบบสอบถาม STUNถามเซิร์ฟเวอร์ STUN 'ที่อยู่ของฉันเป็นอย่างไร' ด้วย UDP
- จัดส่งผู้สมัครรายชื่อผู้สมัครรวมถึงที่อยู่สาธารณะที่ได้รับจากเซิร์ฟเวอร์ STUN จะถูกส่งไปยังเพจ
| ประเภทผู้สมัคร | บางสิ่งบางอย่าง | ข้อมูลที่อาจเปิดเผยได้ | การป้องกันเบราว์เซอร์ล่าสุด |
|---|---|---|---|
| เจ้าภาพ | ที่อยู่ของอุปกรณ์เครือข่ายของเครื่อง | IP ส่วนตัว (192.168.x ฯลฯ) | มาสก์ด้วยชื่อ .local แบบสุ่ม (mDNS) แต่สามารถเห็นได้บนไซต์ที่ให้สิทธิ์อนุญาตกล้องและไมโครโฟน |
| srflx (สะท้อนเซิร์ฟเวอร์) | ที่อยู่สาธารณะของฉันตามที่เซิร์ฟเวอร์ STUN เห็น | IP สาธารณะ, IP จริงหากคุณเลี่ยงผ่านพรอกซี | สามารถจำกัดได้โดยนโยบายการประมวลผล IP ของ WebRTC |
| รีเลย์ | TURN ที่อยู่ของเซิร์ฟเวอร์รีเลย์ | IP เซิร์ฟเวอร์รีเลย์ | หากคุณใช้รีเลย์ อีกฝ่ายจะเห็นที่อยู่เซิร์ฟเวอร์แทน IP ของคุณ |
ปัญหาคือแบบสอบถาม STUN ในขั้นตอนที่ 3 พรอกซีของเบราว์เซอร์ส่งต่อคำขอเว็บ แต่การสื่อสาร UDP ของ WebRTC ไม่ผ่านพรอกซีในการตั้งค่าเริ่มต้นของเบราว์เซอร์ ดังนั้นที่อยู่ที่ได้รับจากเซิร์ฟเวอร์ STUN ไม่ใช่พร็อกซีเซิร์ฟเวอร์ แต่เป็น IP สาธารณะดั้งเดิมของฉัน สิ่งต่าง ๆ แตกต่างไปจาก VPN ทั่วทั้งอุปกรณ์ เนื่องจากการสื่อสาร UDP ทั้งหมด รวมถึงคำขอ STUN ไปที่ทันเนล ที่อยู่ที่เซิร์ฟเวอร์ STUN เห็นจึงเป็น IP ของเซิร์ฟเวอร์ VPN เช่นกัน
พร็อกซีเบราว์เซอร์และนโยบายเริ่มต้น
- คำขอของเว็บต้องผ่านพรอกซี
- คำขอ STUN ไปที่ UDP โดยตรง
- เพจสามารถดู IP สาธารณะจริงได้
พร็อกซีเบราว์เซอร์และ Disable_non_proxyed_udp
- ป้องกันไม่ให้ UDP ผ่านพรอกซี
- WebRTC ใช้เส้นทางพร็อกซีเท่านั้น
- การโทรบางสายมีวิธีการเชื่อมต่อหรือคุณภาพที่แตกต่างกัน
VPN ทั่วทั้งอุปกรณ์
- คำขอ STUN ยังต้องผ่านอุโมงค์ด้วย
- ผู้สมัครที่อยู่สาธารณะคือ IP เซิร์ฟเวอร์ VPN
- การตัดการเชื่อมต่อและการจัดการ IPv6 จำเป็นต้องมีการยืนยัน
Chrome มี 'นโยบายการจัดการ IP ของ WebRTC' ที่กำหนดว่า WebRTC จะใช้ที่อยู่ใด และส่วนขยายสามารถเปลี่ยนค่านี้ได้ แต่ละค่าสอดคล้องกับสี่วิธีที่ระบุไว้ในคำแนะนำการจัดการที่อยู่ IP ของ WebRTC ของ IETF (RFC 8828)
| มูลค่านโยบาย | ความเคลื่อนไหว | ช่วงการเปิดรับแสง |
|---|---|---|
| ค่าเริ่มต้น | รวบรวมผู้สมัครจากอุปกรณ์เครือข่ายทั้งหมด | กว้างที่สุด (ที่อยู่ท้องถิ่นถูกปกปิดโดย mDNS) |
| default_public_and_private_interfaces | ใช้อุปกรณ์ในเส้นทางเริ่มต้นเท่านั้น ใช้ทั้งที่อยู่สาธารณะและส่วนตัว | ไม่เปิดเผยที่อยู่ของอุปกรณ์อื่น |
| default_public_interface_only | ใช้ที่อยู่สาธารณะของเส้นทางเริ่มต้นเท่านั้น | ที่อยู่ส่วนตัวจะไม่ถูกเปิดเผย |
| Disable_non_proxyed_udp | ไม่มี UDP ผ่านพร็อกซี ให้ใช้ TCP ผ่านพร็อกซีหากพร็อกซีไม่รองรับ UDP | อย่าเปิดเผยที่อยู่ของเส้นทางภายนอกพร็อกซี |
วิธีแก้ไข: วิธีการตรวจสอบและแก้ไขตามสาเหตุ
การรั่วไหลส่วนใหญ่มีสาเหตุ 1 ใน 8 ประการ ซึ่งมักเกิดจากการตั้งค่าที่ทับซ้อนกัน เริ่มต้นด้วยการตรวจสอบหมายเลขสาเหตุที่ระบุไว้ในตารางการวินิจฉัย และทุกครั้งที่คุณแก้ไขปัญหา ให้ทำซ้ำขั้นตอนที่ 6 ในภาพด้านบนเพื่อดูว่าผลลัพธ์มีการเปลี่ยนแปลงหรือไม่ หากคุณเปลี่ยนการตั้งค่าหลายรายการพร้อมกัน คุณจะไม่รู้ว่าอะไรได้ผล
สาเหตุที่ 1 · ไม่มีเซิร์ฟเวอร์ DNS ในการกำหนดค่า VPN หรืออุปกรณ์ใช้ DNS อื่น
ตรวจสอบ เมื่อเปิด VPN การทดสอบ DNS จะแสดงเราเตอร์ Wi-Fi หรือเซิร์ฟเวอร์ DNS ของผู้ให้บริการ คุณมักจะมี DNS แบบกำหนดเองในการตั้งค่า Wi-Fi ของอุปกรณ์
แก้ปัญหา แอป StageVPN มีเซิร์ฟเวอร์ DNS ในการกำหนดค่า VPN และส่งคำถามไปยังอุโมงค์ เปลี่ยน DNS แบบปรับเองให้เป็นอัตโนมัติในการตั้งค่าเครือข่ายของอุปกรณ์ จากนั้นยกเลิกการเชื่อมต่อและเชื่อมต่อกับ VPN อีกครั้ง หากปัญหายังคงเหมือนเดิม ให้ตรวจสอบสาเหตุที่ 3 และ 5
สาเหตุที่ 2 IPv6 ออกจากอุโมงค์
ตรวจสอบ IPv4 ได้ถูกเปลี่ยนเป็นที่อยู่เซิร์ฟเวอร์ VPN แล้ว แต่ IPv6 ยังคงเหมือนเดิมกับค่าที่เขียนไว้ในขั้นตอนที่ 1 หาก VPN ส่งสัญญาณเฉพาะ IPv4 เท่านั้น การสืบค้นและการสื่อสารของ IPv6 จะออกไปในเส้นทางเดิม
แก้ปัญหา แอป StageVPN ได้รับการกำหนดค่าให้ส่งการสื่อสาร IPv6 ไปยังทันเนลด้วย (AllowedIPs 0.0.0.0/0, ::/0) ดังนั้นจึงไม่จำเป็นต้องปิดการทำงาน หาก IPv6 ยังคงปรากฏตามที่ควรจะเป็น ก่อนอื่นให้ตรวจสอบเพื่อดูว่าแอป VPN อื่นหรือการตั้งค่าอุปกรณ์กำลังเปลี่ยนเส้นทางหรือไม่ ไซต์ทดสอบบางแห่งไม่รองรับ IPv6 ดังนั้นให้เปรียบเทียบมากกว่าหนึ่งไซต์
สาเหตุที่ 3 · ระบบปฏิบัติการสอบถาม DNS ของอุปกรณ์เครือข่ายหลายเครื่องพร้อมกัน
ตรวจสอบ โดยเฉพาะอย่างยิ่งในระหว่างการเชื่อมต่อ VPN บนพีซีที่ใช้ Windows การทดสอบ DNS จะแสดงทั้ง DNS ของ VPN และ DNS ของผู้ให้บริการของคุณ สาเหตุนี้มีสาเหตุจากฟีเจอร์ที่ถามอุปกรณ์เครือข่ายทั้งหมดพร้อมกัน เช่น Smart Multi-Homed Name Resolution ของ Windows
แก้ปัญหา อัปเดตระบบปฏิบัติการและซอฟต์แวร์ VPN ของคุณให้ทันสมัยและทดสอบซ้ำ ปรากฏการณ์นี้ส่วนใหญ่รายงานด้วย VPN ทั่วทั้งอุปกรณ์บนพีซี และจะไม่เกิดขึ้นในลักษณะเดียวกันบนแอป StageVPN บนสมาร์ทโฟนและ StageVPN สำหรับ Chrome บน Chrome เนื่องจากมีโครงสร้างที่แตกต่างกัน
สาเหตุที่ 4 · Secure DNS (DoH) มีการระบุแยกต่างหากในเบราว์เซอร์หรืออุปกรณ์
ตรวจสอบ การทดสอบ DNS แสดงเซิร์ฟเวอร์จากผู้ให้บริการ DNS สาธารณะ ในกรณีนี้ อาจไม่ใช่การรั่วไหล แต่เป็นการตั้งค่าที่คุณระบุเอง หากคุณมี VPN ทั่วทั้งอุปกรณ์ คำค้นหานี้จะผ่านช่องทางดังกล่าวด้วย แต่ผู้ให้บริการที่ระบุจะได้รับข้อมูลดังกล่าว แทนที่จะเป็น DNS ในการกำหนดค่า VPN ของคุณ
แก้ปัญหา หากนี่คือการตั้งค่าที่ต้องการ คุณสามารถปล่อยไว้ตามเดิมได้ หากคุณต้องการใช้ DNS สำหรับการกำหนดค่า VPN ระบบจะเปลี่ยนการตั้งค่า DNS ที่ปลอดภัยบนเบราว์เซอร์และอุปกรณ์ของคุณโดยอัตโนมัติ สิ่งสำคัญคืออย่าคิดว่าเป็นการรั่วไหลเพียงแค่ดูชื่อธุรกิจ
สาเหตุที่ 5 · แอป VPN, พร็อกซี และความปลอดภัยอื่นๆ เปิดอยู่ด้วย
ตรวจสอบ คุณสมบัติเครือข่ายของแอป VPN อื่น ๆ ส่วนขยายพร็อกซี ตัวกรองโฆษณา หรือโปรแกรมรักษาความปลอดภัยจะเปิดพร้อมกัน การตั้งค่าเส้นทางจะเขียนทับซึ่งกันและกัน ส่งผลให้มีการสอบถามไปยังเส้นทางเดิม
แก้ปัญหา เปิดครั้งละหนึ่งเครื่องเท่านั้น ปิดแอปและส่วนขยายอื่นๆ ยกเลิกการเชื่อมต่อและเชื่อมต่อ StageVPN อีกครั้ง และทำซ้ำขั้นตอนที่ 6 การตั้งค่าพร็อกซีของ Chrome สามารถควบคุมส่วนขยายได้ครั้งละหนึ่งรายการเท่านั้น ดังนั้น หากส่วนขยายอื่นใช้พร็อกซี StageVPN สำหรับ Chrome จะไม่เชื่อมต่อและจะบอกคุณว่าทำไม
สาเหตุที่ 6 · ใช้เฉพาะพร็อกซีของเบราว์เซอร์ แต่คาดว่าจะมีการสื่อสารภายนอกเบราว์เซอร์
ตรวจสอบ ฉันเปิดใช้งาน StageVPN สำหรับ Chrome แต่เบราว์เซอร์ โปรแกรมส่งข้อความ PC และโปรแกรมเมลอื่น ๆ เชื่อมต่อโดยใช้ IP ดั้งเดิมและ DNS ดั้งเดิม นี่ไม่ใช่การรั่ว แต่เป็นช่วงที่ออกแบบไว้ ส่วนขยายครอบคลุมเฉพาะการสื่อสารใน Chrome เท่านั้น
แก้ปัญหา หากคุณต้องการปกป้องโปรแกรมภายนอก Chrome ให้ใช้ VPN ที่ใช้กับอุปกรณ์ทั้งหมด บนสมาร์ทโฟน แอป StageVPN ทำเช่นนั้น ความแตกต่างในขอบเขตระหว่างทั้งสองวิธีคือ เบราว์เซอร์ VPN กับ App VPNฉันจัดมันไว้ใน.
สาเหตุที่ 7 นโยบาย WebRTC ไม่ได้ใช้
ตรวจสอบ ฉันเปิด StageVPN สำหรับ Chrome และฉันเห็น IP สาธารณะดั้งเดิมในการทดสอบ WebRTC หรือในตัวเลือก srflx ใน chrome://webrtc-internals หากนโยบายการจัดการของส่วนขยายหรือบริษัท/องค์กรอื่นควบคุมการตั้งค่า WebRTC ก่อน StageVPN สำหรับ Chrome จะไม่เปลี่ยนนโยบายและจะคงไว้ดังเดิม
แก้ปัญหา ปิดส่วนขยายอื่นๆ ที่ควบคุมการตั้งค่า WebRTC และเชื่อมต่อ StageVPN สำหรับ Chrome อีกครั้ง ถ้านโยบายการจัดการเป็นสาเหตุ โปรดติดต่อผู้ดูแลระบบของคุณ หากต้องการเขียนในหน้าต่างที่ไม่ระบุตัวตน คุณต้องเปิด "อนุญาตในโหมดไม่ระบุตัวตน" ในหน้าจอการจัดการส่วนขยาย เมื่อปิด การสื่อสารในหน้าต่างที่ไม่ระบุตัวตนจะไม่ผ่านพรอกซี
สาเหตุที่ 8 · ช่วงเวลาที่การเชื่อมต่อ VPN ขาดหายไป
ตรวจสอบ IP ดั้งเดิมจะมองเห็นได้ทันทีหลังจากเปลี่ยนเครือข่ายหรือตื่นจากโหมดสลีปเท่านั้น และหลังจากนั้นไม่นานก็เป็นเรื่องปกติ ในระหว่างการตัดการเชื่อมต่อ คำถามและการสื่อสารทั้งหมดจะถูกส่งออกไปในเส้นทางปกติ
แก้ปัญหา ก่อนที่จะทำงานที่มีความละเอียดอ่อนใดๆ ให้ตรวจสอบว่าตัวบ่งชี้การเชื่อมต่อเสร็จสมบูรณ์ของแอปหรือไอคอนส่วนขยายเปิดอยู่หรือไม่ WireGuard ซึ่งใช้โดยแอป StageVPN จะไม่สร้างอุโมงค์ใหม่แม้ว่าจะเปลี่ยนจาก Wi-Fi เป็น LTE แต่โปรโตคอลไม่สามารถชดเชยการขาดการเชื่อมต่อชั่วคราวในเครือข่ายได้ ความสามารถในการบล็อกการสื่อสารโดยอัตโนมัติเมื่อตัดการเชื่อมต่อ VPN ไม่ใช่คุณสมบัติที่มีให้โดย StageVPN หลักการก็คือ อธิบายหลักการ WireGuardมันอยู่ใน
แอป StageVPN และ StageVPN สำหรับ Chrome หยุดการรั่วไหลได้อย่างไร?
แอป StageVPN ช่วยลดการรั่วไหลโดยการขุดอุโมงค์การสื่อสารทั้งหมด ในขณะที่ StageVPN สำหรับ Chrome พร็อกซีค้นหาชื่อและปรับนโยบาย WebRTC เนื่องจากขอบเขตของการป้องกันแตกต่างกัน วิธีจัดการจึงแตกต่างกันด้วย
| รายการ | แอป StageVPN (iPhone·iPad·Android) | StageVPN สำหรับ Chrome |
|---|---|---|
| ช่วงการป้องกัน | อุปกรณ์ทั้งหมด | เบราว์เซอร์ Chrome |
| การสื่อสารที่ส่งผ่านเส้นทาง VPN | IPv4·IPv6 ทั้งหมด (IP ที่อนุญาต 0.0.0.0/0, ::/0) | คำขอเว็บผ่านพร็อกซี (ไม่รวมแบนด์ IP ส่วนตัวและโลคัลโฮสต์) |
| แบบสอบถาม DNS | ส่งต่อภายในอุโมงค์ไปยังเซิร์ฟเวอร์ DNS ที่ระบุในการกำหนดค่า VPN | คำขอที่ส่งผ่านพร็อกซีจะไม่ถูกค้นหาโดย Chrome แต่โดยพร็อกซีเซิร์ฟเวอร์ |
| เว็บRTC | การสื่อสาร UDP ทั้งหมดต้องผ่านอุโมงค์ | Disable_non_proxyed_udp จะถูกใช้ระหว่างการเชื่อมต่อ และจะกลับสู่การตั้งค่าเดิมเมื่อยกเลิกการเชื่อมต่อ |
| สิ่งที่คุณเห็นบนเครือข่ายในปัจจุบัน | ความจริงที่ว่ามีการสื่อสารที่เข้ารหัสกับเซิร์ฟเวอร์ VPN และจำนวนข้อมูล | การค้นหาชื่อของที่อยู่พร็อกซีเซิร์ฟเวอร์ การเชื่อมต่อที่เข้ารหัสกับพร็อกซี และการสื่อสารจากแอปภายนอก Chrome |
| กรณีที่อาจใช้ไม่ได้ | ในขณะที่การเชื่อมต่อ VPN ขาดหายไป เมื่อแอป VPN อื่นเปลี่ยนเส้นทาง | หน้าต่างที่ไม่ระบุตัวตนซึ่งปิดอนุญาตโหมดไม่ระบุตัวตนเมื่อส่วนขยายหรือนโยบายการจัดการอื่นควบคุมการตั้งค่าพร็อกซี/WebRTC |
| ประวัติการเข้าถึง (93 วัน) | โดเมนที่ดูจะไม่ถูกบันทึก | ชื่อโฮสต์ปลายทางที่เชื่อมต่อจะถูกบันทึก แต่เส้นทางหรือคำค้นหาจะไม่ถูกบันทึก |
StageVPN ไม่ได้แนะนำคุณผ่านเมนูการตั้งค่าการป้องกันการรั่วไหลของ DNS แยกต่างหากซึ่งเป็นคุณสมบัติหนึ่งของข้อเสนอ ลักษณะการทำงานข้างต้นขึ้นอยู่กับการกำหนดค่า VPN เริ่มต้นของแอปและวิธีการเชื่อมต่อของส่วนขยาย ขอบเขตของบทบัญญัติคือ คุณสมบัติและขอบเขตของการเสนอขายคุณสามารถตรวจสอบได้ที่นี่
การไม่มีการรั่วไหลหมายความว่าการสืบค้นและการสื่อสารต้องผ่านเส้นทาง VPN แทนที่จะเป็นผู้ให้บริการ นี่ไม่ได้หมายความว่าจะไม่มีการเก็บบันทึกใดๆ StageVPN เก็บรักษาบันทึกการเข้าถึงเป็นเวลา 93 วันตามกฎหมายคุ้มครองความลับในการสื่อสาร และไม่บันทึกเนื้อหาการสื่อสาร รายการก็คือ ประกาศการจัดเก็บบันทึกการเข้าถึงเหตุผลที่ฉันเปิดเผยก็คือ เหตุใดเราจึงเปิดเผยนโยบายการเก็บรักษาบันทึกการเข้าถึงของเราอธิบาย
ตรวจสอบรายการตรวจสอบอีกครั้ง: คุณจะตรวจสอบอะไรอีกครั้งหลังจากทำการเปลี่ยนแปลง
แต่ละครั้งที่คุณแก้ไขสาเหตุหนึ่ง ให้ตรวจสอบรายการด้านล่างอีกครั้งตั้งแต่ต้น หากผ่านทั้งหมดก็ไม่มีการรั่วไหล หากรายการใดล้มเหลว รายการดังกล่าวจะกลับไปยังการ์ดสาเหตุที่เกี่ยวข้อง
- หลังจากยกเลิกการเชื่อมต่อและเชื่อมต่อ VPN อีกครั้ง ฉันตรวจสอบว่าแอปแสดงการเชื่อมต่อเสร็จสิ้นหรือไอคอนส่วนขยายแสดงเป็นเปิดหรือไม่
- ในหน้าการตรวจสอบ IP คุณจะเห็นที่อยู่เซิร์ฟเวอร์ VPN สำหรับทั้ง IPv4 และ IPv6 หรือไม่ก็ไม่เห็น IPv6
- การทดสอบ DNS ไม่แสดงเซิร์ฟเวอร์ DNS ของบริษัทโทรคมนาคมหรือเราเตอร์
- ตัวเลือก srflx ใน chrome://webrtc-internals ไม่มี IP สาธารณะดั้งเดิม
- คุณสมบัติเครือข่ายของแอป VPN พร็อกซี/ส่วนขยาย VPN และโปรแกรมความปลอดภัยอื่นๆ ปิดอยู่
- หากคุณได้ตั้งค่า DNS ด้วยตนเองหรือ DNS ที่ปลอดภัยสำหรับอุปกรณ์และเบราว์เซอร์ของคุณ แสดงว่าคุณตรวจสอบแล้วว่านี่คือการตั้งค่าที่ต้องการ
- ระบบปฏิบัติการ เบราว์เซอร์ รวมถึงแอปและส่วนขยาย StageVPN ของคุณเป็นเวอร์ชันล่าสุด
- ผลลัพธ์เดียวกันแม้หลังจากสลับระหว่าง Wi-Fi และข้อมูลมือถือแล้วรีสตาร์ทเบราว์เซอร์
- หากคุณต้องการปกป้องโปรแกรมภายนอก Chrome คุณสามารถใช้ VPN ทั่วทั้งอุปกรณ์แทนส่วนขยายได้
เป็นความคิดที่ดีที่จะพิจารณาว่าเมื่อใดจึงจำเป็นต้องมีการตรวจสอบซ้ำ นั่นคือหลังจากการอัปเดตระบบปฏิบัติการหรือเบราว์เซอร์ครั้งใหญ่ หลังจากติดตั้งส่วนขยายหรือแอปความปลอดภัยใหม่ หรือก่อนทำงานที่มีความละเอียดอ่อนบนเครือข่ายที่คุณกำลังเชื่อมต่อเป็นครั้งแรก หากการตั้งค่าเหมือนกันแต่ผลลัพธ์เปลี่ยนไป หนึ่งในสามสิ่งนี้มักเป็นสาเหตุ เมื่อคุณเข้าใจแล้ว การวินิจฉัยทั้ง 6 ขั้นตอนก็สามารถเสร็จสิ้นได้ในเวลาเพียงไม่กี่นาที
หากปัญหายังคงอยู่ ให้จัดระเบียบรุ่นอุปกรณ์ ระบบปฏิบัติการและเวอร์ชันแอป เวลาที่เกิด และผลการทดสอบ การสนับสนุนลูกค้ากรุณาติดต่อเรา กรุณาอย่าส่งรหัสผ่านหรือรหัสยืนยันของคุณ การตั้งค่าอุปกรณ์ที่ต้องตรวจสอบควบคู่กับการตรวจสอบรอยรั่วคือ: การตั้งค่าความเป็นส่วนตัวของสมาร์ทโฟน 10 แบบมีความเสี่ยงที่ไม่สามารถแก้ไขได้ด้วย VPN เพียงอย่างเดียว VPN ใดที่ป้องกันและไม่สามารถป้องกันได้นิสัยของคุณบนเครือข่ายสาธารณะก็คือ กฎความปลอดภัย Wi-Fi สาธารณะฉันจัดมันไว้ใน.
วัสดุอ้างอิง
- RFC 1034: ชื่อโดเมน - แนวคิดและสิ่งอำนวยความสะดวก — โครงสร้าง DNS และบทบาทของตัวแก้ไข (IETF)
- RFC 8484: การสืบค้น DNS ผ่าน HTTPS (DoH) — วิธีเข้ารหัสการสืบค้น DNS ผ่าน HTTPS (IETF)
- RFC 7858: DNS ผ่าน TLS — วิธีเข้ารหัสการสืบค้น DNS ด้วย TLS (IETF)
- RFC 8445: การสร้างการเชื่อมต่อเชิงโต้ตอบ (ICE) — ประเภทตัวเลือกการเชื่อมต่อ WebRTC และขั้นตอนการรวบรวม (IETF)
- RFC 8828: ข้อกำหนดการจัดการที่อยู่ IP ของ WebRTC — ช่วงที่อยู่ที่เบราว์เซอร์เปิดเผยต่อ WebRTC (IETF)
- chrome.privacy API — ค่านโยบายการจัดการ IP ของ Chrome WebRTC (Chrome สำหรับนักพัฒนา)
- chrome.proxy API — การตั้งค่าพร็อกซีส่วนขยาย รายการบายพาส และลำดับความสำคัญในการควบคุม (Chrome สำหรับนักพัฒนา)
- เว็บRTC API — RTCPeerConnection และแนวคิดของผู้สมัคร ICE (MDN Web Docs)
