Synology NAS ที่มีพอร์ต LAN สองพอร์ต: ทำไมแฮนด์เชก VPN จึงล้มเหลว

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

ไคลเอนต์รายงานอะไรและเกิดอะไรขึ้นจริง

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

พอร์ตและที่อยู่ที่ผูกไว้คือสองข้อเท็จจริงที่ตัดสินว่าแพ็กเก็ตจะมาถึงหรือไม่

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

ค้นหาที่อยู่ที่แพ็กเกจรับฟัง

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

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

sudo ss -lunp | grep 1194

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

แก้ไขการส่งต่อ แล้วเฝ้าดูตัวนับ

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

หาก DSM ได้ที่อยู่นั้นผ่าน DHCP ให้สร้างการจองก่อน การเปลี่ยนแปลงสัญญาเช่าทำลายการส่งต่อที่ทำงานเมื่อวานอย่างเงียบ ๆ

sudo tcpdump -i any -n udp port 1194

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

จากนั้นจึงดูใบรับรองและการขนส่ง

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

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

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