스플릿 터널 규칙이 서비스와 일치하지 않게 된 이유

스플릿 터널링은 보통 두 가지 방식 중 하나로 실패합니다. 터널 안에 있어야 할 트래픽이 터널을 우회하거나, 밖에 있어야 할 트래픽이 안으로 끌려 들어옵니다. 오래된 규칙으로 인한 실패는 첫 번째 유형이고, 규칙이 쓰인 그대로 시행되기 때문에 더 혼란스럽습니다. 달라진 것은 목적지로, 서비스가 이제 규칙이 한 번도 지목하지 않은 주소에서 응답하며 터널 자체에는 아무 문제가 없습니다.

규칙이 고정하는 것과 DNS가 반환하는 것

스플릿 터널 규칙은 목적지에 대한 정적 진술이며, 보통 프리픽스, 경로 또는 주소 목록으로 표현됩니다. 전송 시점에 패킷의 목적지에 대해 평가됩니다. 호스트 이름은 수명과 캐시를 가진 주소 집합을 반환하는 조회이며, 응답은 리졸버, 쿼리 유형, 분에 따라 달라질 수 있습니다.

그 두 객체는 서로 협상하지 않습니다. 규칙은 주어진 프리픽스와 계속 일치하고, 서비스는 내주는 주소를 계속 바꾸며, 둘 사이의 간격은 조용히 벌어집니다. 그래서 증상은 구성 변경 후가 아니라 공급자 이전이나 인증서 갱신 후에 나타납니다. 아무도 터널을 편집하지 않았으므로 아무도 터널을 보지 않고, 진단은 정책이 아니라 앱 쪽으로 흘러갑니다.

일치가 깨지는 세 가지 방식

분명한 경우는 이전한 서비스로, 운영자가 새 주소를 주었고 DNS는 따라갔지만 예외는 따라가지 않았습니다. 두 번째는 규칙이 한 번도 포괄하지 않은 주소 패밀리로, 이름이 IPv4 전용 예외가 무시하는 AAAA 레코드를 반환하기 시작할 때 생깁니다. 세 번째는 리졸버 차이로, 내부 보기와 공개 보기가 같은 이름에 다른 주소를 반환할 수 있어 앱이 사용하는 주소가 테스트에 사용한 주소와 다를 수 있습니다.

캐시된 연결은 네 번째 변형이며 놓치기 쉽습니다. 앱이 한 시간 전에 해석한 주소와 여전히 통신하고 있을 수 있으며, 이는 새 조회 결과와 열린 소켓이 서비스의 위치에 대해 합의하지 않는다는 뜻입니다.

앱이 실제로 사용하는 목적지를 읽으십시오

브라우저 탭이 아니라 운영 체제와 소켓 표에 물어보십시오. 조회는 이름이 지금 무엇으로 해석되는지 답하고, 소켓 표는 프로세스가 연결된 주소를 보여 주며 그 주소는 더 오래되었을 수 있습니다. 둘 사이의 차이가 대략 절반의 경우에서는 답 자체이므로 이론을 세우기 전에 둘 다 실행하십시오.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

그런 다음 규칙이 포괄하는 것과 비교하십시오. 현재 주소가 예외 밖에 있고 요청이 여전히 실패한다면, 터널 구성을 건드리지 않고 원인을 찾은 것입니다. 앱이 규칙과 일치하는 주소에 연결되어 있고 요청이 여전히 실패한다면, 문제는 터널 너머에 있으며 이는 잘못된 조사입니다.

증상이 아니라 메커니즘을 고치십시오

제품이 유지 관리되는 도메인 기반 유도를 지원한다면 그것을 사용하고 문서화된 새로 고침 및 범위 동작을 따르십시오. 이는 정적 추측을 유지 관리되는 답으로 대체하지만, 기능이 문서대로 작동하는 데 의존하는 비용이 있습니다.

설계가 정적 목록에 의존한다면 소유자와 업데이트 계획을 부여하십시오. 계획은 주소를 어떻게 발견하는지, 누가 변경을 승인하는지, 목록이 공급자 이전을 얼마나 빨리 따라야 하는지를 명시해야 합니다. 소유자 없는 목록은 원인이 알려진 미래의 장애입니다.

짧은 테스트에서 본 모든 주소를 잡기 위해 예외를 큰 인접 네트워크로 넓히지 마십시오. 그것은 수정이 아니라 보안 경계의 영구적 변경이며, 규칙이 존재하는 한 무관한 서비스가 조용히 터널을 우회하도록 내버려 둘 것입니다.

의도의 양쪽 절반을 검증하십시오

스플릿 터널 설계에는 두 가지 의도가 있으며 수정은 둘 다 보존해야 합니다. 보호된 서비스는 터널을 통과해야 하고, 제외된 범주는 계속 터널을 우회해야 합니다. 수리된 목적지에 새 연결을 테스트한 다음, 밖에 남아 있어야 하는 것을 테스트하십시오.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

새 주소, 선택한 메커니즘, 날짜를 기록하십시오. 그 메모가 다음 사람이 VPN이 자기 구성을 무작위로 무시했다고 결론 내리지 않게 막아 줍니다.