Linux conntrack이 더 이상 친구가 아닌 경우

연결 추적(“conntrack”)은 Linux 커널 네트워킹 스택의 핵심 기능입니다. 이를 통해 커널은 모든 논리적 네트워크 연결 또는 흐름을 추적하고 각 흐름을 구성하는 모든 패킷을 식별하여 순차적으로 함께 처리할 수 있습니다.

Conntrack은 몇 가지 기본적인 경우에 사용되는 중요한 커널 기능입니다.

• NAT는 conntrack의 정보에 의존하므로 동일한 스트림의 모든 패킷을 동일하게 처리할 수 있습니다. 예를 들어 포드가 Kubernetes 서비스에 액세스하면 kube-proxy 로드 밸런서는 NAT를 사용하여 클러스터 내의 특정 포드로 트래픽을 전달합니다. Conntrack은 특정 연결에 대해 IP 서비스에 대한 모든 패킷이 동일한 포드로 전송되어야 하며 백엔드 포드에서 반환된 패킷은 요청이 발생한 포드로 다시 NAT 처리되어야 한다고 기록합니다.
• Calico와 같은 상태 저장 방화벽은 connecttrack의 정보를 사용하여 "응답" 트래픽을 화이트리스트에 추가합니다. 이를 통해 명시적으로 응답 트래픽을 허용하는 정책을 작성하지 않고도 "내 포드가 모든 원격 IP 주소에 연결하도록 허용"하는 네트워크 정책을 작성할 수 있습니다. (이것이 없으면 훨씬 덜 안전한 "모든 IP에서 내 포드로의 패킷 허용" 규칙을 추가해야 합니다.)

또한 conntrack은 일반적으로 스트림의 첫 번째 패킷만 전송하므로 시스템 성능을 향상시킵니다(CPU 소비 및 패킷 대기 시간 감소).
전체 네트워크 스택을 살펴보고 어떻게 해야 할지 결정해야 합니다. 게시물을 참조하십시오 "kube-proxy 모드 비교" 작동 방식의 예를 확인하세요.

그러나 conntrack에는 한계가 있습니다.

그렇다면 모든 것이 어디서 잘못 되었습니까?

conntrack 테이블에는 구성 가능한 최대 크기가 있으며, 테이블이 가득 차면 일반적으로 연결이 거부되거나 삭제되기 시작합니다. 테이블에는 대부분의 애플리케이션의 트래픽을 처리할 수 있는 충분한 여유 공간이 있으며 이는 결코 문제가 되지 않습니다. 그러나 conntrack 테이블 사용을 고려할 수 있는 몇 가지 시나리오가 있습니다.

• 가장 확실한 경우는 서버가 매우 많은 수의 동시 활성 연결을 처리하는 경우입니다. 예를 들어, conntrack 테이블이 128개 항목으로 구성되어 있지만 동시 연결이 128개를 초과한다면 분명히 문제가 발생할 것입니다!
• 약간 덜 분명한 경우: 서버가 초당 매우 많은 수의 연결을 처리하는 경우입니다. 연결이 일시적이더라도 일정 기간(기본적으로 120초) 동안 Linux에서 계속 모니터링됩니다. 예를 들어, conntrack 테이블이 128개 항목으로 구성되어 있고 초당 1100개의 연결을 처리하려고 하면 연결이 매우 짧은 경우에도(128k/120s = 1092개 연결/) conntrack 테이블의 크기를 초과하게 됩니다. 에스).

이러한 카테고리에 속하는 몇 가지 틈새 유형의 앱이 있습니다. 또한 악의적인 행위자가 많은 경우 서버의 conntrack 테이블을 반쯤 열린 연결로 채우는 것은 서비스 거부(DOS) 공격의 일부로 사용될 수 있습니다. 두 경우 모두 conntrack은 시스템의 제한적인 병목 현상이 될 수 있습니다. 어떤 경우에는 크기를 늘리거나 conntrack 시간 초과를 줄임으로써 conntrack 테이블 매개 변수를 조정하는 것만으로도 요구 사항을 충족하기에 충분할 수 있습니다(그러나 잘못하면 많은 문제가 발생할 수 있습니다). 다른 경우에는 공격적인 트래픽에 대해 conntrack을 우회해야 합니다.

실제 예

구체적인 예를 들어보겠습니다. 우리가 협력한 한 대형 SaaS 제공업체는 호스트(가상 머신 아님)에 다수의 memcached 서버를 보유하고 있었으며 각 서버는 초당 50개 이상의 단기 연결을 처리했습니다.

