분할 터널이 제대로 동작하는지 검증하기: IP 결과 하나로는 테스트가 아니다

IP 주소를 보여 주는 브라우저 페이지 하나로는 분할 터널에 대해 거의 아무것도 증명하지 못한다. 보이는 주소는 틀린 이유로 맞을 수 있고, 제외된 흐름은 그것으로 결코 시험되지 않는다. 시험하기 전에 기대 결과를 적어 두라: 어떤 애플리케이션이나 목적지가 터널을 써야 하는지, 어느 것이 직접 연결로 남아야 하는지, 터널이 실패할 때 무엇이 멈춰야 하는지. 그 계획이 없으면 그럴듯한 숫자는 모두 성공처럼 보인다.

신화: 주소 조회 한 번이 커버리지를 증명한다

IP 확인은 한 시점에 한 애플리케이션이 바깥 세계에서 무엇으로 보이는가라는 한 가지 질문에 답한다. 내부 프리픽스, 두 번째 브라우저 프로필, 내부에서만 해석되어야 할 이름에 대해서는 아무 말도 하지 않는다. 장애에 대해서도 아무 말이 없는데, 장애야말로 운영 환경에서 무너지는 분할 터널 설계의 절반이다.

주소 페이지는 경로, 리졸버, 장애 정책도 보여 주지 못한다. 이것을 하나의 관찰로 다뤄야지 판정으로 다루면 안 된다.

포함된 흐름과 제외된 흐름을 시험한다

포함되어야 할 애플리케이션에서, 또는 터널을 지난다고 기대하는 프리픽스로 무해한 요청을 보내고 출발지, 목적지, 주소 체계, 관찰된 경로를 기록하라. 직접 연결로 남아야 할 흐름에도 같은 일을 하라. 제외된 쪽이야말로 사람들이 건너뛰는 쪽이며, 분할이 우연이 아니라 의도적이라는 유일한 증거다. 보조 프로세스는 별도의 정책 신원을 가질 수 있으므로 소켓을 소유한 프로세스에서 시험하라.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

그래서 잘못된 애플리케이션에서 한 시험은 설계 의도와 반대 결과를 보일 수 있다. 어떤 결론을 내리기 전에 네 가지 필드를 양쪽 모두에 대해 적어 두라.

DNS와 장애 상황을 더한다

시스템 리졸버와 앱이 쓰는 리졸버에 질의하고, 그 답을 사이트가 보고하는 출구 주소와 비교하라. 두 계층은 설계상 어긋날 수 있고, 브라우저 조회 한 번으로는 운영체제 정책을 시험할 수 없다. 셸을 쓰면 비교를 반복할 수 있다: 터널을 일부러 끊고 브라우저가 캐시하지 않은 요청을 보내라; 캐시에서 나온 페이지는 대체 경로가 어느 쪽으로 갔는지 알려 주지 않는다. 설계가 예측한 것이 아니라 실제로 일어난 일을 기록하라.

curl -s https://ifconfig.me
nslookup intranet.example

닫히는 쪽으로 실패하는 분할 터널과 열리는 쪽으로 실패하는 터널은 터널을 일부러 끊기 전까지 똑같이 보인다. 관찰한 동작을 기록하고, 기대한 동작을 기록하지 마라.

상태가 바뀐 뒤 다시 반복한다

다시 연결하고, 네트워크를 바꾸고, 관련 애플리케이션을 업데이트한 뒤 같은 관찰을 반복하라. 저장된 제외 항목은 더 이상 존재하지 않는 경로나 애플리케이션 신원을 계속 가리킬 수 있고, 설계는 조용히 문서와 어긋나기 시작한다. 이 세 사건이 분할 터널이 어긋나는 지점이며, 각각은 다시 시험하기에 비용이 적다. 배포 때 한 번만 도는 시험은 더 이상 존재하지 않는 구성을 설명한다.

결과가 다르면 여러 설정을 한꺼번에 바꾸기 전에 규칙 소유자와 처리 단계를 찾아라. 다섯 가지를 바꿔 결과 하나를 보는 것은 진단이 아니라 새 구성이다.

결과가 입증해야 하는 것

관찰을 실제로 시험한 정책과 클라이언트 버전에 묶어라. 목표는 이 배포가 주장하는 커버리지에 맞는다는 것을 보이는 것이지, 앞으로 모든 애플리케이션이 사설로만 통신하게 된다는 것을 보이는 것이 아니다. 더 좁은 주장이며, 증거로 실제로 뒷받침할 수 있는 주장이다. 주장과 버전, 네 필드 결과를 변경 기록에 적어라.

그러면 다음 검토자는 설계가 바뀐 것인지 시험이 바뀐 것인지 판단할 수 있다. 양쪽과 리졸버 분할, 장애 동작이 처음 적은 내용과 맞을 때 분할 터널은 검증된 것이다. IP 결과 하나는 그중 어느 것도 검증하지 않는다.