공유 PC에서의 VPN 로그인 하나: 라우트는 또 누가 받는가?
VPN 로그인은 한 사람을 인증하지만, 그 로그인이 설치하는 라우트는 다른 범위다. 공유 머신에서 호스트 전체, 사용자별, 앱별 터널을 비교한다.
워크스테이션을 공유하면 한 사람이 터널을 인증한 뒤에 다른 누가 그것을 사용할 수 있는지, 단일 사용자 노트북이 결코 답할 필요가 없는 질문이 생긴다. 로그인은 주체를 식별하고, 설치하는 라우트는 범위를 서술하며, 이 둘은 같은 대상이 아니다. 그 사이에는 운영체제, 클라이언트 설정, 그리고 프라이빗 서비스가 스스로 요구하는 것이 있다. 적용 지점을 비교하는 것만이 추측 없이 이 질문에 답하는 방법이다.
하나의 로그인, 여러 범위
인증은 누가 들어왔는지 답한다. 라우트는 어떤 패킷이 터널을 통해 나갈 수 있는지 답한다. 권한 부여는 어떤 서비스가 결과 연결을 받아들일지 답하며, 세 가지 중 어느 것도 다음을 함축하지 않는다.
호스트 전체 터널은 흔한 기본값이며 그 간극을 분명히 보여 준다. 라우트는 커널 테이블에 있으므로 VPN 대화 상자를 한 번도 본 적 없는 사용자가 띄운 프로세스까지 포함해 그 테이블을 쓰는 모든 프로세스가 프라이빗 네트워크에 닿을 수 있다. 이것은 터널의 결함이 아니라 시스템 전체 라우트가 뜻하는 바다. 프라이빗 서비스는 여전히 연결을 거부할 수 있으므로 도달 가능성과 권한은 별개의 답을 필요로 한다.
테스트 전에 네 가지 질문을 적어 두면 검토가 그중 하나로 무너지는 것을 막을 수 있다.
경계는 실제로 어디에 있는가
네 가지 구성이 대부분의 머신을 덮는다: 호스트 전체 터널, 사용자별 연결, 앱별 허용 목록, 그리고 별도의 네트워크 네임스페이스나 가상 머신이다.
각각은 적용 지점을 다른 곳에 두며, 차이는 이름표보다 중요하다. 사용자별 연결은 데스크톱 로그인 화면이 아니라 프로필 권한으로 적용된다. 앱별 허용 목록은 클라이언트 내부에서 적용되며, 무엇을 실어 나를지 클라이언트가 결정한다. 네임스페이스나 VM은 인터페이스 경계에서 적용하므로 안쪽 프로세스는 호스트의 라우트를 전혀 볼 수 없다. 머신에 있는 로그인 화면의 수는 그중 어느 것에 대해서도 말해 주지 않는다.
| Arrangement | Enforced by | Who can use the path |
|---|---|---|
| Host-wide tunnel | The routing table | Any local process using that table |
| Per-user connection | Profile permission list | Only the listed accounts |
| Per-app allowlist | The VPN client itself | Only the selected applications |
| Namespace or VM | The interface boundary | Only processes inside it |
테이블을 행별로 읽으면 진짜 질문은 격리가 있는지가 아니라 어디에 구현되었는지임을 알 수 있다.
네 가지 적용 지점 비교
Linux에서는 호스트 전체 터널은 거기에 나타나고 네임스페이스는 나타나지 않기 때문에 라우트 테이블을 먼저 살펴야 한다. 두 번째 사용자로 조회를 실행하는 것이 사람들이 건너뛰는 단계이며, 답은 본인으로서 얻은 것과 다르고, 그것이 보고서를 설명한다.
다음 두 가지 확인은 라우팅이 아니라 정책을 본다. UID와 일치하는 방화벽 규칙은 로컬에서 생성된 트래픽에 적용되므로 둘 다 라우트를 공유하더라도 한 호스트의 두 사용자를 분리할 수 있다. 명시적 권한 목록이 있는 연결 프로필은 활성화 시 네트워크 관리자가 적용한다. 어느 확인도 터널을 바꿀 필요가 없으므로 무엇이든 다시 설계하기 전에 해 둘 가치가 있다.
ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuid두 번째 조회가 터널 라우트를 보여 준다면, 경계는 설계가 가정한 곳에 있지 않다.
동시 세션 규칙은 별도의 통제다
게이트웨이는 흔히 한 계정이 가질 수 있는 세션 수를 제한하며, 그 한도는 로컬 사용자와 아무 관계가 없다. 계정을 제한하므로 같은 자격 증명으로 로그인한 두 번째 사람이 첫 사람의 터널을 끊을 수 있다.
로컬 격리 문제라고 가정하기 전에 실패를 읽어라. 세션 한도는 게이트웨이에서 연결 끊김을 만들고, 범위 문제는 동작하지만 다른 사용자의 트래픽을 실어 나르지 않는 터널을 만든다. 이 두 증상은 전혀 다른 수정으로 이어진다. 규칙 이름이 보통 들어 있으므로 클라이언트의 정확한 메시지를 남겨라. 한도를 우회하는 대신 프로필 소유자에게 승인된 절차를 요청하라.
가상 머신은 그 규칙에서 아무도 면제하지 않으며, 자체적인 네트워크와 자격 증명 설계를 더한다.
관심 있는 맥락을 시험하라
의도한 사용자와 앱을 시험한 뒤 거부되어야 할 맥락을 시험하라. 원래 암호가 동작함만 증명하는 검토는 인증을 시험했을 뿐 그 밖의 것은 아무것도 아니다.
sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'각 결과 옆에 적용 지점을 기록하라: 라우트 테이블, UID 규칙, 프로필 권한, 또는 게이트웨이의 세션 정책이다. 그 기록이 다음 변경을 검토 가능하게 만든다. 또한 누군가 두 번째 로그인 화면을 알아차릴 때마다 같은 질문이 다시 열리는 것을 막는다. 도달 가능성은 권한 부여가 아니며, 둘 중 어느 것도 격리가 아니다.