VPN กับพร็อกซี: แต่ละอย่างครอบคลุมอะไรและไม่ครอบคลุมอะไร
VPN ครอบคลุมทราฟฟิกแอปที่ถูกกำหนดเส้นทาง ส่วนพร็อกซีครอบคลุมเฉพาะแอปที่คุณกำหนดค่า ตรวจสอบขอบเขต การเข้ารหัส DNS และพฤติกรรมเมื่อเกิดความล้มเหลวก่อนเลือกใช้
ทั้ง VPN และพร็อกซีแบบส่งต่อต่างเปลี่ยนที่อยู่ที่เว็บไซต์มองเห็น และนั่นคือจุดที่การเปรียบเทียบส่วนใหญ่หยุดลง ความแตกต่างที่กำหนดการตั้งค่าของคุณคือขอบเขตการครอบคลุม พร็อกซีแบบส่งต่อคือตัวกลางที่แอปของคุณเลือกใช้เอง ต่างจากพร็อกซีแบบย้อนกลับที่ตั้งอยู่หน้าเว็บไซต์ ขณะที่ VPN ย้ายทุกสิ่งที่ระบบปฏิบัติการกำหนดเส้นทางเข้าอุโมงค์ การเข้ารหัส การจัดการ DNS และพฤติกรรมเมื่อเกิดความล้มเหลวล้วนตามมาจากการแบ่งนี้ ทำการตรวจสอบทั้งห้าข้อตามลำดับ และข้อแรกที่ล้มเหลวจะบอกคุณว่าจริง ๆ แล้วคุณต้องใช้เครื่องมือใด
ตัวกลางครอบคลุมแอปใดบ้าง
ส่วนขยายพร็อกซีในเบราว์เซอร์ใช้ได้กับโปรไฟล์เบราว์เซอร์นั้นเท่านั้น ไคลเอนต์อีเมล ตัวจัดการแพ็กเกจ และเบราว์เซอร์ตัวที่สองยังคงใช้การตั้งค่าของตนเอง และแอปบางตัวเพิกเฉยต่อตัวแปรพร็อกซีของระบบโดยสิ้นเชิง VPN ครอบคลุมสิ่งที่ตารางเส้นทางส่งเข้าอุโมงค์ ซึ่งอาจเป็นแอปทั้งหมดหรือเพียงบางส่วนในอุโมงค์แบบแยก ขึ้นอยู่กับเส้นทางและนโยบายของไคลเอนต์
ทดสอบแอปที่สำคัญแทนการสรุปจากการโหลดหน้าเดียว curl https://ifconfig.me ทำตามตัวแปรพร็อกซีของสภาพแวดล้อม ส่วนแอปเดสก์ท็อปอาจไม่ทำ บน Windows netsh winhttp show proxy พิมพ์พร็อกซี WinHTTP ที่บริการต่าง ๆ ใช้ และนั่นเป็นการตั้งค่าที่แตกต่างจากการตั้งค่าของเบราว์เซอร์
การกระโดดครั้งนี้ถูกเข้ารหัสหรือไม่ และ TLS สิ้นสุดที่ใด
โปรโตคอลพร็อกซีคือจุดนัดพบ ไม่ใช่การรับประกัน SOCKS5 ส่งต่อ TCP โดยไม่เข้ารหัส และพร็อกซี HTTP ธรรมดาพาเส้นคำขอและส่วนหัวไปในข้อความธรรมดา HTTPS ผ่านพร็อกซีใช้ CONNECT ดังนั้นเซสชัน TLS ของคุณยังคงสิ้นสุดที่ปลายทาง ไม่ใช่ที่พร็อกซี คู่มือของ MDN เกี่ยวกับพร็อกซีเซิร์ฟเวอร์และการทำอุโมงค์ อธิบายความแตกต่างนี้จากฝั่งโปรโตคอล
VPN เข้ารหัสช่วงระหว่างอุปกรณ์ของคุณกับจุดสิ้นสุดของมัน เกินเลยจุดสิ้นสุดไปใช้กฎเดียวกันกับเครือข่ายอื่น ๆ จึงเป็นเหตุให้อุโมงค์เพียงอย่างเดียวไม่ปกป้องแอปที่ส่งข้อมูลรับรองผ่าน HTTP ธรรมดา ไม่มีการออกแบบใดในสองแบบที่ซ่อนบัญชีที่เข้าสู่ระบบ คุกกี้ หรือลายนิ้วมือของเบราว์เซอร์
curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/nullเอาต์พุตแบบละเอียดแสดงว่า curl ส่ง CONNECT ไปยังพอร์ต 443 หรือส่ง GET ธรรมดาพร้อม URL แบบเต็ม ด้วย socks5h:// ชื่อโฮสต์จะถูกส่งให้พร็อกซีภายในคำขอ SOCKS5 แล้วพร็อกซีส่งต่อ TLS ที่อ่านไม่ได้ จึงเห็นชื่อและจำนวนไบต์ ผ่านพร็อกซี http:// URL แบบ https:// คือ CONNECT ดังนั้นพร็อกซีนั้นก็เห็นชื่อและปริมาณของปลายทาง แต่ไม่เห็นคำขอหรือเนื้อหาการตอบกลับ
ตัวแปลงชื่อใดที่เห็นชื่อนี้
การแปลงชื่อสามารถเกิดขึ้นในเครื่องก่อนคำขอออกไป หรือเกิดขึ้นระยะไกลที่พร็อกซี ด้วย curl socks5h:// ส่งชื่อโฮสต์ไปยังพร็อกซี ขณะที่ socks5:// แปลงชื่อในเครื่องก่อน การตั้งค่าพร็อกซีของเบราว์เซอร์มีตัวเลือก DNS ที่เทียบเคียงได้ และไฟล์ PAC สามารถกำหนดเส้นทางโฮสต์ต่าง ๆ ได้ต่างกัน
โปรโตคอลสองตัวสามารถข้ามพร็อกซีได้โดยไม่มีการกำหนดค่าที่ผิดพลาดเลย WebRTC รวบรวมผู้สมัครผ่าน STUN และ QUIC รัน HTTP/3 บน UDP ซึ่งพร็อกซี TCP ไม่สามารถพาไปได้ เบราว์เซอร์จะกลับไปใช้ TCP หาก UDP 443 ถูกบล็อก ดังนั้นการบล็อก UDP 443 ที่ไฟร์วอลล์ของโฮสต์ (หรือที่เราเตอร์สำหรับทั้งเครือข่าย) ไม่ใช่ธงในเบราว์เซอร์ คือวิธีที่เชื่อถือได้ในการเก็บ HTTP/3 ไว้ในเส้นทางของพร็อกซี
ตรวจสอบตัวแปลงชื่อจากมุมมองของปลายทาง ไม่ใช่มุมมองของแล็ปท็อปคุณ คำขอที่มาพร้อมที่อยู่ทางออกของพร็อกซีแต่มีชื่อที่แปลงในเครื่องยังคงบอกตัวแปลงชื่อในเครื่องว่าคุณเข้าชมเว็บไซต์ใด
เกิดอะไรขึ้นเมื่อตัวกลางล้มเหลว
พร็อกซีแบบชัดแจ้งล้มเหลวแบบปิด คือหยุดกระบวนการพร็อกซีแล้วเบราว์เซอร์หรือแอปจะคืนค่าข้อผิดพลาดการเชื่อมต่อแทนที่จะออกไปตรง ๆ การตั้งค่า PAC และ WPAD คือสิ่งที่ล้มเหลวแบบเปิด หากดึงสคริปต์ไม่ได้ ไคลเอนต์จะกลับไปที่ DIRECT และเว็บไซต์เห็นที่อยู่จริงของคุณอีกครั้ง VPN อาจล้มเหลวแบบเปิดหรือปิดได้ ขึ้นอยู่กับไคลเอนต์และว่าสวิตช์ตัดการเชื่อมต่อหรือกฎไฟร์วอลล์ทำงานอยู่หรือไม่
ทดสอบกรณีล้มเหลวโดยเจตนา หยุดบริการพร็อกซีแล้วโหลดใหม่ หากได้หน้าข้อผิดพลาดแทนการโหลดโดยตรง ให้ชี้ URL ของ PAC ไปยังโฮสต์ที่เข้าถึงไม่ได้เพื่อดูการถอยกลับ หากหน้ายังโหลดผ่านเส้นทางปกติของคุณ พร็อกซีไม่ได้ให้การป้องกันใด ๆ ต่อการหยุดชะงักของตัวเอง และนั่นคือคุณสมบัติที่คุณควรรู้ก่อนจะพึ่งพามัน
ลำดับเป็นตัวกำหนดว่าเว็บไซต์เห็นอะไร พร็อกซีที่ทราฟฟิกขาออกผ่าน VPN ทำให้เว็บไซต์เห็นที่อยู่ของจุดสิ้นสุด VPN วางพร็อกซีไว้นอกอุโมงค์ (VPN ไปยังพร็อกซีบนโฮสต์ระยะไกล) แล้วเว็บไซต์จะเห็นที่อยู่ทางออกของพร็อกซีนั้นแทน ไม่ว่าทางใด การกระโดดสองครั้งสามารถบันทึกสิ่งที่ต่างกันได้
การตรวจสอบห้าข้อตามลำดับ
รายการตรวจสอบด้านล่างคือการตัดสินใจทั้งหมดในที่เดียว ขอบเขตมาก่อนเพราะกำจัดความไม่ตรงกันส่วนใหญ่ได้ หากแอปที่ต้องครอบคลุมไม่เคารพการตั้งค่า ก็ไม่มีสิ่งใดในรายการที่ช่วยได้
| Check | Forward proxy | VPN |
|---|---|---|
| What is covered | The app or browser you configure | Traffic the OS routes into the tunnel, all or split |
| Encryption scope | Protocol-dependent; SOCKS5 alone encrypts nothing | Device to VPN endpoint |
| DNS path | Local or remote, depending on the setting | Normally inside the tunnel |
| Failure mode | Explicit config: connection error; PAC/WPAD: DIRECT fallback | Client policy: fail-open or kill switch |
| What the site sees | The proxy's exit address | The VPN endpoint's exit address |
จากนั้นยืนยันผลด้วยแอปที่ทำให้เกิดการเปลี่ยนแปลง โหลดหน้าในเบราว์เซอร์ที่กำหนดค่าไว้ ดึงหน้าเดียวกันด้วย curl และเปรียบเทียบที่อยู่ที่แต่ละตัวรายงาน หากไม่ตรงกัน แสดงว่าส่วนขยาย กฎ PAC หรือการแทนที่ระดับแอปยังทำงานอยู่ และการปรับอุโมงค์ใด ๆ ก็ไม่แก้ไขได้
บันทึกสิ่งที่คุณกำหนดค่า แอปใดใช้พร็อกซี DNS เป็นแบบในเครื่องหรือระยะไกล UDP ถูกบล็อกหรือไม่ และพฤติกรรมเมื่อล้มเหลวเป็นอย่างไร รายการเล็ก ๆ นี้เองที่ทำให้การเปรียบเทียบครั้งถัดไปเป็นไปได้ เพราะคำว่า “IP เปลี่ยน” ไม่เคยบอกคุณว่าการตรวจสอบห้าข้อใดผ่าน