OpenVPN บนพอร์ต 53: สามบทสนทนาที่คนมักสับสน
การค้นหาชื่อปลายทาง การรับส่งที่เข้ารหัส และ DNS หลังอุโมงค์เป็นสามบทสนทนาที่ต่างกัน ระบุว่าขั้นตอนใดล้มเหลวก่อนจะเปลี่ยนพอร์ตหรือตัวแก้ไขชื่อ
รายงานที่บอกว่า VPN ถูกบล็อกบนพอร์ต 53 มักปนการสังเกตสามอย่างที่ล้มเหลวด้วยเหตุผลต่างกัน การแก้ชื่อปลายทางเกิดขึ้นก่อนจะมีอุโมงค์ใด ๆ การรับส่งที่เข้ารหัสเป็นบทสนทนาแยก และคำถาม DNS ที่ทำหลังจากนั้นเป็นบทที่สาม แต่ละอย่างมีลายเซ็นความล้มเหลวของตัวเอง และมีเพียงอย่างเดียวที่เกี่ยวกับ DNS
ก่อนจะเปลี่ยนอะไร ให้แยกแพ็กเก็ตตามวัตถุประสงค์ เพราะการแก้ไขต้องตามขั้นตอน
สามบทสนทนา หนึ่งหมายเลขพอร์ต
บทสนทนาแรกคือการค้นหาชื่อสำหรับปลายทาง เครื่องของคุณถามตัวแก้ไขชื่อที่ตั้งค่าไว้ว่า vpn.example.com อยู่ที่ใด และคำตอบนั้นมาทาง DNS ปกติก่อนที่ไคลเอนต์จะส่งแพ็กเก็ตอุโมงค์แม้แต่แพ็กเก็ตเดียว บทที่สองคือการรับส่งของ OpenVPN เอง ซึ่งเชื่อมต่อกับที่อยู่ที่การค้นหาให้มา ด้วยโปรโตคอลและพอร์ตที่โปรไฟล์ระบุ บทที่สามเกิดขึ้นหลังอุโมงค์ขึ้นแล้ว เมื่อแอปพลิเคชันขอชื่อและการตั้งค่าตัวแก้ไขชื่อที่ถูกส่งมาจะกำหนดว่าใครเป็นผู้ตอบ
ทั้งสามอย่างนี้อาจสำเร็จหรือล้มเหลวแยกจากกันได้ ไคลเอนต์อาจแก้ชื่อปลายทางได้อย่างสมบูรณ์แต่ยังเข้าถึงผู้รับฟังไม่ได้ และอาจสร้างอุโมงค์ได้ในขณะที่การค้นหาชื่อภายในทุกครั้งล้มเหลวเพราะการตั้งค่า DNS ไม่เคยมาถึง
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
อ่านตารางเป็นรายการตรวจสอบ ไม่ใช่คำอธิบาย ถ้าชื่อปลายทางแก้ไม่ได้ สิ่งอื่นหลังจากนั้นก็ทำงานไม่ได้ และอุโมงค์จะไม่เริ่มต้นเลย
หมายเลขพอร์ตไม่ได้บอกชื่อแอปพลิเคชัน
พอร์ต 53 พา DNS ตามธรรมเนียม และผู้ดูแล OpenVPN ก็อาจเผยแพร่ผู้รับฟังไว้ที่นั่นด้วย ซึ่งเป็นเหตุผลว่าทำไมหมายเลขนี้จึงเป็นตัวระบุที่ไม่ดี เซสชัน OpenVPN บน UDP 53 ก็ยังเป็นเซสชัน OpenVPN และคำถาม DNS ไปยังเซิร์ฟเวอร์บนพอร์ต 53 ไม่ได้บอกอะไรว่าอนุญาตอุโมงค์หรือไม่ บรรทัด proto และ remote ของโปรไฟล์กำหนดปลายทางภายนอก หมายเลขพอร์ตเองไม่ได้กำหนดอะไร
ในการวินิจฉัย สิ่งนี้ตัดได้ทั้งสองทาง การทดสอบ UDP ทั่วไปไปยังพอร์ต 53 พิสูจน์ว่ามีพอร์ตที่ตอบ ไม่ได้พิสูจน์ว่าบริการ VPN ตอบ ทดสอบด้วยไคลเอนต์จริงและโปรไฟล์จริง เพราะมีเพียงวิธีนั้นที่ฝึกการจับมือที่บริการคาดหวัง
พิสูจน์ผู้รับฟังก่อนโทษเครือข่าย
บนเซิร์ฟเวอร์ ตรวจสอบว่ามีอะไรผูกอยู่ด้วย ss -lunp | grep 53 และเทียบกับโปรโตคอลและพอร์ตของโปรไฟล์ จากเครือข่ายของไคลเอนต์ ให้รันไคลเอนต์ด้วยระดับรายละเอียดที่สูงขึ้นเพื่อให้บันทึกแสดงว่าได้ลองที่อยู่และการรับส่งใด ถ้าเซิร์ฟเวอร์กำลังฟังอยู่แต่แพ็กเก็ตของไคลเอนต์ไม่มาถึง แสดงว่าเส้นทางหรือนโยบายปฏิเสธ และนั่นคือบทสนทนากับเจ้าของเครือข่าย ไม่ใช่เหตุผลให้เปลี่ยนพอร์ต
พอร์ตอื่นช่วยได้เฉพาะเมื่อบริการฟังอยู่ที่นั่นจริงและสภาพการติดตั้งอนุญาต การย้ายผู้รับฟังเพื่อหลบการกรองของเครือข่ายที่มีผู้จัดการเป็นการตัดสินใจเชิงนโยบาย ไม่ใช่ขั้นตอนแก้ปัญหา ถามเจ้าของเครือข่ายว่าอนุญาตอะไรก่อนเปลี่ยนบริการ เพราะทางลัดที่ฝ่าฝืนนโยบายจะถูกปิดในภายหลังอยู่ดี จดคำตอบนั้นไว้ข้างโปรไฟล์เพื่อให้คนถัดไปไม่ต้องขอซ้ำ
ตรวจสอบ DNS หลังอุโมงค์แยกต่างหาก
เมื่ออุโมงค์ขึ้นแล้ว ให้ตรวจสอบสถานะตัวแก้ไขชื่อบนอินเทอร์เฟซ VPN และถามหาชื่อภายในหนึ่งชื่อและชื่อสาธารณะหนึ่งชื่อ ถ้าชื่อภายในล้มเหลวในขณะที่อุโมงค์รับส่งข้อมูลอยู่ แสดงว่าการตั้งค่า DNS ที่ส่งมาไม่ได้ถูกนำไปใช้ ซึ่งเป็นเรื่องของการผสานรวมไคลเอนต์ไม่ใช่การรับส่ง ถ้าชื่อสาธารณะล้มเหลวแต่ชื่อภายในทำงาน นโยบายอุโมงค์แบบแยกส่วนก็ทำตามที่ตั้งค่าไว้
ปล่อยการเปลี่ยนแปลง DNS ให้เจ้าของตัวแก้ไขชื่อ การเขียนทับการตั้งค่าตัวแก้ไขชื่อที่มีผู้จัดการเพื่อให้การทดสอบหนึ่งครั้งผ่านอาจทำให้ชื่อส่วนตัวเสียหายสำหรับทุกอย่างอื่นบนเครื่อง ถ้าอุโมงค์ส่งตัวแก้ไขชื่อมาและไคลเอนต์ไม่สนใจ ให้แก้การผสานรวมของไคลเอนต์แทนการเพิ่มรายการแบบคงที่ที่อื่น รายการแบบคงที่ปกปิดความล้มเหลวจนกว่าจะมีคนเปลี่ยนเครือข่าย จดว่าตัวแก้ไขชื่อใดควรตอบเนมสเปซใด