작업 라운드를 가져오는 취약점에 주의하세요. 1부: FragmentSmack/SegmentSmack

안녕하세요 여러분! 제 이름은 Dmitry Samsonov이고 Odnoklassniki에서 수석 시스템 관리자로 일하고 있습니다. 우리는 7개가 넘는 물리적 서버, 클라우드에 11개의 컨테이너, 200개의 애플리케이션을 보유하고 있으며, 이는 다양한 구성으로 700개의 서로 다른 클러스터를 형성합니다. 대부분의 서버는 CentOS 7을 실행합니다.
14년 2018월 XNUMX일 FragmentSmack 취약점에 대한 정보가 게시되었습니다.
(CVE-2018-5391) 및 SegmentSmack(CVE-2018-5390). 이는 네트워크 공격 벡터와 상당히 높은 점수(7.5점)를 지닌 취약점으로, 리소스 고갈로 인한 서비스 거부(DoS)를 위협한다. FragmentSmack에 대한 커널 수정은 당시 제안되지 않았으며, 또한 취약점에 대한 정보가 게시된 것보다 훨씬 늦게 나왔습니다. SegmentSmack을 제거하려면 커널을 업데이트하는 것이 제안되었습니다. 업데이트 패키지 자체도 같은 날 출시됐고, 남은 건 설치뿐이었다.
아니요, 우리는 커널 업데이트를 전혀 반대하지 않습니다! 그러나 뉘앙스가 있습니다 ...

프로덕션에서 커널을 업데이트하는 방법

일반적으로 복잡한 것은 없습니다.

1. 패키지 다운로드;
2. 여러 서버(클라우드 호스팅 서버 포함)에 설치합니다.
3. 파손된 부분이 없는지 확인하세요.
4. 모든 표준 커널 설정이 오류 없이 적용되었는지 확인하십시오.
5. 며칠 기다리십시오.
6. 서버 성능을 확인하세요.
7. 새 서버 배포를 새 커널로 전환합니다.
8. 데이터 센터별로 모든 서버를 업데이트합니다(문제 발생 시 사용자에게 미치는 영향을 최소화하기 위해 한 번에 하나의 데이터 센터).
9. 모든 서버를 재부팅합니다.

우리가 가지고 있는 커널의 모든 분기에 대해 반복합니다. 현재는 다음과 같습니다.

• Stock CentOS 7 3.10 - 대부분의 일반 서버용;
• 바닐라 4.19 - 우리를 위한 것 단일 클라우드 구름, BFQ, BBR 등이 필요하기 때문입니다.
• Elrepo kernel-ml 5.2 - 고부하 유통업체, 4.19는 불안정하게 동작했지만 동일한 기능이 필요하기 때문입니다.

짐작하셨겠지만 수천 대의 서버를 재부팅하는 데 가장 오랜 시간이 걸립니다. 모든 서버에 모든 취약점이 중요한 것은 아니므로 인터넷에서 직접 액세스할 수 있는 취약점만 재부팅합니다. 클라우드에서는 유연성을 제한하지 않기 위해 외부에서 액세스 가능한 컨테이너를 새로운 커널로 개별 서버에 묶지 않고 모든 호스트를 예외 없이 재부팅합니다. 다행히도 일반 서버보다 절차가 더 간단합니다. 예를 들어 상태 비저장 컨테이너는 재부팅 중에 간단히 다른 서버로 이동할 수 있습니다.

하지만 아직 작업량이 많아 몇 주가 걸릴 수 있으며, 새 버전에 문제가 있는 경우 최대 몇 달이 걸릴 수도 있습니다. 공격자들은 이를 매우 잘 이해하고 있으므로 플랜 B가 필요합니다.

FragmentSmack/SegmentSmack. 해결 방법

다행스럽게도 일부 취약점의 경우 이러한 계획 B가 존재하며 이를 해결 방법이라고 합니다. 대부분의 경우 이는 가능한 영향을 최소화하거나 취약점 악용을 완전히 제거할 수 있는 커널/응용 프로그램 설정의 변경입니다.

FragmentSmack/SegmentSmack의 경우 제안되었다 이 해결 방법:

