ทำไมไคลเอนต์ OpenVPN จึงไม่ตรงกับตัวเลือก IPsec ของเกตเวย์

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

ping จากเกตเวย์ทดสอบโฟลว์ที่ไคลเอนต์ของคุณไม่เคยใช้

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

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

พุชคำนำหน้าระยะไกลที่แอปพลิเคชันต้องการจริง

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

บนเซิร์ฟเวอร์ Community ที่รับเส้นทางแบบพุช คำสั่งจะใช้มาสก์จริง: push "route 172.30.239.0 255.255.255.128" Access Server กำหนดปลายทางเดียวกันผ่านการตั้งค่าเครือข่ายส่วนตัวหรือกฎการเข้าถึงของเวอร์ชันที่ติดตั้ง โดยเลือกโหมด routed หรือ translated อย่างตั้งใจ การแก้ไขเชนไฟร์วอลล์ที่สร้างขึ้นแทนการตั้งค่าเจ้าของคือหนทางที่ทำให้การติดตั้งที่ใช้งานได้กลายเป็นสิ่งที่ทำซ้ำไม่ได้

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

ทำให้ตัวเลือกรวมพูลไคลเอนต์

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

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

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

เลือกการกำหนดเส้นทางหรือการแปลอย่างตั้งใจ

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

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

ปิดวงจรที่การส่งต่อและคำตอบ

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

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

รักษาการอนุญาตปลายทางให้แคบขณะทดสอบ และยืนยันว่าไคลเอนต์ที่ไม่มีกฎไม่สามารถเข้าถึงบริการได้ เส้นทางที่ติดตั้งไว้พร้อมการเชื่อมโยงที่สร้างขึ้นไม่เหมือนกับการเข้าถึงที่ได้รับอนุญาต