그들은 conntrack 구성을 실험하여 테이블 크기를 늘리고 추적 시간을 줄였지만 구성이 신뢰할 수 없었고 RAM 소비가 크게 증가하여 문제가 되었으며(GBytes 정도!) 연결이 너무 짧아서 conntrack이 작동하지 않았습니다. 일반적인 성능 이점(CPU 소비 또는 패킷 대기 시간 감소)을 만듭니다.

그들은 대안으로 Calico를 선택했습니다. Calico 네트워크 정책을 사용하면 특정 유형의 트래픽에 대해 conntrack을 사용하지 않을 수 있습니다(doNotTrack 정책 옵션 사용). 이를 통해 필요한 성능 수준과 Calico가 제공하는 추가 보안 수준이 제공되었습니다.

conntrack을 우회하려면 어느 정도까지 가야 합니까?

• 추적 금지 네트워크 정책은 일반적으로 대칭적이어야 합니다. SaaS 제공업체의 경우 애플리케이션이 보호 영역 내에서 실행되었으므로 네트워크 정책을 사용하여 memcached에 대한 액세스가 허용된 다른 특정 애플리케이션의 트래픽을 화이트리스트에 추가할 수 있었습니다.
• 추적 금지 정책은 연결 방향을 고려하지 않습니다. 따라서 memcached 서버가 해킹된 경우 이론적으로 올바른 소스 포트를 사용하는 한 모든 memcached 클라이언트에 연결을 시도할 수 있습니다. 그러나 memcached 클라이언트에 대한 네트워크 정책을 올바르게 정의한 경우 이러한 연결 시도는 클라이언트 측에서 계속 거부됩니다.
• 추적 금지 정책은 흐름의 첫 번째 패킷에만 적용되는 일반 정책과 달리 모든 패킷에 적용됩니다. 정책이 각 패킷에 적용되어야 하므로 패킷당 CPU 사용량이 증가할 수 있습니다. 그러나 수명이 짧은 연결의 경우 이 비용은 conntrack 처리를 위한 리소스 소비 감소로 균형을 이룹니다. 예를 들어 SaaS 공급자의 경우 연결당 패킷 수가 매우 적기 때문에 각 패킷에 정책을 적용할 때 추가 CPU 소비가 정당화되었습니다.

테스트를 시작해보자

초당 매우 많은 수의 연결을 실행할 수 있도록 Memcached 서버와 원격 노드에서 실행되는 여러 Memcached 클라이언트 포드가 있는 단일 포드에서 테스트를 실행했습니다. memcached 서버 포드가 있는 서버에는 conntrack 테이블(호스트에 대해 구성된 표준 테이블 크기)에 8개의 코어와 512k 항목이 있습니다.
우리는 다음 사이의 성능 차이를 측정했습니다. 네트워크 정책 없음; 일반 Calico 정책을 사용합니다. Calico 추적 금지 정책.

첫 번째 테스트에서는 연결 수를 초당 4.000개로 설정하여 CPU 소비의 차이에 집중할 수 있었습니다. 정책 없음과 일반 정책 사이에는 큰 차이가 없었지만 추적하지 않음으로 인해 CPU 소비가 약 20% 증가했습니다.

두 번째 테스트에서는 클라이언트가 생성할 수 있는 만큼 많은 연결을 시작하고 memcached 서버가 처리할 수 있는 초당 최대 연결 수를 측정했습니다. 예상한 대로 "정책 없음" 및 "일반 정책" 사례 모두 초당 4,000개 이상의 연결 제한(512k/120s = 4,369개 연결/초)에 도달했습니다. 추적 금지 정책을 통해 클라이언트는 아무런 문제 없이 초당 60,000개의 연결을 전송했습니다. 더 많은 클라이언트를 추가하여 이 숫자를 늘릴 수 있다고 확신하지만 이 숫자는 이미 이 기사의 요점을 설명하기에 충분하다고 생각합니다!

결론

Conntrack은 중요한 커널 기능입니다. 그는 자신의 일을 완벽하게 수행합니다. 주요 시스템 구성 요소에서 자주 사용됩니다. 그러나 일부 특정 시나리오에서는 conntrack으로 인한 정체가 이것이 제공하는 일반적인 이점보다 더 큽니다. 이 시나리오에서는 Calico 네트워크 정책을 사용하여 네트워크 보안을 강화하면서 conntrack 사용을 선택적으로 비활성화할 수 있습니다. 다른 모든 트래픽에 대해서는 conntrack이 계속해서 여러분의 친구가 되어 드립니다!

블로그에서 다른 기사도 읽어보세요.

• Nginx용 동적 모듈 빌드
• Hashicorp Consul의 Kubernetes 인증 소개
• Kubernetes의 상태 저장 백업
• 다수의 이기종 웹 프로젝트 백업
• Redmine용 텔레그램 봇. 자신과 다른 사람의 삶을 단순화하는 방법

출처 : habr.com