«net.ipv4.ipfrag_high_thresh 및 net.ipv3.ipfrag_low_thresh(및 ipv4 net.ipv4.ipfrag_high_thresh 및 net.ipv6.ipfrag_low_thresh에 대한 대응 항목)에서 6MB 및 6MB의 기본값을 각각 256kB 및 192kB로 변경할 수 있습니다. 낮추다. 테스트에서는 하드웨어, 설정 및 조건에 따라 공격 중에 CPU 사용량이 소폭 감소하는 것으로 나타났습니다. 그러나 한 번에 262144개의 64K 조각만 리어셈블리 대기열에 들어갈 수 있으므로 ipfrag_high_thresh=XNUMX바이트로 인해 성능에 약간의 영향이 있을 수 있습니다. 예를 들어 대규모 UDP 패킷을 사용하는 애플리케이션이 중단될 위험이 있습니다.".

매개변수 자체 커널 문서에서 다음과 같이 설명됩니다:

ipfrag_high_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments before the kernel
    begins to remove incomplete fragment queues to free up resources.
    The kernel still accepts new fragments for defragmentation.

프로덕션 서비스에는 대규모 UDP가 없습니다. LAN에는 조각화된 트래픽이 없고 WAN에는 조각화된 트래픽이 있지만 심각하지는 않습니다. 징후가 없습니다. 해결 방법을 출시할 수 있습니다!

FragmentSmack/SegmentSmack. 퍼스트 블러드

우리가 직면한 첫 번째 문제는 클라우드 컨테이너가 새로운 설정을 부분적으로만 적용하는 경우도 있었고(ipfrag_low_thresh만) 때로는 전혀 적용하지 않는 경우도 있었습니다. 처음에는 단순히 충돌이 발생했습니다. 문제를 안정적으로 재현할 수 없었습니다. (모든 설정은 어려움 없이 수동으로 적용했습니다.) 시작 시 컨테이너가 충돌하는 이유를 이해하는 것도 쉽지 않습니다. 오류가 발견되지 않았습니다. 한 가지 확실한 점은 설정을 롤백하면 컨테이너 충돌 문제가 해결된다는 것입니다.

호스트에 Sysctl을 적용하는 것만으로는 충분하지 않은 이유는 무엇입니까? 컨테이너는 자체 전용 네트워크 네임스페이스에 있으므로 최소한 네트워크 Sysctl 매개변수의 일부 컨테이너의 호스트와 다를 수 있습니다.

컨테이너에 Sysctl 설정이 정확히 어떻게 적용되나요? 우리 컨테이너에는 권한이 없으므로 컨테이너 자체에 들어가서 Sysctl 설정을 변경할 수 없습니다. 단순히 권한이 충분하지 않기 때문입니다. 컨테이너를 실행하기 위해 당시 우리 클라우드는 Docker를 사용했습니다(지금은 포드 맨). 필요한 Sysctl 설정을 포함하여 새 컨테이너의 매개변수가 API를 통해 Docker에 전달되었습니다.
버전을 검색하는 동안 Docker API가 모든 오류를 반환하지 않은 것으로 나타났습니다(적어도 버전 1.10에서는). "docker run"을 통해 컨테이너를 시작하려고 시도했을 때 마침내 최소한 다음과 같은 내용을 확인했습니다.

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

매개변수 값이 유효하지 않습니다. 그런데 왜? 그리고 가끔만 유효하지 않은 이유는 무엇입니까? Docker는 Sysctl 매개변수가 적용되는 순서를 보장하지 않는 것으로 밝혀졌습니다(최신 테스트 버전은 1.13.1). 따라서 ipfrag_low_thresh가 여전히 256M일 때 ipfrag_high_thresh를 3K로 설정하려고 시도하는 경우가 있었습니다. 즉, 상한이 더 낮았습니다. 하한값보다 높아 오류가 발생했습니다.

