tls-auth key-direction: 0 กับ 1 ต้องต่างกัน ไม่ใช่เหมือนกัน
กับ tls-auth ปลายทั้งสองต้องมีทิศทางตรงข้ามกัน คือ 0 กับ 1 หรือทั้งคู่ต้องละเว้นการตั้งค่านี้ หมายเลขเดียวกันจะล้มเหลว และ tls-crypt ไม่เคยใช้ค่านี้
ด้านหนึ่งของอุโมงค์ลงนามในช่องสัญญาณควบคุมด้วยช่องกุญแจที่อีกด้านไม่เคยตรวจสอบ และการเชื่อมต่อก็ตายด้วยข้อผิดพลาดการยืนยันตัวตนก่อนที่จะมีการแลกเปลี่ยนใบรับรองแม้แต่ใบเดียว นี่คือหน้าตาของความไม่ตรงกันของทิศทางใน tls-auth และมันเป็นแบบกำหนดแน่นอน: ไฟล์สองไฟล์เดิมล้มเหลวทุกครั้ง จากทุกเครือข่าย ไม่มีอะไรในบันทึกที่ระบุชื่อตัวเลือกที่คุณกำลังตามหา ผู้คนจึงสร้างกุญแจใหม่และออกใบรับรองซ้ำทั้งที่ไม่เคยเสียหาย ทางแก้คือทำให้ปลายทั้งสองเสริมกัน หรือปล่อยให้ทั้งคู่เป็นสองทิศทาง ไม่ใช่ลดทอนการตรวจสอบ
ความล้มเหลวเกิดก่อนใบรับรอง
กับ tls-auth คู่ปลายทั้งสองถือกุญแจร่วมกันอันเดียวกัน และแต่ละฝ่ายใช้หนึ่งในสองช่องที่ได้มาจากกุญแจนั้น: ช่องหนึ่งลงนามในแพ็กเก็ตควบคุมขาออก อีกช่องตรวจสอบแพ็กเก็ตขาเข้า ทิศทาง 0 และทิศทาง 1 กำหนดบทบาทเหล่านี้ในลำดับตรงกันข้าม คู่จึงต้องเสริมกันเพื่อให้การตรวจ HMAC ตรงกัน เมื่อการกำหนดสลับกันฝ่ายหนึ่ง ผู้รับจะมองหาลายเซ็นในช่องผิดและปฏิเสธแพ็กเก็ต เซสชันจบลงตรงนั้น นี่คือเหตุผลที่ข้อผิดพลาดเกี่ยวกับการยืนยันตัวตนของแพ็กเก็ต ไม่ใช่สิ่งที่ที่เก็บใบรับรองจะสร้างขึ้น
ความแน่นอนมีความสำคัญต่อการวินิจฉัย เพราะปัญหาเรื่องเวลาหรือเส้นทางทิ้งร่องรอยที่ต่างกัน คือการขาดหายเป็นช่วง ๆ ทิศทางหนึ่งล้มเหลว หรือเซสชันที่ตายเฉพาะบางเครือข่าย ความไม่ตรงกันของทิศทางล้มเหลวที่การจับมือครั้งแรกทุกครั้ง และล้มเหลวเหมือนกันบนเครื่องอื่นที่มีไฟล์สองไฟล์เดียวกัน อ่านบันทึกที่ --verb 4 แล้ว หาแพ็กเก็ตแรกที่ถูกปฏิเสธแทนบรรทัดสุดท้าย หากการปฏิเสธนั้นเกิดขึ้นก่อนการแลกเปลี่ยนใบรับรองใด ๆ กุญแจร่วมและทิศทางของมันคือสองสิ่งที่มีค่าควรตรวจสอบ
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
หมายเลขอยู่ที่ไหน
คู่มือ OpenVPN 2.6 ระบุสองตำแหน่งสำหรับทิศทาง: อาร์กิวเมนต์ที่สองของ tls-auth เมื่อกุญแจอยู่ในไฟล์แยก และบรรทัด key-direction เดี่ยวเมื่อกุญแจถูกฝังในโปรไฟล์ ทั้งสองตั้งค่าเดียวกัน โปรไฟล์จึงควรใช้รูปแบบใดรูปแบบหนึ่ง ไม่ใช่ทั้งสอง การละเว้นก็เป็นทางเลือก และมันวางปลายทั้งสองไว้ในการจัดวางแบบสองทิศทางซึ่งทำงานได้เมื่อไม่มีฝ่ายใดระบุทิศทาง คู่ปลายที่มีหมายเลขเดียวกันไม่ได้อยู่ในการจัดวางนั้น: แต่ละฝ่ายคาดว่าจะลงนามในช่องหนึ่งและตรวจสอบในอีกช่องหนึ่ง และทั้งคู่ก็ทำแบบเดียวกัน
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
รูปแบบที่ฝังไว้เป็นคำสั่งบนบรรทัดของตัวเอง ไม่ใช่แอตทริบิวต์บนแท็กเปิดของบล็อกกุญแจ และการเพิ่มอาร์กิวเมนต์ให้แท็กนั้นเป็นข้อผิดพลาด ไม่ใช่การเปลี่ยนทิศทาง ตำแหน่งก็สำคัญ: คำสั่งอยู่นอกบล็อกที่มันเป็นเจ้าของ ค่าที่เขียนไว้ในบล็อกจึงถูกอ่านเป็นเนื้อหากุญแจ คัดลอกการจัดวางที่ผู้แจกจ่ายโปรไฟล์ตั้งใจไว้ แทนที่จะคิดค้นคู่ขึ้นมา เพราะโปรไฟล์ที่ทำงานกับเซิร์ฟเวอร์หนึ่งอาจถูกสะท้อนไว้อีกด้านแล้ว
สิ่งที่ตัวเลือกนี้ไม่แตะต้อง
มันไม่ได้เข้ารหัสทราฟฟิกของแอปพลิเคชัน tls-auth วาง HMAC ไว้รอบแพ็กเก็ตของช่องสัญญาณควบคุม ขณะที่ช่องข้อมูลได้รับการปกป้องด้วยกุญแจเซสชันที่เจรจากันระหว่างการจับมือ คำถามเรื่องทรูพุตหรือรหัสลับจึงไม่เกี่ยวข้องกับหมายเลขทิศทาง การตั้งค่านี้ไม่ได้เพิ่มชั้นการเข้ารหัสที่สอง และนั่นคือสมมติฐานที่ส่งผู้คนไปตามหากุญแจที่ยาวขึ้น
มันใช้ไม่ได้กับ tls-crypt กลไกช่องสัญญาณควบคุมอีกแบบที่มีตัวเลือกและการจัดการกุญแจของตัวเอง และไม่ได้พูดอะไรเกี่ยวกับตัวตนใบรับรองของฝ่ายใดเลย การที่ทิศทางตรงกันและใช้งานได้จึงพิสูจน์เพียงว่าปลายทั้งสองเห็นตรงกันว่าจะยืนยันช่องสัญญาณควบคุมอย่างไร ไม่ได้พิสูจน์ว่าห่วงโซ่ความเชื่อถือได้รับการตรวจสอบแล้ว
จัดให้ตรงกันแล้วเชื่อมต่อใหม่
เปรียบเทียบการกำหนดค่าทั้งสองก่อนจะเปลี่ยนอันใดอันหนึ่ง เพราะการแก้ไขฝ่ายที่ถูกอยู่แล้วจะทำให้งานเพิ่มเป็นสองเท่า grep ด้านล่างแสดงว่าการกำหนดค่าแต่ละไฟล์เลือกกลไกใด การรันแบบละเอียดแสดงว่าช่องสัญญาณควบคุมได้รับการยืนยันหรือไม่ เก็บผลลัพธ์ทั้งสองไว้ เพื่อให้การเปลี่ยนแปลงครั้งต่อไปเทียบกับสถานะที่รู้จักได้
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
รีสตาร์ตปลายทั้งสองหลังการเปลี่ยนแปลงใด ๆ เพราะตัวเลือกเหล่านี้ถูกอ่านครั้งเดียวตอนเริ่มต้น และการโหลดฝ่ายหนึ่งใหม่จะทำให้คู่ไม่สอดคล้องตลอดอายุของเซสชันเก่า หากการติดตั้งใช้งานได้ในตอนนี้โดยไม่ได้กำหนดทิศทาง การเพิ่มการตั้งค่าที่ปลายหนึ่งจะสร้างความล้มเหลวเดิมขึ้นมาอีกครั้ง จะปล่อยทั้งคู่ไว้หรือกำหนดทั้งคู่ก็ได้ เปลี่ยนทีละปลายและเก็บไฟล์ก่อนหน้าไว้ เพื่อให้การถดถอยเป็นการย้อนกลับสองนาที ไม่ใช่การสร้างใหม่
บันทึกกลไก ไฟล์กุญแจ และทิศทางของแต่ละปลายไว้ในบันทึกการติดตั้ง เพราะไม่เช่นนั้นคนถัดไปจะอ่านไฟล์สองไฟล์ที่คล้ายกันและคิดว่าหมายเลขต้องตรงกัน ทิศทางเป็นรายละเอียดของการประสานงาน ไม่ใช่การยกระดับความปลอดภัย: มันแยกสองทิศทางของช่องสัญญาณควบคุมและไม่ได้ทำอะไรอื่น