Google Cloud 기술 지원에서 DNS 패킷 누락에 대한 이야기

Google 블로그 편집기에서: Google Cloud Technical Solutions(TSE) 엔지니어가 지원 요청을 어떻게 처리하는지 궁금한 적이 있나요? TSE 기술 지원 엔지니어는 사용자가 보고한 문제 원인을 식별하고 수정하는 일을 담당합니다. 이러한 문제 중 일부는 매우 간단하지만 때로는 여러 엔지니어의 주의가 동시에 필요한 티켓에 직면할 때도 있습니다. 이 기사에서는 TSE 직원 중 한 명이 최근 업무에서 발생한 매우 까다로운 문제 중 하나에 대해 설명합니다. DNS 패킷이 누락된 경우. 이 이야기에서는 엔지니어들이 어떻게 상황을 해결했는지, 그리고 오류를 수정하면서 어떤 새로운 점을 배웠는지 살펴보겠습니다. 이 이야기를 통해 뿌리 깊은 버그에 대해 배울 수 있을 뿐만 아니라 Google Cloud에 지원 티켓을 제출하는 프로세스에 대한 통찰력도 얻을 수 있기를 바랍니다.

문제 해결은 과학이자 예술입니다. 모든 것은 시스템의 비표준 동작 이유에 대한 가설을 세우는 것부터 시작되며, 그 후에 시스템의 강도를 테스트합니다. 그러나 가설을 세우기 전에 먼저 문제를 명확하게 정의하고 정확하게 공식화해야 합니다. 질문이 너무 모호하게 들리면 모든 것을 주의 깊게 분석해야 합니다. 이것이 문제 해결의 "기술"입니다.

Google Cloud에서는 Google Cloud가 사용자의 개인정보 보호를 보장하기 위해 최선을 다하기 때문에 이러한 프로세스가 기하급수적으로 더 복잡해집니다. 이로 인해 TSE 엔지니어는 시스템을 편집할 수 없으며 사용자만큼 광범위하게 구성을 볼 수도 없습니다. 따라서 우리의 가설을 테스트하기 위해 우리(엔지니어)는 시스템을 신속하게 수정할 수 없습니다.

일부 사용자는 우리가 자동차 서비스의 기계공과 같은 모든 것을 고치고 단순히 가상 머신의 ID를 보내줄 것이라고 믿는 반면, 실제로 프로세스는 정보 수집, 가설 형성 및 확인(또는 반박), 대화 형식으로 진행됩니다. 그리고 결국 결정의 문제는 내담자와의 의사소통에 기초한다.

문제의 문제

오늘은 좋은 결말을 가진 이야기를 가지고 왔습니다. 제안된 사례가 성공적으로 해결된 이유 중 하나는 문제에 대한 매우 자세하고 정확한 설명입니다. 아래에서 첫 번째 티켓의 사본을 볼 수 있습니다(기밀 정보를 숨기도록 편집됨).

이 메시지에는 우리에게 유용한 정보가 많이 포함되어 있습니다.

• 특정 VM이 지정됨
• 문제 자체가 표시됩니다 - DNS가 작동하지 않습니다
• 문제가 나타나는 위치(VM 및 컨테이너)가 표시됩니다.
• 문제를 식별하기 위해 사용자가 수행한 단계가 표시됩니다.

요청은 "P1: Critical Impact - 서비스를 프로덕션에서 사용할 수 없음"으로 등록되었습니다. 이는 "Follow the Sun" 계획에 따라 상황을 연중무휴 24시간 지속적으로 모니터링함을 의미합니다. 사용자 요청 우선순위), 시간대가 바뀔 때마다 한 기술 지원 팀에서 다른 팀으로 이전됩니다. 실제로 문제가 취리히에 있는 우리 팀에 도달했을 때는 이미 전 세계에 퍼져 있었습니다. 이때까지 사용자는 완화 조치를 취했지만 아직 근본 원인이 발견되지 않아 생산 상황이 반복될 것을 두려워했습니다.

티켓이 취리히에 도착했을 때 우리는 이미 다음 정보를 갖고 있었습니다.

• 함유량 /etc/hosts
• 함유량 /etc/resolv.conf
• 출력 iptables-save
• 팀에서 조립 ngrep PCAP 파일

이 데이터를 사용하여 "조사" 및 문제 해결 단계를 시작할 준비가 되었습니다.

우리의 첫 걸음