그 당시 우리는 이미 시작 후 컨테이너를 재구성하기 위한 자체 메커니즘을 사용했습니다. 그룹 냉동고 다음을 통해 컨테이너의 네임스페이스에서 명령을 실행합니다. IP 네트워크), 그리고 이 부분에 Sysctl 매개변수 작성도 추가했습니다. 문제가 해결되었습니다.

FragmentSmack/SegmentSmack. 퍼스트 블러드 2

클라우드에서 해결 방법의 사용을 이해하기 전에 사용자로부터 처음으로 드문 불만이 접수되기 시작했습니다. 당시 첫 번째 서버에서 Workaround를 사용한 지 몇 주가 지났습니다. 초기 조사에 따르면 불만사항은 해당 서비스의 모든 서버가 아닌 개별 서비스에 대해 접수된 것으로 나타났습니다. 문제는 다시 극도로 불확실해졌습니다.

우선, 물론 Sysctl 설정을 롤백하려고 시도했지만 아무런 효과가 없었습니다. 서버 및 애플리케이션 설정에 대한 다양한 조작도 도움이 되지 않았습니다. 재부팅이 도움이 되었습니다. Linux를 재부팅하는 것은 예전 Windows의 경우처럼 부자연스럽습니다. 그러나 이는 도움이 되었으며 Sysctl에 새 설정을 적용할 때 이를 "커널 결함"으로 분류했습니다. 얼마나 황당한 일이었는지...

504주 후에 문제가 다시 발생했습니다. 이러한 서버의 구성은 매우 간단했습니다. 프록시/밸런서 모드의 Nginx입니다. 교통량이 많지 않습니다. 새로운 소개 참고 사항: 클라이언트의 XNUMX 오류 수가 매일 증가하고 있습니다(게이트웨이 시간 초과). 그래프는 이 서비스의 일일 504개 오류 수를 보여줍니다.

모든 오류는 동일한 백엔드, 즉 클라우드에 있는 오류에 관한 것입니다. 이 백엔드의 패키지 조각에 대한 메모리 소비 그래프는 다음과 같습니다.

이는 운영 체제 그래프의 문제를 가장 명확하게 나타내는 것 중 하나입니다. 클라우드에서는 동시에 QoS(Traffic Control) 설정과 관련된 또 다른 네트워크 문제가 수정되었습니다. 패킷 조각의 메모리 소비 그래프에서는 정확히 동일해 보였습니다.

가정은 간단했습니다. 그래프에서 동일하게 보이면 이유도 동일합니다. 또한 이러한 유형의 메모리에 문제가 발생하는 경우는 극히 드뭅니다.

해결된 문제의 핵심은 QoS에서 기본 설정으로 fq 패킷 스케줄러를 사용했다는 것입니다. 기본적으로 하나의 연결에 대해 100개의 패킷을 대기열에 추가할 수 있으며, 채널 부족 상황에서 일부 연결로 인해 대기열이 용량으로 막히기 시작했습니다. 이 경우 패킷이 삭제됩니다. tc 통계(tc -s qdisc)에서 다음과 같이 볼 수 있습니다.

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
 Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  1024 flows (1021 inactive, 0 throttled)
  0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

“464545 flow_plimit”은 한 연결의 대기열 제한을 초과하여 삭제된 패킷 수이고, “dropped 464545”는 이 스케줄러의 모든 삭제된 패킷의 합계입니다. 대기열 길이를 1으로 늘리고 컨테이너를 다시 시작한 후 문제 발생이 중지되었습니다. 편안하게 앉아서 스무디를 마실 수 있습니다.

FragmentSmack/SegmentSmack. 라스트 블러드

