포함 전용인가 제외 전용인가: 분할 터널링의 기본값은 어느 쪽인가
목록을 만들기 전에 기본값을 정한다. 이름을 올린 대상만 터널로 보낼지, 모든 것을 터널로 보내고 예외를 잘라낼지. 그다음 아무도 목록에 넣지 않은 앱으로 시험한다.
VPN 클라이언트의 라우팅 항목을 열면 똑같은 이름표를 단, 모양이 다른 두 개의 제어가 보인다. 하나는 터널에 넣을 목적지를 나열하게 하고 나머지는 계속 로컬 네트워크를 쓰게 한다. 다른 하나는 모든 것이 터널을 지난다고 전제하고 무엇을 다시 밖으로 꺼낼지 묻는다. 둘 다 첫 시험에서는 잘 도는 터널을 주고 둘 다 목록에 줄을 더해 유지되므로, 누군가 새것을 설치할 때까지 그 차이는 보이지 않는다.
이것은 기능이 아니라 기본값의 선택이다. 목록에 스무 개 항목이 붙기 전에 정해 두어라.
기본값은 안내서가 아니라 클라이언트에서 읽는다
WireGuard는 AllowedIPs이 포함 목록일 뿐 그 밖의 뜻이 없기 때문에 이 결정을 유난히 잘 드러낸다. 0.0.0.0/0, ::/0을 가진 피어는 모든 것을 터널로 보내고, 10.20.0.0/16을 가진 피어는 그 대역만 보낸다. 제외 문법은 없으므로 한 서브넷만 빼고 싶다면 나머지 프리픽스를 모두 나열하거나 인터페이스 밖에서 정책 라우팅을 더해야 한다.
OpenVPN은 redirect-gateway def1이 전체 터널을 세우고 개별 route 지시문이 특정 프리픽스를 더하거나 덮어쓰는 식으로 반대 방향에서 같은 지점에 닿는다. 상용 클라이언트는 대개 둘 다 체크 상자와 목적지 표 뒤에 감추므로 이름표를 믿기 전에 표가 실제로 어느 쪽을 고치는지 읽어야 한다.
물어야 할 것은 체크 상자의 이름이 아니다. 두 목록 어디에도 없는 목적지를 가진 패킷에 무슨 일이 생기는가이다. 그것을 글로 적어 두면 나머지 설정은 거기서 따라 나온다. 이 질문을 건너뛰면 첫 번째 설명되지 않는 장애는 그날 클라이언트에 가장 가까운 사람이 정하게 된다.
아무도 목록에 넣지 않은 앱을 따라가 본다
포함 전용 설계에서 그 앱은 로컬 네트워크와 로컬 DNS로 곧장 나간다. 제외 전용 설계에서는 서버가 허용하는 범위 안에서 터널을 지나며, 새 SaaS 도구가 첫날부터 도는지 VPN이 그것을 망가뜨렸다는 티켓이 열리는지의 차이가 흔히 여기서 갈린다.
어느 기본값도 그 자체로 더 안전하지는 않다. 포함 전용은 터널이 나르는 범위를 좁혀 로컬 네트워크를 가장 저항이 적은 길로 만들고, 제외 전용은 터널을 정상 경로로 보고 예외를 예외로 다루는데, 이는대부분의 기업 정책이 실제로 의도하는 바에 더 가깝다.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
플랫폼이 어떤 종류의 객체를 나열하는지 보라
Android의 VpnService.Builder은 허용 앱 목록과 차단 앱 목록을 두 개의 별도 모델로 노출하고, 앱 단위 규칙은 목적지가 아니라 패키지로 고른다. 그런 목록에 넣은 브라우저는 열어 젖히는 모든 목적지를 함께 지니고 다니며, 이는 라우팅 표와 다른 입자이므로 동작하는 앱 안의 깨진 사이트 하나를 고칠 수 없다.
데스크톱 클라이언트는 대개 두 종류를 한 화면에 섞으므로지금 추가하는 행이 패키지인지, 호스트 이름인지, 프리픽스인지를 확인한다. 둘은 실패하는 방식도, 풀리는 자리도 다르다. 호스트 이름 행은 보통 경로와 이름이 되고, 패키지 행은 클라이언트 안의 정책 결정이 된다. 나중에 디버깅하는 사람은 반대쪽을 전제하므로 어느 쪽을 넣었는지 적어 두어라.
행복한 경로만이 아니라 실패 상태를 시험한다
터널에서 제외한 앱이 자동으로 깨끗한 직접 접근을 얻지는 않는다. 클라이언트가 VPN 없이 차단하는 규칙도 함께 적용하면 제외한 트래픽이 통째로 버려질 수 있고, 그것은 라우팅 결정이 아니라 망가진 앱처럼 보인다. 사용자 신고로 알기 전에 그 경우를 일부러 시험하라.
다음으로 DNS와 IPv6를 따로따로 확인한다. IPv4만 나르는 터널은 v6를 다루는 앱에 우회로를 남기고, split DNS는 터널을 아예 지나지 않는 트래픽에서 내부 이름이 풀리는지를 정한다. 목록에 있는 앱, 목록에 없는 앱, 이름 조회, 재접속 한 번을 돌려 보고 결과를 설정과 함께 보관한다.
기본값을 다음 사람이 찾을 자리에 적어 둔다
고른 기본값과 예외, 그 주인을 클라이언트 프로필과 같은 곳에 기록한다. 다음 관리자는 이 이유를 읽지 않고 항목을 더할 것이기 때문이다. 날짜와 예외마다의 이유를 적어 두면, 나중에 고쳐진 사이트를 위한 낡은 예외를 확신을 갖고 지울 수 있다 — 이유가 없는 목록은 끝없이 자란다.
누군가 깨진 목적지 하나를 신고하면 기준이 아니라 예외를 바꾼다. 사이트 하나를 고치려고 기본값을 뒤집으면 목록에 없는 모든 앱이 조용히 터널 반대편으로 옮겨 간다.