Theo dõi kết nối (“conntrack”) là một tính năng cốt lõi của ngăn xếp mạng nhân Linux. Nó cho phép kernel theo dõi tất cả các kết nối hoặc luồng mạng logic và từ đó xác định tất cả các gói tạo nên mỗi luồng để chúng có thể được xử lý tuần tự cùng nhau.
Conntrack là một tính năng quan trọng của kernel được sử dụng trong một số trường hợp cơ bản:
- NAT dựa vào thông tin từ conntrack để có thể xử lý tất cả các gói từ cùng một luồng một cách bình đẳng. Ví dụ: khi một nhóm truy cập dịch vụ Kubernetes, bộ cân bằng tải kube-proxy sử dụng NAT để hướng lưu lượng truy cập đến một nhóm cụ thể trong cụm. Conntrack ghi lại rằng đối với một kết nối nhất định, tất cả các gói đến dịch vụ IP phải được gửi đến cùng một nhóm và các gói được trả về bởi nhóm phụ trợ phải được NAT trở lại nhóm mà yêu cầu được gửi đến.
- Tường lửa có trạng thái như Calico dựa vào thông tin từ lưu lượng truy cập "phản hồi" kết nối đến danh sách trắng. Điều này cho phép bạn viết chính sách mạng có nội dung "cho phép nhóm của tôi kết nối với bất kỳ địa chỉ IP từ xa nào" mà không cần phải viết chính sách để cho phép lưu lượng phản hồi một cách rõ ràng. (Nếu không có điều này, bạn sẽ phải thêm quy tắc "cho phép các gói vào nhóm của tôi từ bất kỳ IP" kém an toàn hơn nhiều.)
Ngoài ra, conntrack thường cải thiện hiệu suất hệ thống (bằng cách giảm mức tiêu thụ CPU và độ trễ gói) vì chỉ gói đầu tiên trong luồng
phải đi qua toàn bộ ngăn xếp mạng để xác định phải làm gì với nó. Xem bài viết"" để xem ví dụ về cách thức hoạt động của tính năng này.
Tuy nhiên, conntrack có những hạn chế...
Thế nó sai ở chỗ nào?
Bảng conntrack có kích thước tối đa có thể định cấu hình và nếu nó đầy, các kết nối thường bắt đầu bị từ chối hoặc bị hủy. Có đủ không gian trống trong bảng để xử lý lưu lượng của hầu hết các ứng dụng và điều này sẽ không bao giờ trở thành vấn đề. Tuy nhiên, có một số trường hợp mà bạn có thể cân nhắc sử dụng bảng conntrack:
- Trường hợp rõ ràng nhất là nếu máy chủ của bạn xử lý một số lượng cực lớn các kết nối hoạt động đồng thời. Ví dụ: nếu bảng conntrack của bạn được định cấu hình cho 128k mục nhập, nhưng bạn có >128k kết nối đồng thời, bạn chắc chắn sẽ gặp sự cố!
- Một trường hợp ít rõ ràng hơn: nếu máy chủ của bạn xử lý số lượng kết nối rất lớn mỗi giây. Ngay cả khi các kết nối chỉ tồn tại trong thời gian ngắn, chúng vẫn tiếp tục được Linux giám sát trong một khoảng thời gian (theo mặc định là 120 giây). Ví dụ: nếu bảng conntrack của bạn được định cấu hình cho 128k mục nhập và bạn đang cố xử lý 1100 kết nối mỗi giây, chúng sẽ vượt quá kích thước của bảng conntrack, ngay cả khi các kết nối có thời gian tồn tại rất ngắn (128k/120s = 1092 kết nối/ S).
Có một số loại ứng dụng thích hợp thuộc các danh mục này. Ngoài ra, nếu bạn có nhiều kẻ xấu, việc lấp đầy bảng conntrack của máy chủ với nhiều kết nối nửa mở có thể được sử dụng như một phần của cuộc tấn công từ chối dịch vụ (DOS). Trong cả hai trường hợp, conntrack có thể trở thành nút cổ chai hạn chế trong hệ thống của bạn. Trong một số trường hợp, việc điều chỉnh các tham số của bảng conntrack có thể đủ để đáp ứng nhu cầu của bạn - bằng cách tăng kích thước hoặc giảm thời gian chờ của conntrack (nhưng nếu làm sai, bạn sẽ gặp rất nhiều rắc rối). Đối với các trường hợp khác, cần phải bỏ qua conntrack đối với lưu lượng truy cập lớn.
Ví dụ thực tế
Hãy đưa ra một ví dụ cụ thể: một nhà cung cấp SaaS lớn mà chúng tôi hợp tác có một số máy chủ được ghi nhớ trên máy chủ (không phải máy ảo), mỗi máy chủ xử lý hơn 50 nghìn kết nối ngắn hạn mỗi giây.
Họ đã thử nghiệm cấu hình conntrack, tăng kích thước bảng và giảm thời gian theo dõi, nhưng cấu hình không đáng tin cậy, mức tiêu thụ RAM tăng đáng kể, đó là một vấn đề (theo thứ tự GByte!), và các kết nối quá ngắn nên conntrack không hoạt động được. tạo ra lợi ích hiệu suất thông thường của nó (giảm mức tiêu thụ CPU hoặc độ trễ gói).
Họ chuyển sang Calico như một sự thay thế. Chính sách mạng Calico cho phép bạn không sử dụng conntrack cho một số loại lưu lượng truy cập nhất định (sử dụng tùy chọn chính sách doNotTrack). Điều này mang lại cho họ mức hiệu suất họ cần, cộng thêm mức độ bảo mật bổ sung do Calico cung cấp.
Bạn sẽ phải đi bao lâu để vượt qua conntrack?
- Các chính sách mạng không theo dõi nhìn chung phải có tính đối xứng. Trong trường hợp nhà cung cấp SaaS: ứng dụng của họ chạy bên trong vùng được bảo vệ và do đó, bằng cách sử dụng chính sách mạng, họ có thể đưa lưu lượng truy cập từ các ứng dụng cụ thể khác được phép truy cập vào memcached vào danh sách trắng.
- Chính sách không theo dõi không tính đến hướng kết nối. Do đó, nếu máy chủ memcached bị hack, về mặt lý thuyết bạn có thể thử kết nối với bất kỳ máy khách memcached nào, miễn là nó sử dụng đúng cổng nguồn. Tuy nhiên, nếu bạn đã xác định chính xác chính sách mạng cho các máy khách được memcached của mình thì những nỗ lực kết nối này sẽ vẫn bị từ chối ở phía máy khách.
- Chính sách không theo dõi được áp dụng cho mọi gói, trái ngược với các chính sách thông thường chỉ được áp dụng cho gói đầu tiên trong luồng. Điều này có thể làm tăng mức tiêu thụ CPU trên mỗi gói vì chính sách phải được áp dụng cho từng gói. Nhưng đối với các kết nối có thời gian tồn tại ngắn, chi phí này được cân bằng bằng việc giảm mức tiêu thụ tài nguyên để xử lý conntrack. Ví dụ: trong trường hợp nhà cung cấp SaaS, số lượng gói cho mỗi kết nối là rất nhỏ, do đó mức tiêu thụ CPU bổ sung khi áp dụng chính sách cho mỗi gói là hợp lý.
Hãy bắt đầu thử nghiệm
Chúng tôi đã chạy thử nghiệm trên một nhóm duy nhất có máy chủ memcached và nhiều nhóm máy khách memcached chạy trên các nút từ xa để chúng tôi có thể chạy số lượng kết nối rất lớn mỗi giây. Máy chủ có nhóm máy chủ memcached có 8 lõi và 512k mục trong bảng conntrack (kích thước bảng được định cấu hình tiêu chuẩn cho máy chủ).
Chúng tôi đã đo lường sự khác biệt về hiệu suất giữa: không có chính sách mạng; với chính sách Calico thông thường; và chính sách không theo dõi của Calico.
Đối với thử nghiệm đầu tiên, chúng tôi đặt số lượng kết nối thành 4.000 mỗi giây để có thể tập trung vào sự khác biệt về mức tiêu thụ CPU. Không có sự khác biệt đáng kể giữa không có chính sách và chính sách thông thường, nhưng mức tiêu thụ CPU tăng lên khoảng 20%:
Trong thử nghiệm thứ hai, chúng tôi đã khởi chạy số lượng kết nối mà khách hàng có thể tạo ra và đo lường số lượng kết nối tối đa mỗi giây mà máy chủ memcached của chúng tôi có thể xử lý. Đúng như dự đoán, cả trường hợp “không có chính sách” và “chính sách thông thường” đều đạt giới hạn kết nối trên 4,000 kết nối mỗi giây (512k / 120s = 4,369 kết nối/s). Với chính sách không theo dõi, khách hàng của chúng tôi đã gửi 60,000 kết nối mỗi giây mà không gặp bất kỳ sự cố nào. Chúng tôi chắc chắn rằng chúng tôi có thể tăng con số này bằng cách thêm nhiều khách hàng hơn, nhưng chúng tôi cảm thấy những con số này đã đủ để minh họa quan điểm của bài viết này!
Kết luận
Conntrack là một tính năng quan trọng của kernel. Anh ấy làm công việc của mình một cách hoàn hảo. Nó thường được sử dụng bởi các thành phần hệ thống quan trọng. Tuy nhiên, trong một số trường hợp cụ thể, sự tắc nghẽn do conntrack gây ra còn lớn hơn những lợi ích thông thường mà nó mang lại. Trong trường hợp này, các chính sách mạng của Calico có thể được sử dụng để vô hiệu hóa có chọn lọc việc sử dụng conntrack đồng thời tăng cường bảo mật mạng. Đối với tất cả lưu lượng truy cập khác, conntrack tiếp tục là bạn của bạn!
Cũng đọc các bài viết khác trên blog của chúng tôi:
Nguồn: www.habr.com