DNS ของปลายทาง AWS Client VPN: ทำไมการตรึง IP ที่แก้ไขแล้วจึงล้มเหลว
แทนที่ชื่อปลายทางของ AWS Client VPN ด้วยที่อยู่ที่คุณแก้ไขได้ แล้วอุโมงค์จะหยุดทำงานในภายหลัง เก็บชื่อที่ส่งออกและคำนำหน้าแบบสุ่มไว้
สัปดาห์ที่แล้ว dig +short ให้ที่อยู่หนึ่งรายการสำหรับชื่อปลายทางในโปรไฟล์ AWS Client VPN ของคุณ และอุโมงค์ก็เชื่อมต่อได้ สัปดาห์นี้โปรไฟล์เดิมค้างอยู่ที่ 'Connecting' บนแล็ปท็อปของคุณ ขณะที่สำเนาของเพื่อนร่วมงานที่ไม่ได้แตะต้องยังใช้งานได้ ไม่มีอะไรถูกบล็อกและใบรับรองไม่ได้หมดอายุ มีคนแทนที่ชื่อโฮสต์ของปลายทางด้วยที่อยู่ที่แก้ไขได้นั้น และบริการก็ไม่ตอบสนองที่นั่นอีกต่อไป ชื่อที่ส่งออกคือส่วนที่สร้างขึ้นเพื่อให้ทนต่อการเปลี่ยนแปลงนั้น
ชื่อในโปรไฟล์ของคุณอาจไม่ใช่ชื่อที่ถูกถาม
โปรไฟล์ที่ส่งออกจาก Client VPN มักมี remote-random-hostname เมื่อเปิดตัวเลือกนั้น ไคลเอนต์จะสร้างป้ายกำกับใช้ครั้งเดียว เชื่อมกับชื่อปลายทางด้วยจุด และแก้ไขชื่อที่รวมกัน บันทึกไวลด์การ์ดในโซนของปลายทางตอบทุกป้ายกำกับ นั่นคือเหตุผลที่คำนำหน้าที่สร้างขึ้นยังแก้ไขได้ และเหตุผลที่กลอุบายนี้ยังมองไม่เห็นเมื่อคุณพยายามทำซ้ำคำถามด้วยมือ
ดังนั้นเมื่อคุณวางชื่อปลายทางในเทอร์มินัลและได้คำตอบ คุณได้แก้ไขชื่ออื่นที่ไม่ใช่ชื่อที่ไคลเอนต์ใช้เมื่อเชื่อมต่อ ความไม่ตรงกันนี้ไม่ใช่ข้อบกพร่องที่ต้องแก้ในโปรไฟล์ ป้ายกำกับถูกสร้างใหม่โดยเจตนา: ตัวเลือกนี้ป้องกันไม่ให้แคชเก็บคำตอบเก่า และไม่เคยระบุเครื่องหรือเซสชันของคุณ
ฉันเคยพบกรณีความเข้ากันได้ที่ไคลเอนต์เพิกเฉยต่อตัวเลือกนี้ทั้งหมด AWS บันทึกวิธีแก้ไว้: เก็บชื่อปลายทางจริงไว้และเติมสตริงสุ่มกับจุดไว้ข้างหน้า โดยถือว่าเป็นรูปแบบการตั้งชื่อไม่ใช่ค่าที่จะวาง การนำไปใช้กับไคลเอนต์เก่านั้นสมเหตุสมผล การเขียนโค้ดตายตัวของสตริงที่มีคำนำหน้าเป็นปลายทางนั้นไม่สมเหตุสมผล
ทำไมคำตอบที่บันทึกไว้จึงไม่สามารถคงความถูกต้องได้
ที่อยู่ของปลายทาง Client VPN ได้รับการจัดการโดย AWS และเปลี่ยนแปลงตามเวลา ซึ่งเอกสารแนวปฏิบัติที่ดีที่สุดระบุไว้อย่างชัดเจน คำตอบที่บันทึกไว้เป็นภาพรวมของการแก้ไขครั้งเดียว โปรไฟล์ที่เขียนโค้ดตายตัวจะกลายเป็นโปรไฟล์ที่เล็งไปยังโฮสต์ที่เลิกใช้แล้วทันทีที่บริการย้าย และความล้มเหลวมักไม่ดูเหมือน DNS: คุณจะได้รับการหมดเวลาการเชื่อมต่อหรือแฮนด์เชคที่ค้าง ผู้คนจึงไล่ตามเส้นทางและใบรับรอง
คำตอบเดียวกันใน /etc/hosts สืบทอดวันหมดอายุเดียวกันพร้อมปัญหาเพิ่มเติม รายการ hosts อยู่รอดจากการรีบูต การส่งออกซ้ำ และการแก้ไข 'ติดตั้งไคลเอนต์ใหม่' ดังนั้นความล้มเหลวจึงกลับมาทุกครั้งที่ที่อยู่ย้าย ฉันเคยเห็นรายการหนึ่งอยู่อย่างไม่เป็นอันตรายหลายสัปดาห์ แล้วทำให้ทุกเครื่องที่พกมันไปหยุดทำงาน ขณะที่การติดตั้งใหม่เชื่อมต่อได้ตามปกติ การแบ่งแยกนั้น กลุ่มหนึ่งล้มเหลวและอีกกลุ่มปกติดีในบัญชีเดียวกัน คือเบาะแสที่ถูกที่สุดที่คุณจะได้
กำหนดขอบเขตการสุ่มให้ถูกต้อง มันเกิดขึ้นต่อการพยายามเชื่อมต่อหนึ่งครั้ง อุโมงค์ที่สร้างแล้วจะไม่แก้ไขปลายทางซ้ำ ไม่สลับเซิร์ฟเวอร์กลางเซสชัน และคำขอของแอปพลิเคชันแต่ละรายการไม่ได้เลือกโฮสต์ VPN ใหม่ทุกครั้ง มีเพียงการพยายามครั้งถัดไปเท่านั้นที่แก้ไขใหม่ นั่นคือเหตุผลที่เซสชันที่ทำงานได้ตลอดบ่ายไม่ได้บอกอะไรเกี่ยวกับเช้าวันพรุ่งนี้
บริการตรวจสอบอะไรเมื่ออุโมงค์ขึ้น
Client VPN กำหนดให้ที่อยู่ที่คุณเชื่อมต่ออยู่ตรงกับที่อยู่ที่แก้ไขสำหรับชื่อ DNS ของปลายทาง ข้อกำหนดเดียวนี้อธิบายความล้มเหลวหลายอย่างที่ดูไม่เกี่ยวข้องกัน: บันทึก DNS ที่กำหนดเองชี้ไปที่อื่น ฟรอนต์เอนด์ที่กำหนดเองซึ่งส่งต่อไปยังที่อยู่ปลายทางจริง และโปรไฟล์ที่เขียนใหม่เป็นที่อยู่ดิบ AWS บันทึกการจัดวางบันทึกที่กำหนดเองบวกการส่งต่อว่าเป็นความล้มเหลวกับไคลเอนต์ที่ AWS จัดหาให้รุ่นใหม่ การตรวจสอบนั้นแคบ ไม่ใช่คำตัดสินว่าทุกนามแฝงถูกห้าม
นี่ไม่ใช่กฎทั่วไปเกี่ยวกับโปรโตคอล VPN ด้วย remote แบบตัวเลขใช้ได้เต็มที่ในการติดตั้ง OpenVPN ทั่วไป และหลายแห่งทำงานเช่นนั้น ข้อจำกัดมาจากการจัดวางที่จัดการให้ ไม่ใช่จากโปรโตคอลข้างใต้
ซึ่งทำให้การผ่อนปรนการตรวจสอบใบรับรองเป็นปฏิกิริยาที่ผิด หากโปรไฟล์ล้มเหลวหลังการสลับที่อยู่ การปิดการตรวจสอบเซิร์ฟเวอร์จะย้ายข้อผิดพลาดแทนที่จะแก้ไขการแก้ชื่อหรือข้อกำหนดการตรงกันของที่อยู่ และทิ้งไคลเอนต์ที่จะเชื่อทุกสิ่ง เก็บ CA ที่ส่งออก การตรวจสอบเซิร์ฟเวอร์ และการตั้งค่าการพิสูจน์ตัวตนทั้งสองฝ่ายไว้ตามเดิม
รายการอนุญาต การออกและ DNS ส่วนตัวเป็นสามปัญหาที่แยกกัน
กฎไฟร์วอลล์ที่ต้องอนุญาตปลายทางก่อนที่แล็ปท็อปจะเชื่อมต่อนั้นเกี่ยวกับตัวรับฟังชั้นนอก ให้ชื่อปลายทาง การขนส่ง และพอร์ตที่กำหนดค่าไว้แก่เจ้าของเครือข่าย แล้วถามว่าการควบคุมของพวกเขาสามารถติดตามพฤติกรรม DNS ของบริการได้หรือไม่ กฎที่เก็บที่อยู่ที่จับได้หนึ่งรายการคือภาพรวมที่มีวันหมดอายุที่ไม่ได้เขียนไว้ หากการควบคุมยอมรับเฉพาะปลายทางที่ไม่เปลี่ยนแปลง ให้แก้ช่องว่างนั้นก่อนการเปิดตัวแทนที่จะเขียนโค้ดคำตอบอย่างเงียบ ๆ
พันธมิตรที่ต้องการที่อยู่ต้นทางคงที่สำหรับคำขอหลังอุโมงค์ขึ้นแล้วมีความต้องการอีกอย่าง: ขาออก สิ่งที่เว็บไซต์เห็นขึ้นอยู่กับเส้นทางของแอปพลิเคชันและนโยบายอุโมงค์แยก ไม่ใช่ที่อยู่ที่ไคลเอนต์เชื่อมต่อ การรับส่งในอุโมงค์แยกอาจไม่แตะ AWS เลย
DNS ส่วนตัวภายในอุโมงค์เป็นชั้นที่สาม ตัวแก้ชื่อที่มอบให้ไคลเอนต์ตอบชื่อภายในหลังการเชื่อมต่อ มันไม่สามารถแก้ไขปลายทางสาธารณะก่อนที่อุโมงค์จะมีอยู่ ความล้มเหลวในการแก้ชื่อปลายทางและความล้มเหลวในการแก้ชื่อแอปพลิเคชันภายในเกิดขึ้นในขั้นตอนต่างกัน และการผสมปนกันจะพาคุณไปยังบันทึกผิด
ตระกูลที่อยู่ก็อยู่ในรายการเดียวกัน คำตอบ IPv4 ไม่ได้บอกอะไรเกี่ยวกับเส้นทางที่อนุญาตของปลายทาง IPv6 หรือสองสแต็ก ดังนั้นภาพรวมที่ถ่ายในตระกูลหนึ่งจึงไม่ใช่หลักฐานสำหรับอีกตระกูล
ตรวจสอบการเชื่อมต่อโดยไม่ตรึงอะไรเลย
เริ่มจากโปรไฟล์ตามที่ส่งออกและอ่านว่ามันขออะไรจริง ๆ:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'จากนั้นเปรียบเทียบสามสิ่ง: ชื่อปลายทางที่โปรไฟล์ถืออยู่ ที่อยู่ที่ไคลเอนต์รายงานสำหรับการพยายามครั้งใหม่ และสิ่งที่ชื่อแก้ไขได้ในตอนนี้ ชื่อที่แก้ไขได้พิสูจน์เพียงว่าบันทึกตอบสนอง การขนส่งและการพิสูจน์ตัวตนแยกกัน และปลายทางไม่จำเป็นต้องตอบ ping บันทึกของไคลเอนต์เองเป็นแหล่งเดียวสำหรับรายการกลาง ดังนั้นจับไว้ระหว่างการพยายามไม่ใช่หลังจากนั้น
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
ที่อยู่ที่ตอบวันนี้เป็นหลักฐานเกี่ยวกับวันนี้ ชื่อคือสิ่งที่บริการรักษาให้ใช้ได้ บันทึกข้อสังเกต ส่งให้เจ้าของปลายทาง และปล่อยให้โปรไฟล์ชี้ไปที่ชื่อ
สองนิสัยที่ควรเลิก: การปิดการตรวจสอบใบรับรองเพื่อข้ามแฮนด์เชคที่ค้าง และการกองป้ายกำกับไว้หน้าชื่อปลายทางโดยหวังว่าสักอันจะติด ป้ายกำกับแก้ไขได้ผ่านบันทึกไวลด์การ์ด หรือปัญหาอยู่ที่อื่น หากโปรไฟล์ที่กำหนดค่าอย่างถูกต้องยังล้มเหลว ให้ส่งคำถามที่แน่นอนและเหตุการณ์การเชื่อมต่อ ไม่ใช่ชื่อโฮสต์ที่ยาวขึ้น
ก่อนปิด: โปรไฟล์ยังมีชื่อปลายทางที่ส่งออก ไม่มีไฟล์ hosts ใดตรึงที่อยู่ remote ในบันทึกไคลเอนต์ตรงกับการแก้ชื่อปัจจุบัน และกฎไฟร์วอลล์ระบุชื่อปลายทางไม่ใช่ที่อยู่ นี่คือสถานะที่ต้องส่งต่อให้คนถัดไปเช่นกัน