Ping은 증거가 아니다: 두 사이트 사이의 경로를 시험하라

게이트웨이에서 보낸 ping은 서비스에 대해 아무것도 말해 주지 않는다. 실제 클라이언트에서 경로를 따라가고, 앱이 쓰는 프로토콜을 사용하며, 실패하는 크기나 이름을 재현하라.

터널은 올라와 있고 게이트웨이들은 서로 응답하는데, 한 사이트의 사용자들은 여전히 다른 사이트의 파일 공유를 열지 못한다. 누군가 게이트웨이에서 핑을 보내 응답을 받고 네트워크가 건강하다고 선언한다. 그 응답은 결코 문제가 아니었던 두 장치 사이를 오간 것뿐이다. 쓸모 있는 시험은 서비스가 필요한 호스트에서 시작하고, 애플리케이션이 쓰는 프로토콜을 사용하며, 실패하는 조건을 재현한다. 나머지는 모두 아무도 다니지 않는 경로에 대한 초록불이다.

서비스가 필요한 클라이언트에서 시작하라

무엇이든 시험하기 전에 네 가지를 적어라: 클라이언트 주소, 목적지 주소, 호스트 이름, 애플리케이션 포트다. 그런 다음 서비스가 자기 사이트에서 옆 호스트로부터 로컬로 동작하는지 확인하라. 이 기준선이 없으면 고장 난 터널과 고장 난 서비스를 구분할 수 없고, 이런 티켓의 절반은 후자다.

문서에 적힌 호스트 이름을 시험하고, 서비스가 허용하는 곳에서는 같은 포트의 직접 주소 확인도 해 보라. 이름 조회 실패와 해석된 주소의 도달 불가는 서로 다른 길로 이끈다. 호스트 이름 대신 IP를 넣더라도, 동작하게 하려고 HTTPS 신원 확인을 끄지 마라 — 인증서 경고는 정보이지 장애물이 아니다.

각 가장자리에서 경로를 따라가라

클라이언트가 선택한 경로를 읽고, 다음으로 게이트웨이가 그 목적지에 대해 선택한 경로를, 다음으로 각 가장자리의 카운터나 범위를 좁힌 캡처를 읽어라. 찾는 사실은 두 가지다: 요청이 원격 LAN에 도착했는가, 응답이 돌아왔는가. 인터페이스 카운터는 다른 모든 흐름을 포함하므로 그래프 모양이 아니라 정확한 타임스탬프와 주소 쌍으로 상관시켜라. 잘못된 가장자리에서 뜬 캡처는 증거처럼 보이기 때문에 없는 것보다 나쁘다.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

요청이 원격 가장자리에 나타나는데 그 뒤에 응답이 없다면, 문제는 반대편에 있다: 방화벽, 빠진 반환 경로, 또는 출발지를 받아들이지 않는 호스트다. 요청이 아예 나타나지 않는다면 로컬 경로나 터널 선택자가 그것을 나르지 않은 것이고, 반대편은 아직 조사할 가치가 없다.

애플리케이션이 쓰는 프로토콜을 사용하라

ICMP는 약한 탐침이다. 필터링되거나 속도 제한을 받거나 서비스와 다른 정책으로 처리될 수 있어 성공과 실패가 모두 모호해진다. 실제 포트를, 가능하면 실제 프로토콜 핸드셰이크까지 시험하라.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

완료된 TCP 핸드셰이크는 그 포트의 도달 가능성과 정책을 증명한다. 애플리케이션이 동작한다는 것은 증명하지 않는다: 인증, 업로드, 특정 API 호출은 여전히 실패할 수 있다. 사용자가 실제로 하는 작업을, 실제 트랜잭션을 반복 제출하는 대신 무해한 등가물로 시험하라.

실패하는 조건을 재현하라

큰 전송에서만 나타나는 실패는 크기 문제이지 연결 문제가 아니다. don't-fragment 비트를 세운 큰 패킷을 보내 어디서 멈추는지 보라. 작은 요청이 성공하고 큰 요청이 멈춘다면 터널의 MTU와 게이트웨이의 MSS 처리가 다음 용의자다.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

한 서브넷만 실패하면 트래픽 선택자, 경로 광고, 그 서브넷의 반환 게이트웨이를 보라. 호스트 이름만 실패하면 DNS를 따라가라: 클라이언트가 어떤 리졸버를 썼는지, 그 사이트에서 원격 뷰가 보이는지도 포함한다. 세 가지 다른 고장, 세 가지 다른 수정, 그리고 ping 시험은 그중 어느 것도 구분하지 못한다.

수정한 뒤 같은 시험을 반복하라

같은 클라이언트, 목적지, 포트, 페이로드를 다시 실행하라. 그다음 설계에 있다면 다시 연결하거나 페일오버 경로를 써 보라 — 원래 터널 인스턴스가 살아 있는 동안에만 동작하는 수정은 시험된 것이 아니기 때문이다. 시험은 대시보드의 초록 표시 하나가 아니라 실제 출발지, 실제 목적지, 실제 작업에 묶어 두라.

네 가지 기준 값과 결과를 기록하라. 같은 증상의 다음 보고는 그때 ping이 아니라 증거에서 시작할 수 있다.

관련 글