คำนำหน้าแบบสาธารณะผ่าน OpenVPN: แก้เส้นทางขากลับ

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

คำนำหน้าต้องถูกกำหนดเส้นทางมาที่คุณก่อน

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

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

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

สองระดับการกำหนดเส้นทาง: เส้นทางเคอร์เนลและ iroute

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

เส้นทางฝั่งเซิร์ฟเวอร์มีลักษณะเช่นนี้ โดยคำนำหน้าและมาสก์ต้องตรงกับการจัดสรร:

ip route add 198.51.100.64/28 dev tun0

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

iroute 198.51.100.64 255.255.255.240

เอกสาร ของ OpenVPN เกี่ยวกับเครือข่ายที่กำหนดเส้นทาง อธิบายทั้งสองระดับและเหตุผลที่แยกจากกัน เส้นทางเคอร์เนลที่ไม่มี iroute ส่งแพ็กเก็ตเข้าอุโมงค์โดยไม่มีเจ้าของ และ OpenVPN จะทิ้งมัน iroute ที่ไม่มีเส้นทางเคอร์เนลจะทิ้งแพ็กเก็ตไว้บนเส้นทางเริ่มต้นของเซิร์ฟเวอร์ ข้อผิดพลาดทั้งสองดูเหมือนอุโมงค์ที่เสียจากฝั่งไคลเอนต์

ที่อยู่บริการอยู่ที่ไหน

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

บนไคลเอนต์ Linux ที่สิ้นสุดบริการในเครื่อง ที่อยู่โฮสต์เดียวก็เพียงพอ:

ip address add 198.51.100.70/32 dev lo

หากคำนำหน้าถูกกำหนดเส้นทางต่อไปยังโฮสต์ VM หรือ LAN อื่น ให้กำหนดค่าเส้นทางปลายน้ำนั้นและเส้นทางขากลับแทน การกำหนดที่อยู่ทุกตัวในบล็อกให้ไคลเอนต์ VPN ไม่จำเป็นและสร้างความขัดแย้งในภายหลัง

รักษาต้นทางสาธารณะไว้บนเส้นทางขากลับ

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

ที่เซิร์ฟเวอร์ทางเข้า กฎ masquerade ที่กว้างคือผู้ร้ายปกติ มันเขียนที่อยู่ต้นทางสาธารณะใหม่เป็นที่อยู่หลักของเซิร์ฟเวอร์ และไคลเอนต์ไม่เคยเห็นของจริง:

iptables -t nat -S POSTROUTING

จำกัด NAT เฉพาะไคลเอนต์ VPN ส่วนตัวที่ต้องการ และปล่อยคำนำหน้าที่มอบหมายไว้โดยไม่แปล จากนั้นยืนยันว่าเซิร์ฟเวอร์ส่งต่อคำนำหน้าหรือไม่ เพราะห่วงโซ่การส่งต่อที่ปฏิเสธตามค่าเริ่มต้นจะทิ้งมันอย่างเงียบๆ

ตรวจสอบทั้งสองทิศทางก่อนเชื่อถือ

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

ถามเคอร์เนลว่าเส้นทางใดที่ที่อยู่ที่มอบหมายใช้ และสังเกตอุโมงค์ขณะคำขอทำงาน:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

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

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

สุดท้าย ทดสอบกรณีล้มเหลว หยุดอุโมงค์และยืนยันว่าคำนำหน้าสาธารณะไม่รั่วออกทางอัปลิงก์ปกติ การคืนค่า VPN ควรนำบริการกลับมาโดยไม่ขยายพอร์ตที่โฮสต์เปิดเผย