วิธีตรวจสอบเซิร์ฟเวอร์ของโปรไฟล์ OpenVPN ก่อนนำเข้า

มีคนส่งโปรไฟล์มาให้คุณ คุณนำเข้ามา และสามสิบวินาทีต่อมาไคลเอนต์กำลังต่อปลายทางที่ไม่มีใครตรวจสอบ อ่านไฟล์ในโปรแกรมแก้ไขข้อความก่อน เพราะทุกอย่างที่สำคัญอยู่ในคำสั่งเพียงไม่กี่ตัว: remote, proto, port, ca, cert, tls-crypt และ verify-x509-name ที่เหลือเป็นค่าเริ่มต้น และความประหลาดใจก็อาศัยอยู่ตรงนั้น

ระบุปลายทางทั้งหมดที่ไฟล์ใช้ได้

เริ่มจากปลายทาง เพราะโปรไฟล์เดียวอาจมีหลายปลายทาง grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn พิมพ์ผู้สมัครทุกตัวตามลำดับในไฟล์ รวมถึงตัวที่ซ้อนอยู่ในบล็อก <connection> แบบอินไลน์

เมื่อคำสั่งไม่ระบุพอร์ต ไคลเอนต์จะกลับไปใช้ค่าเริ่มต้นของผู้รับฟัง ดังนั้น remote vpn.example.com เพียงอย่างเดียวหมายถึงพอร์ต 1194 พร้อมกับ proto ตัวใดก็ตามที่ปรากฏภายหลังในไฟล์ บรรทัด remote ธรรมดาหลายบรรทัดเป็นทางเลือก: ไคลเอนต์จะลองตามลำดับเว้นแต่ remote-random จะสลับให้ และมันไม่เคยแทนที่โฮสต์ของผู้ให้บริการรายอื่นอย่างเงียบ ๆ สองบรรทัด remote บนโดเมนที่ไม่เกี่ยวข้องกันคือจุดที่คุณหยุดและถามว่าอันไหนคือสิ่งที่ตั้งใจ

สังเกตการสะกดของ proto ด้วย tcp ได้รับการยอมรับเป็นคำพ้องของ tcp-client ฝั่งไคลเอนต์ แต่ tcp-server ในโปรไฟล์ไคลเอนต์เป็นข้อผิดพลาดของการกำหนดค่าที่มักค้างแทนที่จะล้มเหลวอย่างสะอาด

ยืนยันชื่อก่อน แล้วจึงยืนยันพอร์ต

dig +short vpn.example.com บอกคุณว่าชื่อมีอยู่หรือไม่และคืนค่าแอดเดรสใด และปลายทางที่มีหลายแอดเดรสหรืออยู่หลังพร็อกซี่อาจคืนค่าหลายค่าได้อย่างชอบธรรม การแปลงชื่อเป็นเงื่อนไขเบื้องต้น ไม่ใช่หลักฐานความเป็นเจ้าของ ใครก็ชี้ชื่อไปที่แอดเดรสได้ และแอดเดรสเดียวตอบหลายชื่อได้

จากนั้นตรวจสอบผู้รับฟังบนพอร์ตที่คุณพบ ให้ตรงกับการรับส่ง บน TCP openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com พิมพ์ห่วงโซ่ที่เซิร์ฟเวอร์นำเสนอ บน UDP คุณต้องใช้ DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 ทำแฮนด์เชกเดียวกันผ่านเดตาแกรม แฮนด์เชกที่เสร็จสมบูรณ์พิสูจน์ว่ามีบางอย่างกำลังฟังและถือใบรับรอง ซึ่งมากกว่าที่ ping แสดงและน้อยกว่าที่การตั้งค่าความเชื่อถือของโปรไฟล์เองเรียกร้อง

เมื่อแฮนด์เชกล้มเหลวและโฮสต์ตอบ ping พอร์ตน่าจะผิดหรือถูกกรอง มองสิ่งนั้นเป็นเหตุผลที่จะขอพอร์ตที่ถูกต้อง ไม่ใช่คำเชิญให้กวาดพอร์ตข้างเคียง nc -vzu ก็รายงานความสำเร็จบนสแตกบางตัวในขณะที่ไม่มีอะไรฟัง ดังนั้นการทดสอบ UDP เปล่า ๆ ไม่มีความหมายหากไม่มีแฮนด์เชกอยู่ข้างหลัง

อ่านหมุดความเชื่อถือแยกจากแอดเดรส

