VPN over TLS คืออะไร และต่างจาก HTTPS อย่างไร

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

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

ความหมายสองแบบของ "VPN over TLS"

วลีนี้ถูกใช้ค่อนข้างหลวม และสองความหมายที่พบบ่อยทำงานต่างกัน

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

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

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

เกิดอะไรขึ้นระหว่าง handshake

การเชื่อมต่อ VPN แบบ TLS เริ่มต้นเหมือนหน้าเว็บปลอดภัย แต่เพิ่มขั้นตอนสำหรับ VPN ลำดับโดยสรุปเป็นดังนี้

1. เชื่อมต่อ อุปกรณ์เปิดการเชื่อมต่อ TCP ไปยังที่อยู่และพอร์ตของเซิร์ฟเวอร์ VPN
2. Hello ไคลเอนต์แจ้งเวอร์ชัน TLS และชุดอัลกอริทึมที่รองรับ เซิร์ฟเวอร์เลือกหนึ่งชุด ระบบสมัยใหม่นิยม TLS 1.3 ซึ่งเจรจาเสร็จเร็วกว่าและตัดตัวเลือกล้าสมัยหลายอย่างออก
3. ใบรับรองของเซิร์ฟเวอร์ เซิร์ฟเวอร์แสดงใบรับรอง อุปกรณ์ตรวจว่าออกโดยผู้ออกที่เชื่อถือ ยังไม่หมดอายุ และชื่อตรงกับเซิร์ฟเวอร์ที่ตั้งใจจะเชื่อมต่อ
4. ตกลงกุญแจ ทั้งสองฝั่งสร้างกุญแจเซสชันใหม่ ชุดสมัยใหม่ใช้กุญแจชั่วคราว หมายความว่าหากกุญแจระยะยาวรั่วในภายหลัง เซสชันในอดีตก็ยังปลอดภัย คุณสมบัตินี้เรียกว่า forward secrecy
5. ยืนยันตัวตนไคลเอนต์ VPN ต้องรู้ว่าคุณเป็นใคร ตามดีไซน์อาจเป็นชื่อผู้ใช้และรหัสผ่านที่ส่งในช่องเข้ารหัส ใบรับรองฝั่งไคลเอนต์ หรือโทเคน
6. ตั้งค่า เซิร์ฟเวอร์กำหนดที่อยู่ภายในของอุโมงค์และค่าต่าง ๆ เช่น DNS ที่จะใช้ และทราฟฟิกใดควรเข้าอุโมงค์
7. ข้อมูลไหล จากจุดนี้แพ็กเก็ตเดินทางในอุโมงค์ภายใต้กุญแจที่ตกลงกัน

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

แพ็กเก็ตที่อยู่ใน record

เมื่อ TLS เป็นช่องข้อมูล ภาพทางเทคนิคนั้นเรียบง่าย การเชื่อมต่อ TLS คือสายไบต์ที่แบ่งเป็น record ไคลเอนต์ VPN นำแพ็กเก็ต IP แต่ละชิ้นใส่ในกรอบเล็ก ๆ ที่มีความยาวนำหน้า แล้วเขียนลงสายนั้น เซิร์ฟเวอร์อ่านกรอบจากสาย แกะแพ็กเก็ตออกและส่งต่อไปยังอินเทอร์เน็ต คำตอบกลับมาทางเดียวกัน

ผลที่ตามมามีสามข้อ

• สายเชื่อถือได้และเรียงลำดับ TCP รับประกันการส่งถึงและลำดับ แพ็กเก็ตที่หายจะถูกส่งซ้ำก่อนที่อะไรหลังจากนั้นจะถูกส่งมอบ ดีสำหรับโอนไฟล์ แต่ไม่ดีสำหรับทราฟฟิกเรียลไทม์ ซึ่งจะกลับมาพูดถึงด้านล่าง
• แอปของคุณไม่รู้ เบราว์เซอร์ เกม และอีเมลส่งแพ็กเก็ตปกติไปยังสิ่งที่คิดว่าเป็นการ์ดเครือข่ายธรรมดา การทำอุโมงค์มองไม่เห็นสำหรับแอปเหล่านั้น
• ขนาดมีความสำคัญ กรอบและ TLS record เพิ่มไบต์ให้ทุกแพ็กเก็ต หากแพ็กเก็ตบวกส่วนเกินเกินขีดจำกัดของเส้นทาง จะถูกแตกชิ้นหรือทิ้ง นี่คือเหตุผลที่การตั้งค่าอุโมงค์มีค่า MTU และเป็นเหตุผลที่ path MTU discovery ใน RFC 1191 มีอยู่ อุโมงค์ที่ขนาดไม่ถูกจะให้อาการแปลก คือหน้าเล็กโหลดได้แต่หน้าใหญ่ค้าง

