Giới hạn một cổng OpenVPN vào một LAN bằng các quy tắc UFW

Hãy quyết định quyền trước khi mở một tệp tường lửa: máy khách đã xác thực được mở kết nối tới một mạng con cụ thể, và cổng phải từ chối mọi đường trung chuyển khác kể cả khi máy khách cài thêm tuyến. Câu đó chính là thiết kế, và mỗi quy tắc bên dưới tồn tại để thực thi nó. Bất cứ điều gì rộng hơn, như toàn bộ không gian địa chỉ riêng, lối ra internet qua đường hầm hay lưu lượng ngang hàng, là một thiết kế khác cần quyết định riêng. Các quy tắc cũng cố ý nhàm chán, bởi một tường lửa khôn khéo là thứ mà sau này không ai kiểm toán được.

Trước hết hãy ghi lại sơ đồ mạng và quyền

Ví dụ dùng một máy chủ Community OpenVPN với thiết bị TUN trong không gian người dùng tên là tun0, một nhóm máy khách 10.77.0.0/24, và một mạng con được gắn 192.168.60.0/24 trên lan0. Việc chuyển tiếp IPv4 đã hoạt động và LAN đã có tuyến quay về nhóm, nên không gì ở đây phụ thuộc vào việc dịch giữa hai bên.

Tường lửa trên máy chủ này thuộc về UFW, và không bộ quy tắc trong container hay bảng nftables riêng nào được phép đặt một đường chấp nhận sớm hơn. Một lối tắt giảm tải luồng bỏ qua bộ lọc sẽ biến các chuỗi canh gác thành đồ trang trí, nên hãy xác nhận không có cái nào đang bật. Hãy để việc chuyển tiếp client-to-client của chính OpenVPN ở trạng thái tắt, vì lưu lượng ngang hàng không bao giờ đi qua bộ lọc của hệ điều hành không thể bị giới hạn bằng nó. Bộ lắng nghe bên ngoài và các quy tắc quản trị giữ nguyên, vì thay đổi này điều hành lưu lượng đường hầm đã giải mã thay vì thay thế tường lửa.

Đặt các canh gác trước những lần chấp nhận sớm của UFW

Một quyền cho tuyến rồi sau đó từ chối là không đủ cho một ranh giới chặt. Các quy tắc before mặc định chấp nhận lưu lượng đã thiết lập và một số ICMP trước khi bất kỳ quy tắc người dùng nào được xem xét, nên một luồng được cho phép tuần trước có thể nằm ngoài giới hạn đích mới chỉ vì nó còn trạng thái. Hãy sao lưu các tệp UFW và giữ một bảng điều khiển ngoài băng mở trước khi sửa.

Trong mục *filter của tệp /etc/ufw/before.rules, hãy khai báo hai chuỗi bên cạnh các khai báo hiện có và trước mọi dòng quy tắc.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Ngay sau các khai báo, và trước các quyền cho đầu vào và chuyển tiếp, hãy nhảy vào chúng và định nghĩa chúng cho qua những gì.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Giữ phần còn lại của mục và dòng COMMIT của nó. Dán một bảng lọc thứ hai hoặc xóa những quy tắc không liên quan là cách một thay đổi tường lửa trở thành sự cố ngừng dịch vụ, và tệp chỉ còn một lần khởi động nữa là bản sao duy nhất có ý nghĩa.

Đọc xem mỗi canh gác cho qua và từ chối những gì

Chuỗi đầu tiên chỉ tiếp tục xử lý khi nguồn nằm trong nhóm, đích là mạng con duy nhất đó, giao diện ra là LAN và gói tin đi theo hướng ban đầu của luồng. Mọi thứ khác đến từ đường hầm đều bị bỏ, kể cả nguồn ngoài nhóm và mọi đích vượt quá mạng con được phép.

Một gói tin ngang hàng đi vào và đi ra tun0, nên nó trượt phép thử giao diện LAN trước cả khi tới bước kiểm tra đích. Các kết nối mới từ LAN tới máy khách cũng trượt phép thử hướng trả lời, điều này đóng đường gọi lại ngược theo mặc định.

Đích RETURN giữ chính sách UFW thông thường vẫn có hiệu lực. Các chuỗi này lọc, và quyền cho tuyến bạn thêm sau đó vẫn quyết định gói tin sống sót có được chấp nhận hay không. Chính sự tách bạch đó cho phép bạn đổi mạng con được phép ở một chỗ về sau. Nếu các canh gác chấp nhận gói tin ngay, mọi quy tắc tương lai sẽ phải thêm hai lần.

Cho phép mạng con và đóng các cửa bên

Hãy xem trước quyền cho tuyến, rồi bỏ cờ xem trước để áp dụng: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Sau đó hãy xem lại thứ tự các quy tắc người dùng, vì một lần từ chối trước đó vẫn thắng một lần cho phép sau. Một quyền cho toàn bộ mạng con cũng là hình dạng sai khi chỉ cổng HTTPS của một máy chủ nên được tiếp cận.

Hãy để ý việc bỏ đầu vào làm gì: máy khách đường hầm không thể chạm tới bất kỳ dịch vụ nào trên chính cổng, kể cả một bộ lắng nghe DNS gắn với địa chỉ LAN của nó. Lưu trữ DNS ở đó cần một ngoại lệ có chủ đích trước khi bỏ và một hợp đồng quyền đã sửa lại. Nếu UFW quản lý IPv6, hãy thêm các lần bỏ tương ứng cho tun0 trong before6.rules nữa, vì danh sách đích IPv4 không nói gì về gói tin IPv6.

Hãy xác minh chính sách đã nạp, không phải bản xem trước

Xem trước lần nạp lại, áp dụng nó trong một cửa sổ bảo trì, và đọc bộ quy tắc đang sống.

sudo ufw --dry-run reload
sudo ufw show raw

Xác nhận rằng các canh gác đường hầm xuất hiện trước các quyền mặc định về trạng thái và ICMP. Lệnh ufw status đơn thuần không hiển thị các quy tắc before sửa tay, đó là lý do người vận hành kết luận thiếu một quy tắc trong khi nó thực ra đã được nạp. Hãy đọc danh sách thô từ trên xuống thay vì tìm một mẩu. Nếu các canh gác xuất hiện sau một quyền trạng thái, ranh giới không làm đúng như tệp gợi ý.

Sau đó hãy thử hành vi chứ không phải văn bản. Mở một kết nối mới tới máy chủ được phép và xem phản hồi, gửi một yêu cầu vô hại tới một đích ngoài mạng con và xác nhận nó chết, thử một kết nối ngang hàng, thử một dịch vụ cục bộ trên cổng, và thử một kết nối không được yêu cầu từ LAN tới máy khách. Hãy đưa vào một luồng ngoài phạm vi đã tồn tại trước thay đổi, và chỉ xóa luồng đó thay vì xả toàn bộ bảng theo dõi của máy.

Hãy ghi các giới hạn bên cạnh các quy tắc: điều này giới hạn việc trung chuyển và không gì khác. Nó không ngăn máy khách dùng kết nối internet riêng, không ngăn một máy chủ LAN được phép chuyển tiếp lưu lượng đi xa hơn, và không thay thế việc xác thực bên trong các dịch vụ được phép.