UFW loại bỏ máy chủ DNS của VPN ngay khi đường hầm đi lên

Tên miền ngừng được phân giải ngay khoảnh khắc VPN kết nối, trong khi ping tới một địa chỉ công cộng vẫn trả lời và trạng thái tường lửa không hiển thị gì có vẻ sai. Không có gì thay đổi trong chính sách; điều đã thay đổi là một giao diện mới xuất hiện, và lệnh từ chối mặc định bao phủ nó ngay từ gói đầu tiên. UFW quyết định theo hướng và giao diện, nên một quy tắc viết cho liên kết không dây không nói gì về lưu lượng rời khỏi đường hầm. Cách sửa là một nhúm quy tắc hẹp được áp dụng theo một thứ tự nhất định.

Triệu chứng chỉ xuất hiện sau khi đường hầm đi lên

Chính sách từ chối mặc định làm đúng những gì được bảo: mọi thứ không có quy tắc khớp đều bị từ chối, trên mọi giao diện tồn tại. Đường hầm chưa tồn tại khi các quy tắc được viết, nên không quy tắc nào bắt được nó, và lệnh từ chối vốn luôn ở đó nay áp dụng cho việc phân giải tên. Lưu lượng trực tiếp tới một địa chỉ nguyên văn vẫn có thể hoạt động khi một quyền cho phép rộng hơn bao phủ nó, và đó là lý do ping tới một trình phân giải công cộng thành công trong khi tra cứu tên thất bại. Khoảng trống là một quy tắc cho giao diện mà chính sách chưa từng thấy.

Điều đó cũng giải thích vì sao lỗi đảo ngược gọn gàng: bỏ đường hầm và tên lại được phân giải, vì truy vấn quay về một giao diện có quy tắc. Một chính sách chỉ thất bại khi đường hầm đi lên không phải vấn đề DNS, và việc chỉnh chính trình phân giải là thứ tốn thời gian nhất ở đây. Đọc danh sách giao diện trước khi đọc cấu hình trình phân giải.

Ba hướng, ba bộ quy tắc khác nhau

Một phiên chạm vào các quy tắc ở nhiều hơn một hướng, và một đường hầm thêm giao diện thứ hai cho gần như tất cả chúng. Sắp xếp lưu lượng theo hướng và giao diện trước khiến phần còn lại trở nên máy móc, vì mỗi hàng bên dưới cần quy tắc riêng ở đúng chỗ của nó. Các ví dụ dùng tun0 và một nhóm 10.8.0.0/24, nên hãy thay tên và dải bằng những gì có trong đầu ra của chính máy khách.

Hai hàng thường bị nhầm vì cả hai đều nhắc tới đường hầm. Quy tắc cho trình phân giải cho phép lưu lượng máy khách gửi vào đường hầm, trong khi quy tắc cho SSH cho phép lưu lượng máy chủ nhận từ đó; chúng sống trên các máy khác nhau và thất bại độc lập. Hàng bị quên nhiều nhất là hàng thứ hai, vì máy khách không thể dựng đường hầm chút nào cho tới khi lưu lượng của nó tới địa chỉ công cộng của máy chủ được cho phép. Làm việc từ trên xuống dưới và mỗi thất bại có một nguyên nhân khả dĩ.

Trình phân giải được đẩy cần quy tắc riêng

Đường hầm có mang DNS hay không phụ thuộc vào những gì máy chủ gửi. Máy chủ đẩy một tùy chọn trình phân giải sẽ cài một địa chỉ riêng vào cấu hình của máy khách, và địa chỉ đó chỉ định tuyến được qua đường hầm. Nếu máy chủ không đẩy gì, máy khách giữ trình phân giải sẵn có và các quy tắc bên dưới không có gì để cho phép. Kiểm tra trạng thái được đẩy và kết quả truy vấn hiện tại trước khi viết bất cứ điều gì:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Đầu ra trạng thái nêu trình phân giải đang dùng và liên kết mà nó gắn vào, và việc tra tuyến phía sau cho thấy giao diện nào sẽ mang truy vấn tới địa chỉ đó. Khi trình phân giải nằm trên một liên kết khác, vấn đề nằm trước tường lửa và không quy tắc nào giúp được. Khi cả hai đồng ý về đường hầm, cần hai quy tắc, vì UDP mang phần lớn truy vấn và TCP tiếp quản khi câu trả lời bị cắt. Ghi lại cả hai giá trị, vì đó là những gì các quy tắc sẽ nêu tên:

sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'

Mở đường bên ngoài trước đường bên trong

Máy khách phải tới được địa chỉ công cộng của máy chủ trước khi có đường hầm, nên quy tắc cho việc đó nằm trên liên kết vật lý và phải có mặt trước tiên. Một chính sách cho phép trình phân giải nhưng quên máy chủ để máy khách hoàn toàn không thể dựng đường hầm, và triệu chứng đó thường bị đổ cho kill switch. Sau đó cho phép các dịch vụ bạn thực sự muốn qua đường hầm, mỗi lần một quy tắc hẹp, thay vì mở toàn bộ giao diện. Các quy tắc hẹp là lý do lệnh từ chối có thể ở nguyên tại chỗ.

sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'

Thứ tự quan trọng khi kiểm thử, vì quy tắc đầu tiên là thứ cho phép đường hầm đi lên. Thêm nó, kết nối và xác nhận đường hầm đã lên trước khi thêm quy tắc dịch vụ, vì làm cả hai cùng lúc nghĩa là một thất bại không cho bạn biết nửa nào sai. Thay địa chỉ tài liệu ở trên bằng điểm cuối mà máy khách được cấu hình để dùng.

Kết thúc phía máy khách bằng cách chủ động ngắt kết nối. Lệnh từ chối vẫn phải từ chối lưu lượng bạn cố ý loại trừ, vì một trình phân giải trả lời khi đường hầm đi lên chỉ bao phủ một nửa của chính sách từ chối khi nghi ngờ.

Máy khách kết nối chưa được chấp nhận

Máy chủ có hướng riêng để cân nhắc, và máy khách hoàn tất bắt tay vẫn không tới được bất cứ thứ gì chạy trên máy chủ cho tới khi máy chủ chấp nhận nó. Quy tắc của trình lắng nghe công cộng chỉ cho phép đường hầm tồn tại; nó không cho lưu lượng của đường hầm vào. Trên máy chủ đó là hai quy tắc cộng một lần kiểm tra rằng dịch vụ thực sự đang lắng nghe:

sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'

Nhóm trong quy tắc phải bằng dải mà máy chủ cấp, và số đường hầm phải khớp với số máy chủ đã tạo, vì một quy tắc cho giao diện khác không thể phân biệt với không có quy tắc. limit là cố ý cho một cổng quản trị, vì nó giới hạn các kết nối lặp lại thay vì chấp nhận chúng không giới hạn. Việc kiểm tra trình lắng nghe tách một cổng đóng khỏi một gói bị bỏ, hai thứ trông giống nhau từ phía máy khách. Các quy tắc đánh số cũng không phải toàn bộ bức tranh: các quy tắc before của UFW và mọi dòng nftables viết tay khớp sớm hơn và vẫn có thể từ chối một gói mà danh sách có vẻ cho phép.