StrongSwan đẩy một địa chỉ DNS mà Mac không thể tới

Mọi thứ hoạt động cho đến khi ai đó mở một chiếc MacBook. Đường hầm được thiết lập, các máy chủ nội bộ trả lời bằng địa chỉ, còn việc phân giải tên thì chết. Trên iPhone cùng một hồ sơ cũng hành xử như vậy, trong khi máy khách Windows và Linux vẫn ổn. Thuộc tính DNS được đẩy xuống thường là thủ phạm: máy chủ phát ra địa chỉ giao diện công cộng của chính nó, và máy khách IKEv2 của Apple không gửi truy vấn tới đó qua đường hầm. Chuyển máy phân giải vào trong bể và triệu chứng biến mất mà không cần chạm vào máy khách.

Triệu chứng chỉ vào địa chỉ được đẩy xuống

Khi chỉ một số nền tảng hỏng, đường hầm và thông tin đăng nhập gần như chắc chắn ổn, vì chúng được dùng chung. Điều khác biệt là cách mỗi máy khách áp dụng tải cấu hình mà nó nhận được, kể cả máy chủ DNS nội bộ. Một máy khách chấp nhận địa chỉ nhưng lại định tuyến truy vấn vòng qua đường hầm sẽ kết thúc với một máy phân giải mà nó nhìn thấy nhưng không dùng được.

Địa chỉ công cộng là lựa chọn thường gặp vì đó là địa chỉ mà quản trị viên đã biết. Đó cũng là địa chỉ duy nhất được bảo đảm nằm ngoài tiền tố của chính đường hầm, và chính tính chất đó làm hỏng máy khách Apple.

Hãy xem giá trị trước khi thay đổi bất cứ điều gì. Nếu máy phân giải được đẩy xuống là địa chỉ WAN của máy chủ, bạn đã tìm ra hình dạng của vấn đề và có thể bỏ qua phần còn lại của việc đoán. Hãy so sánh nó với tiền tố của bể nữa, vì một địa chỉ nằm trong bể nhưng ngoài dải cấp phát chính là hình dạng của bản sửa. Hai phút với cấu hình tốt hơn cả buổi chiều bắt gói tin trên máy khách.

Tách máy phân giải ra khỏi dải cấp phát

Cho đường hầm một quy hoạch địa chỉ trong đó máy phân giải là thành viên của chính mạng con của bể, rồi đặt trước địa chỉ đó để không máy khách nào được cấp nó. Trong ví dụ này bể là 10.180.7.0/24, máy chủ giữ 10.180.7.1, và việc cấp phát bắt đầu từ 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Tiền tố của bể và máy phân giải dùng chung một mạng con, nên tuyến đã chở lưu lượng đường hầm cũng chở các truy vấn. Chính tính chất duy nhất đó làm cho bản sửa có thể mang sang mọi máy khách. Trong cấu hình swanctl, hai sự thật ấy xuất hiện dưới dạng định nghĩa bể và thiết lập DNS trên kết nối, chứ không phải trong cú pháp ipsec.conf.

Máy chủ không cần giao diện vật lý mới cho việc này. Thêm 10.180.7.1 vào giao diện loopback là đủ để máy phân giải ràng buộc và trả lời, vì máy khách tới được nó qua tuyến bể đã tồn tại. Giữ địa chỉ nằm ngoài dải cấp phát để không máy khách nào vô tình chiếm nó. Nếu bể do dịch vụ DHCP hoặc RADIUS bên ngoài quản lý, hãy đặt trước địa chỉ ở đó nữa, nếu không máy khách đầu tiên hỏi sẽ lấy nó.

Ràng buộc máy phân giải và đóng cổng 53

Gán một địa chỉ không giống với việc lắng nghe trên nó. Máy phân giải chỉ lắng nghe trên địa chỉ LAN sẽ từ chối hoặc phớt lờ các truy vấn gửi tới địa chỉ bể, và máy khách thấy một thời gian chờ trông như lỗi định tuyến.

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

Đoạn unbound đó chấp nhận truy vấn từ bể đường hầm và từ chối mọi thứ khác, đó là chính sách mà hầu hết máy phân giải doanh nghiệp muốn. Nếu cùng một thực thể đó cũng trả lời máy khách LAN, hãy thêm tiền tố LAN một cách rõ ràng thay vì mở rộng việc lắng nghe ra mọi nguồn.

Các quy tắc tường lửa sau đó phải khớp với kiểm soát truy cập của chính máy phân giải. Chấp nhận cổng 53 từ bể, và bỏ nó từ mọi nơi khác, nhưng hãy kiểm tra thứ tự chuỗi trước.

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

Một quy tắc chấp nhận rộng hơn đặt trước đó khiến hai dòng cuối thành phẩm trang trí, và máy phân giải vẫn truy cập được từ internet. Hãy đọc tập quy tắc hiệu lực kèm bộ đếm thay vì tin vào thứ tự bạn định đặt. Chính sách thay thế, tức đẩy địa chỉ công cộng và cho phép truy vấn từ mọi nguồn, có hiệu quả với nhiều máy khách, nhưng nó đặt máy phân giải lên internet và cần tự giới hạn tốc độ cùng giám sát.

Xác minh điều máy khách thực sự nhận được

Hãy xem góc nhìn của máy chủ trước, rồi của máy khách, vì hai bên bất đồng theo những cách đáng chú ý. Danh sách bể cho thấy địa chỉ nào đã được cấp, và danh sách liên kết bảo mật cho thấy kết nối có đứng với danh tính mong đợi hay không.

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

Truy vấn trực tiếp chứng minh máy phân giải trả lời trên địa chỉ bể từ một máy có thể tới được nó. Nó không chứng minh Mac đã chọn máy chủ đó. Trên macOS, scutil --dns liệt kê máy phân giải theo từng dịch vụ có phạm vi và nhiều thông tin hơn bảng tóm tắt; trên Windows, Get-DnsClientServerAddress cho thấy bộ điều hợp đường hầm có chấp nhận giá trị được đẩy xuống không.

Nếu máy khách hiển thị địa chỉ bể mà truy vấn vẫn hết thời gian, thì tuyến đường hầm hoặc chuỗi tường lửa là thủ phạm. Một máy khách không báo cáo máy phân giải nào nghĩa là tải cấu hình chưa bao giờ tới, nên hãy xem nền tảng đó áp dụng các thiết lập được đẩy xuống thế nào, chứ không phải mạng. Hãy ghi lại bạn đã quan sát trường hợp nào trong hai trường hợp đó trước khi thay đổi bất cứ thứ gì khác. Hai sự cố ấy trông giống hệt nhau trong một phiếu hỗ trợ và dẫn tới những bản sửa ngược nhau.