첫째, 커널의 취약점이 발표된 지 몇 달 후 마침내 FragmentSmack에 대한 수정 사항이 나타났습니다(7.5월 발표와 함께 SegmentSmack에 대한 수정 사항만 릴리스되었음을 상기시켜 드리겠습니다). 이는 해결 방법을 포기할 수 있는 기회를 제공했습니다. 그로 인해 우리는 많은 어려움을 겪었습니다. 이 기간 동안 우리는 이미 일부 서버를 새 커널로 이전했으며 이제 처음부터 시작해야 했습니다. FragmentSmack 수정을 기다리지 않고 커널을 업데이트한 이유는 무엇입니까? 사실 이러한 취약점으로부터 보호하는 프로세스는 CentOS 자체를 업데이트하는 프로세스(커널만 업데이트하는 것보다 훨씬 더 많은 시간이 소요됨)와 일치(및 병합)되었습니다. 게다가 SegmentSmack은 더 위험한 취약점이고 이에 대한 수정 사항이 즉시 나타났으므로 어쨌든 의미가 있었습니다. 하지만 CentOS 7.6에서 나타났던 FragmentSmack 취약점이 버전 7.5에서만 수정되었기 때문에 CentOS에서 단순히 커널을 업데이트할 수는 없었기 때문에 7.6로의 업데이트를 중단하고 XNUMX으로의 업데이트부터 다시 시작해야 했습니다. 그리고 이런 일도 일어납니다.

둘째, 문제에 대한 사용자 불만이 드물게 접수되었습니다. 이제 우리는 이것이 모두 클라이언트에서 일부 서버로 파일을 업로드하는 것과 관련이 있다는 것을 이미 알고 있습니다. 더욱이 전체 질량 중 아주 적은 수의 업로드가 이러한 서버를 통과했습니다.

위의 이야기에서 기억하는 것처럼 Sysctl을 롤백하는 것은 도움이 되지 않았습니다. 재부팅이 도움이 되었지만 일시적이었습니다.
Sysctl에 대한 의혹은 해소되지 않았지만 이번에는 최대한 많은 정보를 수집해야 했습니다. 또한 무슨 일이 일어나고 있는지 더 정확하게 연구하기 위해 클라이언트에서 업로드 문제를 재현하는 능력이 크게 부족했습니다.

사용 가능한 모든 통계와 로그를 분석해도 무슨 일이 일어나고 있는지 더 이상 이해할 수 없었습니다. 특정 연관성을 '느끼기' 위해 문제를 재현하는 능력이 심각하게 부족했습니다. 마지막으로 개발자는 특수 버전의 애플리케이션을 사용하여 Wi-Fi를 통해 연결된 테스트 장치에서 문제를 안정적으로 재현하는 데 성공했습니다. 이는 조사의 획기적인 사건이었습니다. 클라이언트는 우리의 Java 애플리케이션인 백엔드로 프록시되는 Nginx에 연결되었습니다.

문제에 대한 대화는 다음과 같습니다(Nginx 프록시 측에서 수정됨).

1. 클라이언트: 파일 다운로드에 대한 정보를 받기 위해 요청합니다.
2. 자바 서버: 응답.
3. 클라이언트: 파일과 함께 POST.
4. 자바 서버: 오류.

동시에 Java 서버는 클라이언트로부터 0바이트의 데이터를 수신했다고 로그에 기록하고 Nginx 프록시는 요청에 30초 이상 걸렸다고 기록합니다(30초는 클라이언트 애플리케이션의 시간 초과임). 시간 초과 이유와 0바이트 이유는 무엇입니까? HTTP 관점에서 보면 모든 것이 정상적으로 작동하지만 파일이 포함된 POST가 네트워크에서 사라지는 것 같습니다. 게다가 클라이언트와 Nginx 사이에서는 사라집니다. 이제 Tcpdump로 무장할 시간입니다! 하지만 먼저 네트워크 구성을 이해해야 합니다. Nginx 프록시는 L3 밸런서 뒤에 있습니다. NF웨어. 터널링은 L3 밸런서에서 서버로 패킷을 전달하는 데 사용되며, 서버는 패킷에 헤더를 추가합니다.

이 경우 네트워크는 Vlan 태그가 지정된 트래픽의 형태로 이 서버에 제공되며 패킷에 자체 필드도 추가됩니다.

그리고 이 트래픽은 조각화될 수도 있습니다(해결 방법의 위험을 평가할 때 이야기한 것과 동일한 작은 비율의 조각화된 수신 트래픽). 이로 인해 헤더의 내용도 변경됩니다.

