Giới hạn quy tắc SNAT của OpenVPN trước khi nó làm hỏng nginx

Hai lỗi cứ liên tục đến từ cùng một loại máy chủ. Ở trường hợp thứ nhất, máy khách xác thực rồi không đến được gì ngoài đường hầm. Ở trường hợp thứ hai, VPN lên và chính trang web của máy chủ ngừng phản hồi, đây là trường hợp đáng lo hơn vì trông như thiệt hại kèm theo. Trên VPS dựa trên container, cả hai thường quy về cùng một danh sách kiểm tra ngắn, và thứ tự rất quan trọng: thiết bị trước, dịch địa chỉ sau, phạm vi cuối cùng.

Xác nhận rằng container có thể tạo thiết bị tun

Không gì khác quan trọng nếu giao diện đường hầm không thể tồn tại. Kiểm tra rằng /dev/net/tun có mặt và việc tạo thiết bị thử nghiệm thành công, vì nhiều nhà cung cấp tắt tun trong container theo mặc định. Không có công việc firewall nào bù đắp được một thiết bị chưa từng được tạo.

Nếu thiết bị không có, chỉ máy chủ hoặc nhà cung cấp mới có thể bật nó. Một gói khác thường rẻ hơn một chủ đề hỗ trợ mở kéo dài một tuần. Xác nhận điều này trước khi đọc dù chỉ một dòng nhật ký OpenVPN. Nếu không, bạn sẽ dành cả buổi tối để tinh chỉnh những quy tắc không bao giờ thấy gói tin nào.

Quyết định MASQUERADE làm gì trên giao diện này

Trên một máy ảo thông thường, quy tắc ra thông thường là POSTROUTING MASQUERADE từ giao diện chính. Trong container OpenVZ, thiết bị nhìn thấy thường là venet0, một giao diện ảo do máy chủ quản lý chứ không phải card mạng được định tuyến, và MASQUERADE không phải lúc nào cũng hành xử ở đó như các hướng dẫn giả định.

Dạng khả thi là dịch rõ ràng sang địa chỉ mà máy khách đã đến được, với việc cho phép chuyển tiếp theo cả hai chiều. Thay pool từ cấu hình máy chủ quan trọng không kém thay địa chỉ. Đọc từng dòng trước khi dán.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Không có các quy tắc chuyển tiếp, việc dịch vẫn diễn ra và nhân vẫn từ chối chuyển tiếp. Sự kết hợp đó tạo ra trạng thái khó hiểu trong đó bộ đếm trên quy tắc NAT tăng lên trong khi máy khách không nhận được gì. Hai dòng FORWARD cũng phải đứng trước bất kỳ quy tắc drop rộng nào trong cùng chuỗi. Thứ tự là một phần của cấu hình, không phải chi tiết triển khai.

Giới hạn quy tắc trong một pool và một giao diện

Triệu chứng thứ hai có nguyên nhân khác: một quy tắc POSTROUTING không có giới hạn nguồn và không có giới hạn đầu ra. Quy tắc như vậy viết lại mọi gói tin rời khỏi máy chủ.

Các dịch vụ phụ thuộc vào nguồn gốc ban đầu sau đó hành xử sai. Một máy chủ web sau proxy cục bộ có thể ngừng phản hồi, và khởi động lại không thay đổi gì vì quy tắc vẫn nằm trên đường đi. Lưu lượng máy chủ gửi đến địa chỉ công khai của chính nó cũng bị ảnh hưởng, đó là lý do sự cố có thể trông giống vấn đề DNS hoặc chứng chỉ hơn là firewall. Quy tắc gần như chắc chắn được thêm vào để sửa triệu chứng đầu tiên.

Giải pháp là thu hẹp sự khớp vào pool đường hầm và giao diện ra, rồi thêm một quy tắc cho mỗi pool thay vì mở rộng một quy tắc để bao nhiều pool.

Làm cho các quy tắc bền vững và tìm ra ai khác sở hữu chúng

Các quy tắc thêm bằng tay biến mất khi khởi động lại, nên hãy lưu chúng bằng iptables-save hoặc quản lý qua netfilter-persistent ở nơi nó được cài đặt. Xác nhận rằng việc khôi phục chạy trước khi OpenVPN khởi động. Sau đó khởi động lại một lần có chủ đích thay vì phát hiện lỗ hổng trong lúc sự cố.

Trên máy chủ container, cũng xác nhận rằng tệp duy trì nằm trong bộ nhớ container ghi được và nhà cung cấp không thay thế việc lọc khi khởi động. Một số nền tảng quản lý chính sách bên ngoài container, nơi các quy tắc cục bộ hoặc bị bỏ qua hoặc xung đột với quy tắc của chính máy chủ.

Xác minh bằng bộ đếm và một luồng đã bắt

Từ một máy khách đã kết nối, kiểm tra địa chỉ công khai mà một dịch vụ bên ngoài báo cáo. Nếu nó khớp với địa chỉ của máy chủ, việc dịch hoạt động; nếu không, gói tin đi ra theo đường khác hoặc không đi ra gì cả. Sau đó thử cả một dịch vụ lưu trữ trên máy chủ và một dịch vụ trên internet công cộng, vì chúng đi theo những đường khác nhau qua cùng một bộ quy tắc.

Trên máy chủ, đọc bộ đếm gói tin trên các quy tắc NAT và FORWARD bằng iptables -t nat -L -v -n và quan sát một luồng trong bản bắt gói. Nếu địa chỉ của máy khách xuất hiện trong bản bắt và không có phản hồi nào theo sau, lỗ hổng nằm trên đường về hoặc trong việc lọc của nhà cung cấp, không phải trong hồ sơ máy khách. So sánh nguồn đã bắt với địa chỉ mà quy tắc dịch sang, vì sự không khớp nghĩa là một quy tắc khác đã khớp trước. Một luồng quan sát được giải quyết nhiều hơn một trang đọc cấu hình.

Giữ pool, địa chỉ đã dịch và tên giao diện cùng nhau trong bản ghi thay đổi. Một quy tắc đúng cho một pool lại dịch sai pool tiếp theo.