우선, 메타데이터 서버의 로그와 상태를 확인하여 제대로 작동하는지 확인했습니다. 메타데이터 서버는 IP 주소 169.254.169.254에 응답하며 무엇보다도 도메인 이름 제어를 담당합니다. 또한 방화벽이 VM에서 올바르게 작동하고 패킷을 차단하지 않는지 다시 확인했습니다.

그것은 일종의 이상한 문제였습니다. nmap 검사는 UDP 패킷 손실에 대한 우리의 주요 가설을 반박했기 때문에 우리는 이를 확인하는 몇 가지 추가 옵션과 방법을 정신적으로 생각해 냈습니다.

• 패킷이 선택적으로 삭제됩니까? => iptables 규칙을 확인하세요
• 너무 작지 않나요? MTU? => 출력 확인 ip a show
• 문제가 UDP 패킷에만 영향을 미치나요, 아니면 TCP에도 영향을 미치나요? => 차를 몰고 가다 dig +tcp
• 발굴 생성 패킷이 반환됩니까? => 차를 몰고 가다 tcpdump
• libdns가 제대로 작동하고 있나요? => 차를 몰고 가다 strace 양방향으로 패킷 전송을 확인하려면

여기에서는 실시간으로 문제를 해결하기 위해 사용자에게 전화하기로 결정했습니다.

통화 중에 우리는 다음과 같은 몇 가지 사항을 확인할 수 있습니다.

• 여러 번 확인한 후 이유 목록에서 iptables 규칙을 제외합니다.
• 네트워크 인터페이스와 라우팅 테이블을 확인하고 MTU가 올바른지 다시 확인합니다.
• 우리는 그것을 발견합니다 dig +tcp google.com (TCP)는 정상적으로 작동하지만 dig google.com (UDP)가 작동하지 않습니다
• 차를 몰고 가버린 tcpdump 일하는 동안 dig, UDP 패킷이 반환되고 있음을 발견했습니다.
• 우리는 차를 몰고 갑니다 strace dig google.com 그리고 dig가 올바르게 호출하는 방법을 살펴보겠습니다. sendmsg() и recvms()그러나 두 번째는 시간 초과로 인해 중단됩니다.

불행하게도 근무 시간이 종료되어 문제를 다음 시간대로 확대해야 합니다. 그러나 이 요청은 우리 팀의 관심을 불러일으켰고 동료는 scrapy Python 모듈을 사용하여 초기 DNS 패키지를 만들 것을 제안했습니다.

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

이 조각은 DNS 패킷을 생성하고 메타데이터 서버에 요청을 보냅니다.

사용자가 코드를 실행하면 DNS 응답이 반환되고 애플리케이션은 이를 수신하여 네트워크 수준에서 문제가 없음을 확인합니다.

또 다른 '세계 일주' 후에 요청이 우리 팀으로 돌아오고, 요청이 이리 저리 돌지 않으면 사용자에게 더 편리할 것이라고 생각하여 완전히 나 자신에게 전달합니다.

그동안 사용자는 시스템 이미지의 스냅샷을 제공하는 데 동의합니다. 이는 매우 좋은 소식입니다. 시스템을 직접 테스트할 수 있어 문제 해결 속도가 훨씬 빨라졌습니다. 더 이상 사용자에게 명령을 실행하고 결과를 보내고 분석하도록 요청할 필요가 없기 때문에 모든 것을 스스로 할 수 있습니다!

동료들이 나를 조금씩 부러워하기 시작했다. 점심을 먹으면서 우리는 개종에 대해 논의했지만, 무슨 일이 일어나고 있는지 아는 사람은 아무도 없습니다. 다행스럽게도 사용자 자신이 이미 결과를 완화하기 위한 조치를 취했고 서두르지 않으므로 문제를 분석할 시간이 있습니다. 그리고 이미지가 있으므로 관심 있는 모든 테스트를 실행할 수 있습니다. 엄청난!

한발 뒤로 물러서다

시스템 엔지니어 직위에 대한 가장 인기 있는 면접 질문 중 하나는 다음과 같습니다. www.google.com? 후보자는 셸부터 사용자 공간, 시스템 커널, 네트워크까지 모든 것을 설명해야 하기 때문에 질문은 훌륭합니다. 나는 웃는다: 가끔 면접 질문이 실생활에서 유용할 때가 있다...

나는 이 HR 질문을 현재 문제에 적용하기로 결정했습니다. 대략적으로 말하자면, DNS 이름을 확인하려고 하면 다음과 같은 일이 발생합니다.

