StrongSwan ส่งที่อยู่ DNS ที่ Mac เข้าถึงไม่ได้

ทุกอย่างทำงานได้จนกว่าจะมีคนเปิด MacBook อุโมงค์เชื่อมต่อสำเร็จ โฮสต์ภายในตอบสนองด้วยที่อยู่ การแปลงชื่อกลับล้มเหลว บน iPhone โปรไฟล์เดียวกันก็ทำงานแบบเดียวกัน ขณะที่ไคลเอนต์ Windows และ Linux ปกติดี แอตทริบิวต์ DNS ที่ส่งไปมักเป็นตัวการ: เซิร์ฟเวอร์แจกที่อยู่ของอินเทอร์เฟซสาธารณะของตัวเอง และไคลเอนต์ IKEv2 ของ Apple ไม่ส่งคำถามไปที่นั่นผ่านอุโมงค์ ย้ายตัวแก้ชื่อเข้าไปในพูลแล้วอาการจะหายไปโดยไม่ต้องแตะไคลเอนต์

อาการชี้ไปที่ที่อยู่ที่ส่งไป

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

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

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

ตัดตัวแก้ชื่อออกจากช่วงเช่า

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

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

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

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

ผูกตัวแก้ชื่อและปิดพอร์ต 53

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

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

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

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

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

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

ตรวจสอบว่าไคลเอนต์ได้รับอะไรจริง ๆ

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

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

คำถามตรงพิสูจน์ว่าตัวแก้ชื่อตอบบนที่อยู่พูลจากโฮสต์ที่เข้าถึงได้ มันไม่ได้พิสูจน์ว่า Mac เลือกเซิร์ฟเวอร์นั้น บน macOS scutil --dns แสดงรายการตัวแก้ชื่อตามบริการที่มีขอบเขตและให้ข้อมูลมากกว่าแผงสรุป บน Windows Get-DnsClientServerAddress แสดงว่าอะแดปเตอร์อุโมงค์ยอมรับค่าที่ส่งไปหรือไม่

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