แก้ไข DNS ของแขก libvirt ที่ถูกไฟร์วอลล์ VPN แบบอิงมาร์กบล็อก

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

แขกเสีย DNS ทันทีที่อุโมงค์ขึ้น

ยืนยันรูปร่างก่อนจะเปลี่ยนอะไร ลดอุโมงค์ลง รัน dig @192.168.122.1 example.com จากแขกแล้วดูว่ามันตอบ ยกอุโมงค์ขึ้น ทำซ้ำ แล้วดูว่ามันหมดเวลา ผลลัพธ์คู่นั้นตัดเครือข่าย libvirt ที่เสีย ที่อยู่ตัวแก้ชื่อที่ผิด และ dnsmasq ที่ตายไปแล้วออกได้ในขั้นตอนเดียว

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

ทำไมกฎ accept ในเชนถัดไปจึงไม่เคยทำงาน

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

การขยายมันจนกว่าอะไรจะทำงานได้คือกับดักที่สอง การยอมรับซับเน็ต libvirt ทั้งหมดในเส้นทางขาเข้าของโฮสต์เปิดบริการทุกอย่างของโฮสต์ให้แขก เมื่อความต้องการจริงคือพอร์ตเดียว

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

ทำมาร์กคำถามก่อนตาราง VPN จะเห็นมัน

ใส่ข้อยกเว้นไว้ในตารางของมันเอง เพื่อให้ผู้อ่านภายหลังหาเจอโดยไม่ต้องแยกวิเคราะห์กฎ VPN:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

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

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

ให้รูนั้นกว้างเท่าพอร์ต 53

ตามที่เขียนไว้ สิ่งนี้ยอมให้ DNS จากซับเน็ต libvirt ไปยังโฮสต์ผ่าน TCP หรือ UDP พอร์ต 53 และไม่มีอย่างอื่น มันไม่ให้แขกออกอินเทอร์เน็ตนอกอุโมงค์ และไม่ให้โฮสต์เปิดการเชื่อมต่อเข้าหาแขก ถ้าภายหลังแขกต้องการบริการอื่นของโฮสต์ ให้เพิ่มกฎแยกที่ระบุพอร์ตปลายทางนั้นแทนการผ่อนกฎนี้

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

ทำให้มันอยู่รอดหลังรีบูตและพิสูจน์ทั้งสองครึ่ง

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

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

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