1. 애플리케이션은 libdns와 같은 시스템 라이브러리를 호출합니다.
2. libdns는 접속해야 하는 DNS 서버의 시스템 구성을 확인합니다(다이어그램에서는 169.254.169.254, 메타데이터 서버임).
3. libdns는 시스템 호출을 사용하여 UDP 소켓(SOKET_DGRAM)을 생성하고 DNS 쿼리와 함께 UDP 패킷을 양방향으로 보냅니다.
4. sysctl 인터페이스를 통해 커널 수준에서 UDP 스택을 구성할 수 있습니다.
5. 커널은 하드웨어와 상호 작용하여 네트워크 인터페이스를 통해 네트워크를 통해 패킷을 전송합니다.
6. 하이퍼바이저는 패킷을 포착하여 메타데이터 서버와 접촉 시 패킷을 전송합니다.
7. 메타데이터 서버는 마술처럼 DNS 이름을 확인하고 동일한 방법을 사용하여 응답을 반환합니다.

우리가 이미 고려한 가설이 무엇인지 상기시켜 드리겠습니다.

가설: 손상된 라이브러리

• 테스트 1: 시스템에서 strace를 실행하고 dig가 올바른 시스템 호출을 호출하는지 확인합니다.
• 결과: 올바른 시스템 호출이 호출됩니다.
• 테스트 2: srapy를 사용하여 시스템 라이브러리를 우회하는 이름을 확인할 수 있는지 확인
• 결과: 우리는 할 수 있다
• 테스트 3: libdns 패키지 및 md5sum 라이브러리 파일에서 rpm –V 실행
• 결과: 라이브러리 코드는 작동 중인 운영 체제의 코드와 완전히 동일합니다.
• 테스트 4: 이 동작 없이 VM에 사용자의 루트 시스템 이미지를 마운트하고, chroot를 실행하고, DNS가 작동하는지 확인합니다.
• 결과: DNS가 올바르게 작동합니다.

테스트를 기반으로 한 결론: 문제는 도서관에 있지 않아

가설: DNS 설정에 오류가 있습니다.

• 테스트 1: tcpdump를 확인하고 dig 실행 후 DNS 패킷이 올바르게 전송 및 반환되는지 확인합니다.
• 결과: 패킷이 올바르게 전송되었습니다.
• 테스트 2: 서버에서 다시 확인 /etc/nsswitch.conf и /etc/resolv.conf
• 결과: 모든 것이 정확함

테스트를 기반으로 한 결론: 문제는 DNS 구성에 있는 것이 아닙니다

가설: 코어 손상

• 테스트: 새 커널 설치, 서명 확인, 다시 시작
• 결과: 비슷한 행동

테스트를 기반으로 한 결론: 커널이 손상되지 않았습니다

가설: 사용자 네트워크(또는 하이퍼바이저 네트워크 인터페이스)의 잘못된 동작

• 테스트 1: 방화벽 설정 확인
• 결과: 방화벽은 호스트와 GCP 모두에서 DNS 패킷을 전달합니다.
• 테스트 2: 트래픽을 가로채고 DNS 요청 전송 및 반환의 정확성을 모니터링합니다.
• 결과: tcpdump는 호스트가 반환 패킷을 수신했음을 확인합니다.

테스트를 기반으로 한 결론: 문제는 네트워크에 있지 않습니다

가설: 메타데이터 서버가 작동하지 않습니다.

• 테스트 1: 메타데이터 서버 로그에서 이상 징후 확인
• 결과: 로그에 이상이 없습니다.
• 테스트 2: 다음을 통해 메타데이터 서버 우회 dig @8.8.8.8
• 결과: 메타데이터 서버를 사용하지 않아도 해상도가 깨집니다.

테스트를 기반으로 한 결론: 문제는 메타데이터 서버에 있는 것이 아닙니다

하단 라인 : 우리는 다음을 제외한 모든 하위 시스템을 테스트했습니다. 런타임 설정!

커널 런타임 설정 살펴보기

커널 실행 환경을 구성하려면 명령줄 옵션(grub) 또는 sysctl 인터페이스를 사용할 수 있습니다. 나는 들여다 보았다 /etc/sysctl.conf 생각해 보면 몇 가지 사용자 정의 설정을 발견했습니다. 뭔가 붙잡힌 듯한 느낌이 들어서 비네트워크나 비tcp 설정을 모두 버리고 산 설정만 남았습니다. net.core. 그런 다음 VM의 호스트 권한이 있는 곳으로 가서 범인을 찾을 때까지 손상된 VM에 설정을 하나씩 적용하기 시작했습니다.

net.core.rmem_default = 2147483647