มาตรฐานใหม่ RFC 9484 อธิบายการขนแพ็กเก็ต IP ผ่าน HTTP โดยตรง เป็นแนวคิดเดียวกัน คือใช้กลไกของเว็บเป็นพาหะ และแสดงว่าแนวคิดนี้ยังพัฒนาอยู่

TLS ยืนยันอะไร และไม่ยืนยันอะไร

TLS ตอบคำถามเฉพาะบางข้อ การรู้ว่าข้อไหนมีประโยชน์

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

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

ทำไมดีไซน์นี้จึงสำคัญ

ดีไซน์แบบ TLS มีเหตุผลเชิงปฏิบัติที่น่าสนใจ

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

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

ต้นทุนของการวิ่งบน TCP

ข้อแลกเปลี่ยนหลักของการใช้ TLS เป็นช่องข้อมูลคือชั้นขนส่ง อุโมงค์ที่อยู่ใน TCP มักขนทราฟฟิกที่เป็น TCP อยู่แล้ว เช่นหน้าเว็บ ทำให้เกิดการส่งซ้ำสองชั้น

เมื่อแพ็กเก็ตหายบนสายที่ดี ผลน้อยมาก แต่เมื่อสายแย่ เช่น Wi-Fi แออัดหรือสัญญาณมือถืออ่อน ทั้ง TCP ชั้นในและชั้นนอกพยายามซ่อมการสูญหาย โดยแต่ละชั้นมีตัวจับเวลาของตัวเอง สองชั้นอาจรบกวนกัน ชั้นนอกถ่วงแพ็กเก็ตที่ตามมาขณะกู้คืน ชั้นในเห็นว่าไม่ดีจึงชะลอลงอีก ผลคือเห็นอาการค้างแล้วพุ่งเป็นช่วง ๆ รูปแบบนี้บางครั้งเรียกว่า TCP meltdown

ต้นทุนอื่นเล็กกว่า

• ข้อมูลส่วนเกิน ทุกแพ็กเก็ตมีกรอบของ TLS record และกรอบของ VPN ซ้อนอยู่
• Head-of-line blocking แพ็กเก็ตที่มาช้าหนึ่งชิ้นทำให้ทุกชิ้นข้างหลังรอ กระทบการโทรและเกมมากกว่าการดาวน์โหลด
• เวลาของ handshake การเชื่อมต่อใหม่หลังเครือข่ายเปลี่ยนต้องทำ handshake ใหม่ ซึ่งนานกว่าการต่อเซสชันแบบ UDP น้ำหนักเบา

ดีไซน์ TLS ที่ใช้ datagram แบบ UDP สำหรับข้อมูลและใช้ TLS เฉพาะการควบคุมหลีกเลี่ยงต้นทุนเหล่านี้ ซึ่งเป็นเหตุผลที่บางผลิตภัณฑ์เลือกความหมายแรกข้างต้น แนวทางทั่วไปเรื่องสิ่งที่ควบคุมได้และไม่ได้ อยู่ใน ทำไมความเร็วอินเทอร์เน็ตเปลี่ยนเมื่อใช้ VPN

เมื่อมีปัญหา ข้อผิดพลาดของใบรับรองและ TLS

TLS ทำให้ VPN แบบนี้มีรูปแบบความล้มเหลวที่วินิจฉัยง่ายเมื่อรู้จักมัน