แอดเดรสตัดสินว่าไคลเอนต์ไปที่ไหน บล็อกความเชื่อถือตัดสินว่าเชื่อใครเมื่อไปถึง verify-x509-name "vpn.example.com" name ปักหมุดชื่อสามัญของหัวข้อ และ remote-cert-tls server กำหนดให้ใช้คีย์แบบขยายสำหรับการพิสูจน์ตัวตนเซิร์ฟเวอร์ โปรไฟล์ที่ผู้ให้บริการมอบให้ควรมีทั้งสองอย่าง

มองหา ca บล็อก <ca> แบบอินไลน์ และ tls-crypt หรือ tls-auth โปรไฟล์ที่ใช้ tls-auth ต้องมี key-direction 1 ฝั่งไคลเอนต์เมื่อฝั่งเซิร์ฟเวอร์ใช้ทิศทาง 0 และความไม่ตรงกันทำให้แฮนด์เชกล้มเหลวด้วยข้อผิดพลาด TLS ที่อ่านดูเหมือนความบกพร่องของใบรับรอง CA แบบอินไลน์ที่ไม่ได้เป็นของผู้ให้บริการที่คุณเพิ่งแปลงชื่อหมายความว่าไฟล์ถูกประกอบจากสองแหล่ง และนั่นคือกรณีที่ควรปฏิเสธอย่างเด็ดขาด

verify-x509-name รับโหมด name name-prefix หรือ subject และตัวสุดท้ายคาดหวังชื่อที่แตกต่างเต็มรูปแบบในลำดับเดียวกับที่เซิร์ฟเวอร์พิมพ์ เลือกโหมดที่ตรงกับรูปร่างของค่า เพราะไคลเอนต์ปฏิเสธทุกการเชื่อมต่อแทนที่จะเตือนเกี่ยวกับการใกล้เคียง สำหรับไฟล์ที่คุณไม่ได้เขียน name พร้อมชื่อโฮสต์ธรรมดาคือทางเลือกที่คาดไม่ถึงน้อยที่สุด

ตรวจสอบตัวเลือกที่ล้มเหลวอย่างเงียบ ๆ

OpenVPN 2.6 เจรจาไซเฟอร์ผ่าน data-ciphers และโปรไฟล์ที่มีเพียงบรรทัด cipher AES-256-CBC เก่า ๆ อาจทำให้ช่องควบคุมเสร็จสมบูรณ์แล้วค้างที่ข้อมูล การอ่านค่านั้นบอกคุณว่าไฟล์เก่ากว่าเซิร์ฟเวอร์ที่คุณกำลังเข้าร่วมหรือไม่ หน้าคู่มือของ 2.6 ระบุลำดับการเจรจาไว้หากคุณต้องอ้างถึงผู้ให้บริการ

auth-user-pass ที่ไม่มีชื่อไฟล์หมายความว่าไคลเอนต์จะถาม ดังนั้นโปรไฟล์ที่ดูเหมือนพึ่งพาตนเองได้ก็ยังต้องการข้อมูลรับรอง auth-user-pass credentials.txt หมายความว่ามันคาดหวังไฟล์ที่อาจไม่ได้ส่งมาให้คุณ nobind และ resolv-retry infinite เป็นเรื่องปกติและไม่เป็นอันตราย ในขณะที่ explicit-exit-notify ใช้กับ UDP เท่านั้นและไม่มีประโยชน์บน TCP

ไม่มีข้อใดเปลี่ยนว่าโปรไฟล์เชื่อมต่อที่ไหน แต่แต่ละข้อเปลี่ยนว่าจะเชื่อมต่อหรือไม่ และไม่มีข้อใดมองเห็นได้ในกล่องโต้ตอบการนำเข้าของไคลเอนต์

ตัดสินใจ แล้วบันทึกสิ่งที่คุณตัดสินใจ

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

บันทึกแฮชที่คุณตรวจสอบไว้ เพื่อให้คนถัดไปรู้ว่าไฟล์เปลี่ยนหรือไม่: sha256sum profile.ovpn ติดไว้ข้างปลายทางในบันทึกของคุณ โปรไฟล์คือการจัดวางทั้งหมด ไม่ใช่รายการแอดเดรส ดังนั้นอย่าเชื่อม remote ที่ใช้งานได้เข้ากับบล็อกความเชื่อถือของคนอื่นโดยเก็บข้อมูลรับรองของพวกเขาไว้

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

ถ้าคุณนำเข้ามันและความพยายามครั้งแรกล้มเหลว ให้รันไคลเอนต์ด้วย --verb 3 และอ่านสิบบรรทัดแรก: แอดเดรส remote ที่แปลงแล้ว proto ที่เจรจา และข้อผิดพลาด TLS ปรากฏในลำดับนั้น ซึ่งบอกคุณว่าคุณข้ามการตรวจสอบใดข้างต้นไป