ufw allow 443 không giúp gì cho dịch vụ phía sau VPN

Ping thành công từ một máy khách VPN, dịch vụ TCP hết thời gian chờ, và ufw allow 443/tcp không thay đổi gì cả. Khi ứng dụng chạy trên một máy chủ phía sau cổng chứ không phải trên chính cổng, quyền đó đã được viết cho sai đường đi của lưu lượng. Gói tin không được đánh địa chỉ tới tường lửa và không được giao cho tiến trình cục bộ nào, nên các quy tắc đầu vào không bao giờ thấy nó. Cách sửa là một quy tắc tuyến nhắm vào luồng được chuyển tiếp, và bằng chứng đã có sẵn trong nhật ký.

Xác định đích là cục bộ hay được chuyển tiếp

Đọc gói tin theo cách nhân hệ điều hành nhìn thấy nó. Lưu lượng được giao cho một dịch vụ trên cổng là đầu vào cục bộ. Lưu lượng mà cổng định tuyến tiếp tới máy chủ khác là được chuyển tiếp, và UFW giữ các bộ quy tắc riêng cho hai đường đi. Sự khác biệt do địa chỉ đích và việc tra cứu tuyến quyết định, không phải giao diện mà gói tin đến.

Một dòng nhật ký hiển thị cùng một giao diện ở cả hai trường IN và OUT vẫn có thể mô tả một gói tin đã được định tuyến, vì một đường hầm đưa máy khách vào và ra khỏi cùng một thiết bị trông đúng như vậy. Địa chỉ đích giải quyết câu hỏi đó nhanh hơn tên giao diện. Thấy cùng một tên hai lần không chứng minh việc giao cục bộ, và việc bịa ra một giao diện đường hầm mà bản triển khai chưa từng tạo cũng không giúp gì.

Đọc khối trước khi thêm bất kỳ quy tắc nào

Tái hiện một lần thử kết nối đã được cấp phép và ghi lại nguồn, đích, giao thức và cổng đích đúng như cổng đã ghi. So sánh bốn giá trị đó với mục trong nhật ký và với vị trí thực tế của dịch vụ. Một lần ping thành công trước đó chỉ chứng minh rằng chính cuộc trao đổi của nó được phép, và tường lửa có thể xử lý một TCP SYN tới ứng dụng theo cách hoàn toàn khác.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

Lệnh đầu tiên trả về phán quyết cùng các trường của nó, và lệnh thứ hai cho thấy những gì đã được nạp và theo thứ tự nào. Đọc cả hai trước khi sửa bất cứ điều gì, vì một lần từ chối trước đó nằm trên quy tắc của bạn cũng giải thích cùng triệu chứng mà không cần quy tắc nào bị thiếu.

Viết quy tắc tuyến hẹp nhất phù hợp

Trong ví dụ này máy khách đến trên tun0 từ 172.20.8.0/24, dịch vụ lắng nghe trên 10.30.0.15 tại cổng 8443, và cổng đi ra qua ens5. Những giá trị đó được chọn để trông không giống chút nào giá trị mặc định của VPC trên đám mây là 10.0.0.0/16 hay mạng gia đình 192.168.0.0/16, và 8443 giữ ví dụ tránh xa trình lắng nghe 443 của chính cổng.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

Lần chạy thử in ra bộ quy tắc sẽ hình thành, và đó là cách rẻ nhất để thấy quy tắc của bạn rơi trước hay sau một lần từ chối đang có. Đối chiếu tên giao diện và địa chỉ bên trong với bản triển khai chứ không phải với ví dụ, và nhớ rằng khi NAT đích chạy trước, bộ lọc nhìn thấy đích đã được dịch.

Giữ đường về có trạng thái

UFW theo dõi các kết nối được phép, nên các phản hồi cho một luồng được chuyển tiếp và được phép vẫn được chấp nhận mà không cần quy tắc ngược rõ ràng. Thêm một quy tắc không giới hạn theo chiều ngược lại để mọi thứ hoạt động sẽ mở rộng chính sách vượt xa một dịch vụ duy nhất và không cần thiết cho một cuộc trao đổi yêu cầu và phản hồi thông thường. Giữ đường về là ngầm định và bộ quy tắc dễ đọc.

Chỉ áp dụng quy tắc sau khi lần chạy thử khớp với ý định của bạn, rồi xác nhận rằng danh sách có thứ tự hiển thị nó ở vị trí mong đợi. Giữ trình lắng nghe VPN và các quy tắc quản trị như những vấn đề riêng, vì thay đổi chúng là một quyết định khác với việc cho một ứng dụng đi qua. Ghi lại thay đổi ở nơi sơ đồ mạng được viết, để kỹ sư tiếp theo không phải phát hiện lại nó từ một bản bắt gói tin.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Kiểm tra những gì UFW không thể thực thi thay bạn

Một quy tắc đúng vẫn cần việc chuyển tiếp trong nhân và một tuyến đi tới dịch vụ. Xác nhận cả hai trước khi đổ lỗi cho tường lửa lần thứ hai.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Sau đó nhìn ra ngoài máy chủ. Trên một phiên bản đám mây, chính sách UFW của máy khách không thay thế các nhóm bảo mật, ACL mạng con hay cấu hình chuyển tiếp của chính nhà cung cấp, nên một chặn cục bộ là bằng chứng về một tầng chứ không phải bằng chứng rằng mọi tầng khác đều cho phép dịch vụ.

Kết thúc bằng việc thử một kết nối mới khi tường lửa đang bật, từ một nguồn được phép và từ một nguồn không liên quan. Tắt UFW loại bỏ triệu chứng và phá hủy bằng chứng trong cùng một lệnh, vì vậy đó nên là thí nghiệm cuối cùng chứ không phải đầu tiên.