다시 한 번 말씀드리지만, 패킷은 Vlan 태그로 캡슐화되고, 터널로 캡슐화되고, 조각화됩니다. 이것이 어떻게 발생하는지 더 잘 이해하기 위해 클라이언트에서 Nginx 프록시까지의 패킷 경로를 추적해 보겠습니다.

1. 패킷이 L3 밸런서에 도달합니다. 데이터 센터 내에서 올바른 라우팅을 위해 패킷은 터널에 캡슐화되어 네트워크 카드로 전송됩니다.
2. 패킷 + 터널 헤더가 MTU에 맞지 않기 때문에 패킷을 조각으로 잘라서 네트워크로 전송합니다.
3. L3 밸런서 뒤의 스위치는 패킷을 수신하면 Vlan 태그를 추가하여 전송합니다.
4. Nginx 프록시 앞의 스위치는 포트 설정을 기반으로 서버가 Vlan 캡슐화 패킷을 기대하고 있음을 확인하므로 Vlan 태그를 제거하지 않고 있는 그대로 보냅니다.
5. Linux는 개별 패키지 조각을 가져와 하나의 큰 패키지로 병합합니다.
6. 다음으로 패킷은 Vlan 인터페이스에 도달하며 여기서 첫 번째 계층(Vlan 캡슐화)이 제거됩니다.
7. 그런 다음 Linux는 이를 Tunnel 인터페이스로 보냅니다. 여기서 다른 레이어가 제거됩니다(Tunnel encapsulation).

어려운 점은 이 모든 것을 tcpdump에 매개변수로 전달하는 것입니다.
끝부터 시작해 보겠습니다. 클라이언트에서 VLAN 및 터널 캡슐화가 제거된 깨끗한(불필요한 헤더 없이) IP 패킷이 있습니까?

tcpdump host <ip клиента>

아니요, 서버에는 그러한 패키지가 없습니다. 따라서 문제는 더 일찍 발생했을 것입니다. Vlan 캡슐화만 제거된 패킷이 있습니까?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx는 XNUMX진수 형식의 클라이언트 IP 주소입니다.
32:4 - SCR IP가 터널 패킷에 기록되는 필드의 주소 및 길이입니다.

인터넷에서는 약 40, 44, 50, 54를 썼지만 거기에는 IP 주소가 없었기 때문에 필드 주소는 무차별 대입으로 선택해야했습니다. 또한 XNUMX진수로 된 패킷 중 하나(tcpdump의 -xx 또는 -XX 매개변수)를 보고 알고 있는 IP 주소를 계산할 수도 있습니다.

VLAN 및 터널 캡슐화가 제거되지 않은 패킷 조각이 있습니까?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))

이 마법은 마지막 조각을 포함하여 모든 조각을 보여줍니다. 아마 IP로도 똑같은 걸 필터링할 수 있겠지만, 그런 패킷이 별로 없고, 필요한 패킷은 일반 흐름에서 쉽게 찾을 수 있었기 때문에 시도하지 않았습니다. 여기 있습니다:

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
    11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
    33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
        0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
        0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
        0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
        0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
        0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
    11.11.11.11 > 22.22.22.22: ip-proto-4
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
        0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
        0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
        0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

이는 사진(첫 번째 패키지에 Exif라는 단어가 표시됨)이 포함된 한 패키지(동일 ID 53652)의 두 조각입니다. 이 수준에는 패키지가 있지만 덤프에 병합된 형식이 없기 때문에 문제는 분명히 어셈블리에 있습니다. 마지막으로 이에 대한 기록적인 증거가 있습니다!

패킷 디코더는 빌드를 방해하는 어떤 문제도 드러내지 않았습니다. 여기에서 시도했습니다. hpd.gasmi.net. 처음에 거기에 뭔가를 넣으려고 하면 디코더가 패킷 형식을 좋아하지 않습니다. Srcmac과 Ethertype 사이에 추가로 XNUMX개의 옥텟이 있는 것으로 나타났습니다(조각 정보와 관련 없음). 제거한 후 디코더가 작동하기 시작했습니다. 그러나 아무런 문제도 나타나지 않았습니다.
뭐라고 말하든 Sysctl 외에는 아무것도 발견되지 않았습니다. 남은 것은 규모를 이해하고 추가 조치를 결정하기 위해 문제 서버를 식별하는 방법을 찾는 것뿐이었습니다. 필요한 카운터가 충분히 빨리 발견되었습니다.

