โปรไฟล์ที่ล็อกกับเซิร์ฟเวอร์ล้มเหลวหลังพร็อกซิ TLS: รุ่นไหน?
Access Server 2.8 และ 2.9 สร้างโปรไฟล์ที่ล็อกกับเซิร์ฟเวอร์ต่างกัน ตัดสินใจว่าพร็อกซิของคุณทำให้เส้นทางใดพังก่อนเปลี่ยนส่วนหน้า
ผู้ใช้คนหนึ่งเชื่อมต่อได้ แต่อีกคนไม่ได้ ผ่านพอร์ทัลเดียวกัน ในวันเดียวกัน ทั้งสองมีโปรไฟล์ที่ล็อกกับเซิร์ฟเวอร์ ทั้งสองอยู่บน Access Server บิลด์เดียวกัน และความต่างเดียวคือเวลาโปรไฟล์ถูกสร้างขึ้น นี่คือรูปแบบที่ควรจดจำ เพราะ "ล็อกกับเซิร์ฟเวอร์" บอกชื่อนโยบาย ไม่ใช่ลำดับการเชื่อมต่อ Access Server ได้ส่งมอบสองรุ่นของสิ่งที่ว่านั้น และพร็อกซิย้อนกลับ TLS ยืนอยู่หน้าเส้นทางเดียวเท่านั้นในสองเส้นทาง สามเงื่อนไขเป็นตัวกำหนดว่าคุณอยู่บนกิ่งใด
สองรุ่น สองลำดับการเชื่อมต่อ
ในการออกแบบเก่าที่ใช้ถึง 2.8 ไฟล์ที่นำเข้าคือโปรไฟล์เทียม OpenVPN Connect ใช้มันเพื่อพิสูจน์ตัวกับ API เว็บของ Access Server ผ่าน HTTPS รับโปรไฟล์ชั่วคราวที่ล็อกกับผู้ใช้และโทเคนเซสชัน แล้วจึงสร้าง VPN สองทรานสปอร์ตทำงานตามลำดับ และตัวแรกคือคำขอเว็บธรรมดา
รูปแบบที่นำมาใช้กับ 2.9 ไม่ทำการบูตสแตรปต่อการเชื่อมต่อนั้น เป็นโปรไฟล์แบบเนทีฟที่ใช้ได้โดย OpenVPN ไคลเอนต์ที่เข้ากันได้ ไม่ใช่แค่ OpenVPN Connect การดาวน์โหลดหรือนำเข้าผ่าน URL อาจยังเกี่ยวข้องกับ HTTPS — นั่นคือขั้นตอนการเผยแพร่ ไม่ใช่การดึงโปรไฟล์ชั่วคราวต่อการเชื่อมต่อ
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
การอัปเกรดไม่จำเป็นต้องเขียนทับโปรไฟล์ที่ออกไปแล้ว ดังนั้นเวอร์ชันเซิร์ฟเวอร์ปัจจุบันอาจยังแจกจ่ายสิ่งของเก่าอยู่ บิลด์เซิร์ฟเวอร์บอกคุณว่าอะไรเป็นไปได้ ไม่ใช่สิ่งที่ผู้ใช้คนนี้นำเข้า
สามเงื่อนไขที่เลือกกิ่งของคุณ
เงื่อนไขแรกคือรุ่นของสิ่งที่นั้น ขอไฟล์ ดูว่ามันถูกผลิตอย่างไร และบันทึกเวอร์ชันไคลเอนต์ที่นำเข้ามัน ถ้าคุณระบุรุ่นจากไฟล์ไม่ได้ โปรไฟล์ใหม่ที่ออกให้บัญชีทดสอบจะบอกคุณว่าเซิร์ฟเวอร์ผลิตอะไรในวันนี้ และนั่นเป็นข้อมูลที่ต่างจากที่ผู้ใช้ที่ล้มเหลวมีอยู่
เงื่อนไขที่สองคือสิ่งที่ส่วนหน้าของคุณสิ้นสุดจริง ๆ พร็อกซิย้อนกลับ HTTP ชั้นเจ็ดที่ถอด TLS ไม่ใช่วัตถุเดียวกับตัวส่งต่อ TCP ชั้นสี่ และตัวส่งต่อ UDP ก็ไม่ใช่ การจัดวางปกติของ Access Server บนพอร์ต 443 ทำให้ดีมอน OpenVPN TCP รู้จักทราฟฟิกเบราว์เซอร์และส่งต่อให้บริการเว็บ ดังนั้นการใส่ตัวสิ้นสุด HTTPS ที่ไม่เกี่ยวข้องไว้ข้างหน้าจึงไม่ได้รักษาการจัดการโปรโตคอลของดีมอนนั้น การใช้หมายเลข 443 ร่วมกันไม่ทำให้สองการออกแบบเทียบเท่ากัน
เงื่อนไขที่สามคือความล้มเหลวไปตกที่ใด ความล้มเหลวก่อน VPN และความล้มเหลวของช่องควบคุมดูคล้ายกันในไคลเอนต์ที่บอกเพียง "กำลังเชื่อมต่อ" แต่ทิ้งหลักฐานไว้คนละที่ ถ้ารูปแบบเก่าเกี่ยวข้อง การบูตสแตรปคือผู้ต้องสงสัย ถ้ารูปแบบใหม่เกี่ยวข้อง บันทึกการเข้าถึงเว็บที่ว่างเปล่าเป็นสิ่งที่คาดหมายและไม่ได้พิสูจน์สิ่งใดทั้งสองทาง
เมื่อสิ่งที่นั้นเก่า: การบูตสแตรปล้มเหลวก่อน
อ่านข้อผิดพลาดจริงของไคลเอนต์ ไม่ใช่สถานะสุดท้าย ฟิลด์ที่น่าสนใจคือข้อผิดพลาด HTTPS ตัวตนเซิร์ฟเวอร์ที่ไคลเอนต์คาดไว้ ปลายทางที่คำขอไปถึง และการตรวจสอบใบรับรองเสร็จสิ้นหรือไม่ จากนั้นเทียบกับบันทึกของบริการเว็บและพร็อกซิฝั่งเซิร์ฟเวอร์
การที่เบราว์เซอร์ไปถึงหน้าเข้าสู่ระบบไม่ใช่หลักฐานว่าการพิสูจน์ตัวผ่าน API ของไคลเอนต์นี้สำเร็จ เป็นคำขอคนละแบบ มีความคาดหวังใบรับรองต่างกัน และมักมีชื่อโฮสต์ต่างกัน ถ้าพอร์ทัลให้บริการอย่างถูกต้องแต่ไคลเอนต์ยังล้มเหลว ความไม่ตรงกันอยู่ที่เส้นทางการบูตสแตรป ไม่ใช่รหัสผ่านของผู้ใช้
อย่าทำให้การเปรียบเทียบผ่านด้วยการปิดการตรวจสอบ TLS หรือผ่อนนโยบายการพิสูจน์ตัว นั่นเปลี่ยนความไม่ตรงกันของการตั้งค่าที่วินิจฉัยได้ให้เป็นเส้นทางที่ทำงานได้แต่ไม่ได้ตรวจสอบ และเป็นการเปลี่ยนแปลงที่ทำให้การทดสอบชั่วคราวกลายเป็นช่องโหว่ถาวร เอกสารโปรไฟล์การเชื่อมต่อของ Access Server อธิบายทั้งสองรุ่นและขั้นตอนของโปรไฟล์ชั่วคราว และเป็นเอกสารอ้างอิงที่ควรตรวจสอบก่อนสรุปว่าพร็อกซิเป็นต้นเหตุ
เมื่อสิ่งที่นั้นใหม่: อ่านช่องควบคุมแทน
ด้วยโปรไฟล์สไตล์ 2.9 ไคลเอนต์ไปยังปลายทาง VPN แบบเนทีฟโดยตรง ตรวจสอบปลายทางในโปรไฟล์ ทรานสปอร์ตที่ใช้ และข้อผิดพลาดของช่องควบคุม ถ้าไคลเอนต์ไม่เคยส่งคำขอ HTTP เลย นั่นสอดคล้องกับการออกแบบและไม่ใช่อาการ
ตรงนี้เองที่คำถามเรื่องพร็อกซิเปลี่ยนรูป การถอด HTTPS ไม่สามารถทำให้สตรีมที่เป็น TCP เท่านั้นซึ่งมองไม่เห็นพังได้ แต่ยังทำให้การดาวน์โหลดที่เผยแพร่โปรไฟล์พังได้ และตัวส่งต่อแบบ TCP เท่านั้นจะไม่พา UDP เลย ตรวจสอบว่าทรานสปอร์ตใดที่โปรไฟล์ต้องการก่อนสรุปว่าส่วนหน้าไม่เกี่ยวข้อง
การส่งผ่าน TLS สำหรับสตรีมเดียวเป็นการจัดวางที่แคบ ไม่มีการส่งต่อ UDP และไม่จำลองพฤติกรรมการส่งต่อบริการของดีมอนเองบน 443 ถ้าส่วนหน้าของคุณทำอย่างใดอย่างหนึ่ง บอกว่าเป็นอย่างใด เพราะวิธีแก้ต่างกัน
วิธีแก้ที่ยังคงแคบ
การตรวจสอบที่รบกวนน้อยที่สุดคือสร้างโปรไฟล์ใหม่ที่รองรับสำหรับบัญชีทดสอบและเชื่อมต่อผ่านปลายทางเนทีฟที่ตั้งใจด้วยข้อกำหนดการพิสูจน์ตัวเดียวกัน ถ้าอันนั้นได้ผลแต่โปรไฟล์เก่าที่เก็บไว้ไม่ คุณแยกสิ่งที่นั้นออกจากเซิร์ฟเวอร์และจากพร็อกซิในขั้นตอนเดียว
การเผยแพร่โปรไฟล์ที่ล็อกกับผู้ใช้ ลบการพึ่งพาการบูตสแตรปแบบเดิมออกทั้งหมด เพราะไม่มีการแลกเปลี่ยนโปรไฟล์ชั่วคราวที่อาจล้มเหลว ต้องออกให้ผู้ใช้ที่ตั้งใจไว้ ไม่คัดลอกจากผู้ดูแลระบบ และมันเปลี่ยนสิ่งที่ไคลเอนต์ได้รับอนุญาต จึงควรถือเป็นการตัดสินใจเชิงนโยบาย ไม่ใช่วิธีเลี่ยง
จากนั้นแก้การจัดวางการเผยแพร่ให้มีทุกเส้นทางที่จำเป็น: เส้นทางเว็บสำหรับดาวน์โหลดและการใช้พอร์ทัล และเส้นทาง VPN แบบเนทีฟบนทรานสปอร์ตที่โปรไฟล์คาดไว้ ให้งานของพร็อกซิอยู่ในชั้นเดียว อุโมงค์ที่ล็อกกับผู้ใช้และทำงานได้พิสูจน์ว่าเส้นทางนั้นทำงาน ไม่ได้พิสูจน์ว่าการจัดวางพร็อกซิทุกรูปแบบรองรับทุกรุ่น และความล้มเหลวของการบูตสแตรปแบบเก่าไม่ได้ตำหนิรูปแบบใหม่
- ระบุรุ่นของสิ่งที่นั้นก่อนแตะพร็อกซิ
- ตัดสินว่าความล้มเหลวเกิดก่อนอุโมงค์หรือภายในอุโมงค์
- ยืนยันว่าส่วนหน้าสิ้นสุดอะไร: HTTP สตรีม TCP หรือ UDP
- ทดสอบโปรไฟล์ที่ออกใหม่กับปลายทางเนทีฟโดยไม่เปลี่ยนนโยบาย