분할 터널링 대 기업 정책: 어느 규칙이 이기는가

분할 터널 클라이언트에서 앱 하나를 선택하는 일은 로컬 선호처럼 느껴지지만 관리되는 기기에서는 정책 변경에 더 가깝다. 이 예외는 트래픽을 승인된 경로에서 벗어나게 하는데, 그 경로는 관리되는 DNS, 필터링, 서비스가 인식하는 출발지 주소를 나르는 같은 경로일 수 있다. 클라이언트가 당신의 편집을 되돌리는 것은 잘못된 동작이 아니다. 배포가 제 역할을 하는 것이다.

체크박스를 두고 다투기 전에 그 정책이 무엇을 보호하려고 존재하는지 밝혀라.

규칙 뒤에 있는 속성

일부 배포는 모든 트래픽이 승인된 게이트웨이를 지나도록 전부 라우팅한다. 다른 배포는 이름 확인을 중시하여 질의를 로컬 네트워크가 아닌 기업 리졸버에 둔다. 또 다른 배포는 안정된 출발지 주소가 필요해 내부 서비스가 응답할지 말지를 결정할 수 있다.

네 번째 집단은 엔드포인트 상태를 강제한다. 디스크 암호화 상태, 패치 수준, 에이전트 건강이다. 터널을 나누는 것은 이를 바꾸지 않지만, 에이전트 자체의 트래픽을 피하는 우회는 바꿀 수 있다.

이것은 네 가지 서로 다른 요구이며 각각 다른 예외에 의해 깨진다. 변경을 제안하기 전에 요구를 읽어라. 작성자는 어느 것이 적용되는지 즉시 말해 줄 수 있다. 잘못된 요구를 만족하는 변경은 아무것도 사지 못한다.

두 가지 주장은 일찍 버릴 가치가 있다. 전체 터널링이 관리자에게 모든 평문 페이지를 넘겨주지는 않는다. 무엇이 보이는지는 애플리케이션 암호화와 엔드포인트 통제가 결정하며, 분할 터널링도 보편적으로 안전하지 않은 것은 아니다. 관리되는 DNS, 앱별 정책, 엔드포인트 에이전트는 경로와 무관하게 유지될 수 있다.

검사를 순서대로 실행하라

아래 순서는 예외를 실제로 실패한 가장 작은 것으로 좁힌다. 성립하지 않는 첫 검사에서 멈춰라. 나중의 수정은 앞선 결함을 보상하지 못한다.

어떤 트래픽이 지금 승인된 게이트웨이를 벗어나는지 묻고, 이름 확인이 여전히 기업 리졸버에 도달하는지 확인하라. 해당 애플리케이션이 킬 스위치를 존중하는지, 실패한 시도를 직접 경로에 썼는지 보라. 그다음 공유 서비스를 보라. 문서 뷰어나 업데이트 브로커는 체크박스가 시사하는 것보다 예외를 더 멀리 나를 수 있다. 마지막으로 재연결 시 정책이 다시 적용되는지 기록하라. 그 동작이 로컬 변경의 생존을 결정한다.

모든 답은 사실이며, 예외 요청에 필요한 것은 사실이다. VPN이 짜증나는지에 대한 논쟁은 그중 하나가 아니다. 대화가 시작되기 전에 답을 적어 두어라.

좁은 예외를 요청하라

애플리케이션, 목적지, 실패한 작업을 그 순서로 보고하라. 업데이터 하나를 직접 경로에 두는 요청은 검토할 수 있다. 브라우저 전체의 터널 우회 요청은 그렇지 않다.

이미 시도한 것과 로그가 보여 준 것을 서술하고, 헬프데스크 응대자가 아니라 프로필을 소유한 팀에 보내라. 관리되는 기기에서 프로필 소유자는 보통 업데이트 후에도 살아남는 지원되는 예외를 만들 수 있지만, 로컬 경로 편집은 그럴 수 없다.

답이 아니오라면 그것을 우회할 장애물이 아니라 설계 결정으로 다뤄라. 다음 검토가 그것을 다시 여는 자리이며, 실패한 작업을 문서화하고 업무상 이유를 붙이면 된다. 우회하는 것은 그 예외가 가치 있었던 것보다 더 많은 위험을 진다.

예외를 지속 가능하게 만들어라

승인된 변경 후에는 깨졌던 부분만이 아니라 이전에 작동하던 부분도 확인하라. 내부 이름은 여전히 기업 리졸버로 해석되어야 하고, 사설 자원은 응답해야 하며, 이전에 실패한 작업은 이제 완료되어야 한다.

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

첫 명령은 리졸버가 내부 접미사에 여전히 응답함을 증명하고, 둘째는 요청이 현재 경로에서 내부 서비스에 도달함을 증명한다. 재연결 후 다시 실행하라. 정책 푸시는 테스트 중 안정해 보이던 변경을 조용히 되돌릴 수 있다. 티켓과 함께 저장한 두 줄의 출력이 고리를 닫는다. 그것이 없으면 예외는 한 번 로드된 페이지에 대한 누군가의 기억에 기댄다.

예외와 그 목적, 포함하는 구성 요소를 배포 노트와 같은 곳에 기록하라. 문서화되지 않은 예외는 다음 분기의 사고가 되고, 문서화된 예외는 설계가 실제 작업 부하를 견딘다는 증거가 된다.