DNS OpenVPN trên gateway: dnsmasq và phạm vi tường lửa

Các máy khách trên đường hầm đến được gateway, và gateway đến được bộ phân giải nội bộ, nên DNS đáng lẽ phải hoạt động. Nhưng nó không hoạt động, vì đó là hai quyền khác nhau và một dịch vụ DNS hoạt động được là điều thứ ba. Trình lắng nghe phải tồn tại trên một địa chỉ mà máy khách đến được, tường lửa phải cho phép truy vấn tới địa chỉ đó, và máy khách phải được bảo là dùng nó. Mở đường hầm theo cả hai chiều tình cờ giải quyết hai điều đầu và để điều thứ ba dở dang.

Trình lắng nghe là dịch vụ cục bộ có hai chiều

Chiều vào, một máy khách gửi truy vấn tới địa chỉ đường hầm của gateway trên cổng 53. Chiều ra, daemon chuyển tiếp truy vấn đó tới thượng nguồn đã cấu hình. Cả hai nửa đều phải hoạt động, và chúng hỏng theo những cách khác nhau.

Thời gian chờ do máy khách báo và thời gian chờ thấy trên gateway không phải cùng một lỗi.

Gắn địa chỉ đường hầm, không phải mọi địa chỉ

Một thực thể dnsmasq chuyên dụng cho việc này cần một địa chỉ lắng nghe rõ ràng, một chế độ gắn chịu được việc đường hầm xuất hiện sau khi khởi động, và một thượng nguồn rõ ràng. Đây là phiên bản nhỏ nhất tôi dùng:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic gắn các địa chỉ riêng lẻ và xử lý khi tun0 xuất hiện muộn hơn, điều quan trọng trên một máy chủ nơi dịch vụ VPN khởi động lại. Liệt kê loopback giữ cho công cụ cục bộ hoạt động mà không thêm một trình lắng nghe công khai. no-resolv ngăn daemon kế thừa thượng nguồn từ cấu hình bộ phân giải của máy chủ, và no-hosts ngăn thực thể này công bố tệp hosts của gateway. Không tùy chọn nào trong số đó cấp cho ai quyền truy vấn dịch vụ.

Kiểm tra xem có trình lắng nghe sẵn có trên cổng 53 không trước khi khởi động daemon thứ hai, và dùng chủ sở hữu cấu hình của bản phân phối thay vì một tệp lạc trong thư mục sai.

Cho phép đầu vào DNS, không phải lưu lượng xuyên đường hầm

Các quy tắc tường lửa làm được điều này là quy tắc đầu vào cục bộ, giới hạn ở giao diện đường hầm, nhóm máy khách, địa chỉ gateway và cổng 53. Hai quy tắc, mỗi giao thức một cái, là đủ:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS chạy trên TCP cũng như UDP, nên quy tắc chỉ cho UDP để các phản hồi lớn hỏng theo cách trông như ngắt quãng. Đây không phải ufw route quyền, và chúng không được trở thành một sự cho phép rộng trên tun0. Thứ tự quan trọng ngang với nội dung: một quy tắc trước đó loại bỏ toàn bộ đầu vào từ tun0 vẫn thắng, và thêm một sự cho phép bên dưới một lần loại bỏ cuối cùng không tạo ra gì.

Nếu DNS của gateway giờ là một phần của thiết kế, hãy chủ động xem lại chính sách trước đó và ghi lại lý do.

Nửa thượng nguồn là một đường riêng

Các truy vấn rời gateway từ địa chỉ của chính nó về phía bộ phân giải thượng nguồn, nên tuyến của gateway và chính sách đầu ra tới bộ phân giải đó phải cho phép trao đổi. Đây là quy tắc khác với quy tắc cho máy khách đến được trình lắng nghe, và nó hỏng với triệu chứng khác.

Đừng thêm đầu ra đường hầm không giới hạn để phản hồi hoạt động; các phản hồi được theo dõi không cần điều đó.

Đẩy tùy chọn rồi kiểm tra việc bàn giao

Máy chủ có thể quảng bá bộ phân giải cho máy khách bằng một tùy chọn được đẩy. Đó là một tùy chọn, không phải chỉ thị mà hệ điều hành buộc phải tuân theo:

push "dhcp-option DNS 10.90.0.1"

Một máy khách Linux dòng lệnh có thể cần tích hợp bộ phân giải của trình quản lý kết nối, và một thiết bị được quản lý có thể cần hồ sơ quản lý đã cập nhật. Sau khi kết nối, hãy xác nhận bộ phân giải đang hoạt động trên máy khách thay vì giả định việc đẩy đã được áp dụng. Khi hai cơ chế cùng cố đặt DNS, bạn sẽ có một cuộc đua thể hiện như việc phân giải chập chờn.

Mục tiêu là một chủ sở hữu duy nhất cho cấu hình bộ phân giải của máy khách, và việc đẩy thường là chủ sở hữu đó chỉ khi nền tảng máy khách đồng ý.

Kiểm tra thứ bạn thực sự đã dựng

Truy vấn một tên riêng đủ điều kiện hoàn toàn và một tên bên ngoài được phép trực tiếp vào địa chỉ đường hầm, qua cả UDP và TCP. Sau đó lặp lại theo đường tra cứu thông thường của ứng dụng.

Nếu các truy vấn trực tiếp hoạt động mà ứng dụng vẫn hỏng, lỗi nằm ở việc bàn giao chứ không phải ở máy chủ:

• Máy khách chưa bao giờ áp dụng tùy chọn được đẩy.
• Một bộ phân giải khác được đặt sau đó và thắng cuộc đua.
• Ứng dụng dùng thư viện bộ phân giải riêng hoặc một phản hồi đã lưu trong bộ nhớ đệm.

Kết thúc bằng việc xác nhận rằng một nguồn ngoài đường VPN đã được phê duyệt hoàn toàn không thể dùng trình lắng nghe. Phân giải thành công không cấp quyền cho địa chỉ mà nó trả về, nên hãy giữ hai câu hỏi đó tách biệt.