TCP 핸드셰이크 뒤에 멈추는 쿼리는 라우팅 문제가 아니다. 경로 결함은 핸드셰이크를 실패시키므로, 세션이 맺어진 뒤 조용해진다는 것은 경로 내부를 가리킨다. 검사, MTU, 또는 터널의 UDP 패킷이 도착하는 방식이다. 앞에 놓인 결정은 그 경로를 고칠지 터널을 TCP로 옮길지다. 세 가지 조건이 그것을 정하며, 어느 것도 데이터베이스에 관한 것이 아니다.

터널을 탓하기 전에 멈춤을 분류하라

네 가지 결과는 사용자에게 똑같아 보이지만 엔지니어에게는 전혀 다른 의미다.

What the client seesWhat it rules out
Connection refusedNothing is listening on the address and port the client reached
Timeout before the handshakeA filter, a missing route, or the wrong address
Handshake completes, query hangsThe session exists, so look at inspection, MTU and packet order
Stalls that recover on retryOften reordering, or a state table entry expiring

터널에 시간을 쓸 명분이 있는 것은 마지막 두 줄뿐이다. VPN을 건너 거부된 연결은 보통 데이터베이스가 loopback에서만 듣는 경우이며 이는 리스너 문제이고, 핸드셰이크 전 타임아웃은 필터나 경로다. 둘 다 캡슐화를 바꿔서는 나아지지 않는다.

분류를 먼저 티켓에 적어라. 가장 값싼 단계이며 탐색 공간의 대부분을 없앤다.

UDP와 TCP를 가르는 세 가지 조건

캡슐화된 IPsec 트래픽은 UDP로 흐르고, UDP는 경로에 아무에게도 말하지 않고 재정렬하고 버릴 자유를 준다. 재정렬이 패킷을 터널의 재전송 방지 창 밖으로 밀어내면 그것들은 조용히 폐기되고 안쪽 TCP 세션은 그저 기다린다. 핸드셰이크는 성공하는데 쿼리가 결코 돌아오지 않는 이유가 이 메커니즘이다.

경로를 고칠지 TCP로 돌아갈지는 세 가지에 달려 있다. 첫째, 경로에 실제 패킷 손실이 있는가, 아니면 재정렬뿐인가. 둘째, 검사가 일어나는 위치를 바꿀 수 있는가, 아니면 재정렬하는 구성 요소에서 이 터널을 제외할 수 있는가. 셋째, 워크로드가 멈춤 패턴에 민감한가, 예를 들어 링크 하나를 공유하는 다중화 세션이 많은가.

첫 답이 손실이고 둘째가 아니면,443의 TCP가 현실적인 대안이다. 둘째 답이 그렇다면 경로를 고치고 UDP를 유지하라.

애플리케이션 오류가 아니라 방화벽 기록을 읽어라

애플리케이션은 타임아웃을 보고하지만 그것은 원인에 대해 아무것도 말해 주지 않는다. 방화벽 자체의 로그가 폐기나 차단이 나타나는 곳이므로 데이터베이스와 애플리케이션 주소로 걸러 허용뿐 아니라 폐기도 찾아라.위협 방지 블레이드는 애플리케이션 수준 오류를 만들지 않고 패킷을 폐기할 수 있다, 그리고 그것이 멈추는 쿼리의 정확한 모양이다. 로그의 침묵도 데이터다. 로그를 남기지 않는 무언가, 예컨대 재정렬을 가리킨다.

클러스터도 확인하라. 잘못 구성된 클러스터는 패킷이 다른 구성원의 경로를 가는데도 한 구성원의 상태 테이블에 세션을 붙잡아 두어, 상태가 없는 곳으로 응답이 도착하게 만들 수 있다. 그런 멈춤은 무작위로 보이고 부하와 상관관계가 없다.

무언가를 바꾸기 전에 양쪽 끝을 비교하고, 패킷 수가 아니라 도착 순서를 비교하라:

tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap

443의 TCP가 실제로 무엇을 치르게 하는가

터널을 TCP로 옮기면 재정렬 증상은 사라진다. 중간 장비가 이제 순서가 있는 스트림을 보기 때문이다. 대신 TCP over TCP를 만든다. 바깥 연결이 안쪽 연결이 이미 재전송한 것을 다시 전송하고, 손실 하나로 다중화된 모든 세션이 한꺼번에 멈출 수 있다. 깨끗한 경로에서는 보이지 않는다. 손실이 있는 경로에서는 치료가 증상보다 나쁘다.

대안이 연결 자체가 없는 상황이라면 이 맞바꿈은 받아들일 만하며, 정상으로 흡수하기보다 책임자를 둔 예외로 기록해야 한다.

전송 방식, 포트, 예시 쿼리, 측정한 결과, 그리고 날짜를 기록하라. 그 기록이 없으면 다음 엔지니어가 실험을 되풀이하고, 예외는 조용히 아키텍처가 된다.

결정을 다시 검토할 수 있게 유지하라

경로 진단은 빠르게 낡는다. 중간 장비가 교체되고, 블레이드 구성이 바뀌고, 링크가 업그레이드되며, 구성은 남은 채 443의 TCP 이유만 사라진다. 예외에 검토 날짜를 붙이고 UDP로 돌아갈 수 있게 할 조건을 명시하라.

작은 쿼리와 큰 결과 집합으로 두 전송 방식을 모두 시험하라. 재정렬은 크기에 따라 달라지는 멈춤으로 나타나고, 리스너 결함은 두 크기를 똑같이 멈춘다.

관련 글