netstat -s | grep "packet reassembles failed”

또한 OID=1.3.6.1.2.1.4.31.1.1.16.1 아래의 snmpd에도 있습니다(ipSystemStatsReasm실패).

"IP 재조립 알고리즘에 의해 감지된 오류 수(이유가 무엇이든: 시간 초과, 오류 등)."

문제가 연구된 서버 그룹 중에서 이 카운터는 두 개에서는 더 빠르게 증가했고, 두 개는 더 느리게 증가했으며, 두 개 이상에서는 전혀 증가하지 않았습니다. 이 카운터의 역학을 Java 서버의 HTTP 오류 역학과 비교하면 상관 관계가 드러났습니다. 즉, 미터를 모니터링할 수 있습니다.

문제에 대한 신뢰할 수 있는 지표를 갖는 것은 Sysctl 롤백이 도움이 되는지 정확하게 판단할 수 있도록 매우 중요합니다. 이전 이야기에서 우리는 이것이 애플리케이션에서 즉시 이해될 수 없다는 것을 알고 있기 때문입니다. 이 지표를 사용하면 사용자가 문제를 발견하기 전에 생산의 모든 문제 영역을 식별할 수 있습니다.
Sysctl을 롤백한 후 모니터링 오류가 중지되어 문제의 원인이 입증되었으며 롤백이 도움이 된다는 사실도 확인되었습니다.

우리는 새로운 모니터링이 작동하는 다른 서버의 조각화 설정을 롤백했으며 어딘가에서 이전 기본값보다 조각에 더 많은 메모리를 할당했습니다(이것은 UDP 통계였으며 부분 손실은 일반 배경에서 눈에 띄지 않았습니다) .

가장 중요한 질문

L3 밸런서에서 패킷이 조각화되는 이유는 무엇입니까? 사용자로부터 밸런서로 도착하는 대부분의 패킷은 SYN 및 ACK입니다. 이 패키지의 크기는 작습니다. 그러나 이러한 패킷의 점유율은 매우 크기 때문에 배경에 비해 조각화되기 시작한 큰 패킷의 존재를 인식하지 못했습니다.

그 이유는 구성 스크립트가 깨졌기 때문입니다. advmss Vlan 인터페이스가 있는 서버에서(당시 프로덕션에서는 태그가 지정된 트래픽이 있는 서버가 거의 없었습니다). Advmss를 사용하면 우리 방향의 패킷 크기가 작아야 터널 헤더를 연결한 후 조각화될 필요가 없다는 정보를 클라이언트에 전달할 수 있습니다.

Sysctl 롤백은 도움이 되지 않았지만 재부팅은 왜 도움이 되었나요? Sysctl을 롤백하면 패키지 병합에 사용할 수 있는 메모리 양이 변경되었습니다. 동시에, 프래그먼트에 대한 메모리 오버플로로 인해 연결 속도가 느려지고 큐에서 프래그먼트가 오랫동안 지연되는 결과를 낳았습니다. 즉, 프로세스가 주기적으로 진행되었습니다.
재부팅하면 메모리가 지워지고 모든 것이 주문대로 돌아왔습니다.

해결 방법 없이도 가능합니까? 예, 하지만 공격이 발생할 경우 사용자가 서비스를 받지 못하게 될 위험이 높습니다. 물론 Workaround를 사용하면 사용자 서비스 중 하나가 느려지는 등 다양한 문제가 발생했지만 그럼에도 불구하고 우리는 그러한 조치가 정당했다고 믿습니다.

Andrey Timofeev에게 많은 감사를 드립니다(아티모페예프) 조사 수행에 도움을 주신 Alexey Krenev (장치x) - 서버에서 Centos 및 커널을 업데이트하는 엄청난 작업을 위해. 이 경우 프로세스를 처음부터 여러 번 시작해야 했기 때문에 몇 달 동안 지연되었습니다.

출처 : habr.com