1. วันที่หรือเวลาผิด ใบรับรองใช้ได้ระหว่างสองวันที่เท่านั้น ถ้านาฬิกาเครื่องผิด ใบรับรองที่ดีก็ดูเหมือนหมดอายุหรือยังไม่เริ่มใช้ ให้เปิดการตั้งวันที่และเวลาอัตโนมัติแล้วลองใหม่
2. ใบรับรองหมดอายุหรือถูกเปลี่ยน หากใบรับรองของเซิร์ฟเวอร์หมดอายุหรือหมุนเปลี่ยน และแอปผูกกับใบเก่า การเชื่อมต่อจะล้มเหลว โดยปกติเป็นเรื่องของผู้ให้บริการ ให้อัปเดตแอปและติดต่อฝ่ายสนับสนุน
3. ชื่อไม่ตรง ใบรับรองออกให้ชื่อหนึ่งแต่แอปไปถึงเซิร์ฟเวอร์ด้วยอีกชื่อ ตรวจว่าเลือกสถานที่จากรายการ ไม่ใช่พิมพ์ที่อยู่เอง
4. เครือข่ายที่แทรกกลาง TLS เครือข่ายองค์กรหรือโรงเรียนบางแห่งมีอุปกรณ์ที่เซ็นใบรับรองใหม่ให้การเชื่อมต่อ TLS อุปกรณ์ของคุณเห็นใบรับรองจากผู้ออกที่ไม่รู้จักและปฏิเสธ ไคลเอนต์ VPN ที่ถูกต้องควรปฏิเสธ ให้เปลี่ยนไปใช้เครือข่ายที่คุณควบคุมได้ แทนที่จะพยายามข้ามคำเตือน
5. พอร์ตถูกบล็อกหรือถูกหน่วง handshake ไม่เสร็จเพราะพอร์ตถูกกรอง ลองเครือข่ายอื่น เช่น ข้อมูลมือถือ
6. ปัญหา MTU อุโมงค์เชื่อมต่อได้แต่ดาวน์โหลดไฟล์ใหญ่ค้าง ลองลดค่า MTU หากแอปมีตัวเลือกให้

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

TLS 1.2 กับ TLS 1.3 ในงาน VPN

คุณอาจเห็นทั้งสองเวอร์ชัน ความต่างสำคัญกับอุโมงค์มากกว่าหน้าเว็บ เพราะอุโมงค์เชื่อมต่อใหม่บ่อย

ประเด็น	TLS 1.2	TLS 1.3
จำนวนรอบเพื่อเริ่ม	สองรอบ	หนึ่งรอบ มีตัวเลือกต่อเซสชัน
Forward secrecy	ไม่บังคับ ขึ้นกับชุดอัลกอริทึม	บังคับสำหรับการแลกกุญแจ
ตัวเลือกอัลกอริทึมเก่า	มาก บางตัวอ่อน	ถูกตัดออก
การมองเห็น handshake	ฟิลด์ที่เห็นชัดมากกว่า	handshake ส่วนมากถูกเข้ารหัส
ความเร็วเชื่อมต่อใหม่	ช้ากว่า	เร็วกว่าเมื่อต่อเซสชัน

VPN ที่ตั้งค่าดีควรเลือก TLS 1.3 และปฏิเสธเวอร์ชันล้าสมัย ในฐานะผู้ใช้คุณแทบไม่ต้องเลือก ได้ประโยชน์เมื่อแอปและเซิร์ฟเวอร์อัปเดตอยู่เสมอ อีกเหตุผลหนึ่งที่ควรติดตั้งอัปเดตของแอป VPN

สองสถานการณ์สั้น ๆ

นักเดินทางบน Wi-Fi โรงแรม แล็ปท็อปของเมย์เชื่อมต่อ VPN ในโรงแรมไม่ได้ แต่แอปเดียวกันเชื่อมต่อได้ผ่านฮอตสปอตของมือถือ รูปแบบนี้ชี้ไปที่เครือข่ายโรงแรม ซึ่งอาจกรองทราฟฟิกที่ผิดปกติหรือแทรกกลาง TLS ไม่ใช่ที่บัญชีของเธอ เธอไม่พยายามข้ามคำเตือนใด ๆ แต่สลับไปใช้ข้อมูลมือถือสำหรับงานที่ละเอียดอ่อน และแจ้งปัญหาที่แผนกต้อนรับ เพราะกฎของโรงแรมเป็นสิ่งที่โรงแรมกำหนด

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

สรุป

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

หากอยากลอง VPN แบบเติมวันง่าย ๆ ดูวิธีทำงานได้ที่หน้าราคา