여기 DNS를 깨는 구성이 있습니다! 살인무기를 찾았어요 그런데 왜 이런 일이 일어나는 걸까요? 아직 동기가 필요했어요.

기본 DNS 패킷 버퍼 크기는 다음을 통해 구성됩니다. net.core.rmem_default. 일반적인 값은 약 200KiB 정도이지만 서버가 많은 DNS 패킷을 수신하는 경우 버퍼 크기를 늘리는 것이 좋습니다. 예를 들어, 애플리케이션이 패킷을 충분히 빠르게 처리하지 않아서 새 패킷이 도착했을 때 버퍼가 가득 차면 패킷이 손실되기 시작합니다. 우리 고객은 DNS 패킷을 통해 메트릭을 수집하는 애플리케이션을 사용하고 있었기 때문에 데이터 손실이 두려워 버퍼 크기를 올바르게 늘렸습니다. 그가 설정한 값은 가능한 최대값인 231-1이었습니다(231로 설정하면 커널은 "INVALID ARGUMENT"를 반환합니다).

갑자기 나는 왜 nmap과 scapy가 올바르게 작동하는지 깨달았습니다. 그들은 원시 소켓을 사용하고 있었습니다! 원시 소켓은 일반 소켓과 다릅니다. iptable을 우회하고 버퍼링되지 않습니다!

그런데 "버퍼가 너무 큼"이 문제를 일으키는 이유는 무엇입니까? 분명히 의도한 대로 작동하지 않습니다.

이 시점에서 나는 여러 커널과 여러 배포판에서 문제를 재현할 수 있었습니다. 문제는 이미 3.x 커널에서 나타났으며 이제 5.x 커널에서도 나타납니다.

실제로 시작하자마자

sysctl -w net.core.rmem_default=$((2**31-1))

DNS 작동이 중지되었습니다.

간단한 이진 검색 알고리즘을 통해 작동 값을 찾기 시작했고 시스템이 2147481343으로 작동한다는 것을 발견했지만 이 숫자는 나에게 의미 없는 숫자 집합이었습니다. 고객에게 이 번호를 사용해 보라고 제안했고 시스템은 google.com에서는 작동하지만 다른 도메인에서는 여전히 오류가 발생한다고 답하여 조사를 계속했습니다.

나는 설치했다 드롭워치, 이전에 사용했어야 하는 도구입니다. 이 도구는 커널에서 패킷이 끝나는 위치를 정확하게 보여줍니다. 범인은 함수였다 udp_queue_rcv_skb. 커널 소스를 다운로드하고 몇 가지를 추가했습니다. 기능들 printk 패킷이 정확히 어디에서 끝나는지 추적합니다. 딱 맞는 조건을 빨리 찾았어요 if, 그리고 잠시 동안 그것을 쳐다만 보았습니다. 왜냐하면 모든 것이 마침내 전체 그림으로 합쳐졌기 때문입니다. 231-1, 의미 없는 숫자, 작동하지 않는 도메인... 그것은 코드 조각이었습니다. __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

참고 :

• rmem int 유형입니다.
• size u16(부호 없는 XNUMX비트 int) 유형이며 패킷 크기를 저장합니다.
• sk->sk_rcybuf int 유형이며 정의에 따라 다음 값과 동일한 버퍼 크기를 저장합니다. net.core.rmem_default

언제 sk_rcvbuf 접근 방식 231에서 패킷 크기를 합산하면 다음과 같은 결과가 나올 수 있습니다. 정수 오버플로. 그리고 int이기 때문에 그 값은 음수가 됩니다. 따라서 조건이 false여야 할 때 조건이 true가 됩니다(이에 대한 자세한 내용은 다음에서 확인할 수 있습니다). 링크).

오류는 다음과 같은 간단한 방법으로 수정할 수 있습니다. unsigned int. 수정 사항을 적용하고 시스템을 다시 시작했는데 DNS가 다시 작동했습니다.

승리의 맛

내가 조사한 내용을 고객에게 전달하고 보냈습니다. LKML 커널 패치. 저는 기쁩니다. 퍼즐의 모든 조각이 서로 맞아떨어지고, 우리가 관찰한 것을 관찰한 이유를 정확히 설명할 수 있으며, 가장 중요한 것은 우리의 팀워크 덕분에 문제에 대한 해결책을 찾을 수 있었다는 것입니다!

이 사례가 드문 것으로 판명되었다는 점은 인식할 가치가 있으며, 다행스럽게도 사용자로부터 이러한 복잡한 요청을 받는 경우는 거의 없습니다.

출처 : habr.com