전체 터널이 긴 분할 터널 목록보다 단순할까?

분할 터널 목록은 앱 세 개로 시작해 결국 컴퓨터의 대부분을 덮게 되며, 새 줄 하나하나가 누군가의 예외다. 그 시점에 목록은 조용히 단계가 더 붙은 기본값이 되어 있다. 전체 터널은 그 배치를 뒤집어, 문서화된 제외가 반대로 말하지 않는 한 모든 것이 터널로 들어간다. 이것이 더 단순한지는 게이트웨이와, 당신이 깨뜨리게 될 로컬 서비스에 달려 있다.

유지하는 규칙부터 세어 보라

항목을 세고, 그중 몇 개에 이름이 붙은 소유자와 마지막 검증 날짜가 있는지 세라. 중요한 것은 두 번째 숫자인데, 참조하는 소프트웨어가 이름을 바꾸거나 교체되면 주인이 없는 예외는 평가할 수 없기 때문이다. 실행 파일 경로에 묶인 규칙은 업데이트 후 조용히 실패하며, 그 실패는 낡은 규칙이 아니라 VPN이 불안정한 것처럼 보인다. 목록에 대한 의견을 갖기 전에 먼저 적어 두라.

각 항목은 세 가지 질문, 즉 그것이 없으면 무엇이 깨지는지, 누가 그렇게 정했는지, 이유가 만료된 것을 어떻게 알게 되는지에 답해야 한다. 세 가지 모두에 답할 수 없는 항목은 이전이 아니라 삭제 후보이며, 먼저 삭제하면 나중 비교가 정직해진다.

대부분의 항목이 트래픽의 큰 몫을 라우팅한다면, 당신은 이미 유지보수 부담이 붙은 전체 터널을 운영하고 있다. 그때 결정은 기본값이 어디에 사는지이지, 기본값이 있어야 하는지가 아니다.

게이트웨이가 기본값을 감당할 수 있는지 확인하라

전체 터널은 모든 패킷을 한 장치로 보내므로, 그 장치의 CPU 부하, conntrack 테이블, 주소 변환, 업스트림 대역폭 요구가 동시에 바뀐다. 사내 서브넷 몇 개를 편하게 처리하던 게이트웨이가 사용자의 브라우징 전체에 맞춰 설계되지 않았을 수 있다. 따라서 평균이 아니라 예상되는 최대 동시 세션 수, 즉 가장 먼저 부서지는 피크를 보라.

ip -s link show dev tun0
conntrack -C
ss -s

사양에서 추론하지 말고 변경 전후에 같은 작업 부하를 측정하라. 한 대에서 반나절 정도 평범하게 쓰면 게이트웨이가 한계에 가까운지 드러나며, 월요일 아침에 그것을 발견하는 것과 비교하면 비용이 들지 않는다.

경로의 MTU도 끝에서 끝까지 확인하라. 완전한 기본값은 모든 앱을 터널의 최대 패킷 크기에 노출하므로, 터널 밖에서 동작하던 앱이 미처 고려하지 않았던 단편화 동작에 의존하게 될 수 있다.

로컬 서비스와 사설 DNS가 여전히 동작하는지 확인하라

로컬에 남아야 할 것을 앱 이름이 아니라 프로토콜로 나열하라. 프린터와 디스플레이용 검색 프로토콜, 스마트 홈 브리지, 라우터 관리 페이지, LAN에서만 해석되는 이름으로 접근하는 로컬 개발 서버 같은 것들이 기본 경로가 터널을 가리키기 시작하면 깨지고, 클라이언트에서 아무것도 오류를 기록하지 않기에 조용히 깨진다.

사설 DNS가 다른 의존성이다. 내부 이름이 이전에 터널의 리졸버로 해석되었다면 아무것도 바뀌지 않는다. 로컬에서 해석되었다면 완전한 기본값이 그것들을 영역을 아는 리졸버로 운반해야 하므로, 리졸버 목록이 살아남았다고 가정하지 말고 변경 후 내부 이름 하나와 공개 이름 하나를 시험하라.

로컬 예외는 그것을 소유한 프로필에 적어라. 누군가의 기억에만 남은 예외는 다음 이전에서 가장 먼저 잃는 것이다.

프로필 하나를 이전하고 경계를 검증하라

이전 실험이 남긴 수동 경로 위에 새 기본값을 겹치는 대신 프로필 자체의 구성으로 바꿔라. 그 남은 경로가 바로 동작하는 것처럼 보이다가 하루 뒤 일관성 없이 행동하는 이전의 흔한 원인이다. 예전 프로필을 사용 가능하게 두어 되돌리기가 재구축이 아니라 선택이 되게 하라.

그다음 공개 목적지와 사설 목적지가 모두 동작하는지, 그리고 원치 않는 트래픽이 터널 밖으로 나가지 않는지 두 경계를 따로 검증하라. 성공적인 페이지 로드는 첫째를 증명하고 둘째에 대해서는 아무 말도 하지 않는다.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

재연결 후와 장애 후에 점검을 반복하라. 장애 중 트래픽을 차단하는 스위치는 이후에 올바로 복구되는 경로와 다른 속성이므로, 더 단순한 설계란 앱이나 네트워크가 바뀐 뒤에도 실제 적용 범위를 여전히 설명할 수 있는 설계다.