두 번째 브라우저를 열어도 두 번째 VPN 경로가 생기지 않는다

브라우저 둘, 창 둘, 하나는 업무 계정에 하나는 개인 계정에 있고, 이제 서로 다른 경로를 탄다는 가정이 붙는다. 그렇지 않다. 프로필 분리는 쿠키를 따로 보관할 뿐이고, 경로 결정은 브라우저 아래에서 이루어지며 어느 프로필이 요청했는지 알지 못한다. 두 번째 경로에는 그것을 고르는 규칙이 필요하고, 그 규칙이 머물 수 있는 자리는 몇 곳뿐이다.

상태 분리는 경로 분리가 아니다

브라우저 프로필이 격리하는 것은 저장소다: 쿠키, 방문 기록, 확장 기능, 때로는 자격 증명이 여기 들어간다. 그 격리는 하나의 프로세스 트리 안에서 강제되며 어떤 인터페이스가 패킷을 나르는지에 대해서는 아무 말도 하지 않는다.

시크릿 창은 겉모습에서는 더 나아가지만 경로에서는 한 걸음도 나아가지 않는다. 브라우저가 보내는 모든 것은 소켓과 네트워크 사이에서 무언가가 바꾸지 않는 한 여전히 운영 체제가 고른 경로로 나간다. 저장소 격리와 네트워크 격리를 혼동하면 어떤 브라우저 제조사도 약속하지 않았고 어떤 시험도 만족시킬 수 없는 기대가 생긴다.

실제로 경로를 고르는 것

네 가지가 다른 경로를 고를 수 있다: 실행 파일이나 패키지에 맞는 앱별 VPN 규칙, 브라우저나 시스템 안에 설정한 프록시, 네트워크 네임스페이스나 컨테이너, 그리고 두 번째 물리 기기다. 각각은 실제로 무언가를 바꾸고, 각각 비용이 있다.

앱별 규칙은 VPN 서비스가 패키지 목록을 받는 모바일 플랫폼에서 흔한 답이다. 데스크톱에서는 클라이언트에 달려 있고, 실행 파일에 맞는 규칙은 그 파일이 여는 모든 프로필을 덮는다. 두 프로필에 정말 다른 경로가 필요하다면 보통 두 탭이 아니라 서로 다른 신원을 가진 두 프로세스가 필요하다. 그래서 공유 브라우저 설치가 프로필 단위 설계의 경계가 될 수는 없다.

앱 수준 프록시는 중간자를 하나 더 더한다

브라우저의 프록시 설정은 실제로 별도의 경로를 만들고, 프록시를 운영하는 쪽과 별도의 신뢰 관계도 만든다. 한 프로필에는 정당한 방식이지만 기기 전체를 덮는 것과 같지는 않다.

프록시는 의도적으로 고르라: 같은 호스트의 SOCKS 리스너, 터널 안의 인증된 프록시, 또는 원격 서비스다. 프록시를 전체 터널 VPN과 섞으면 장애 유형이 곱해지는 중첩 경로가 생긴다.

각 브라우저의 실제 요청을 확인하라

같은 요청을 각 브라우저에서 보내고 설정 화면을 비교하는 대신 관찰된 출구 주소를 비교하라. 설정한 프록시가 조용히 연결에 실패하는 것은 기본 경로로 되돌아가는 아주 흔한 방식이다.

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --proxy socks5h://127.0.0.1:1080 https://api.ipify.org
dig +short example.com

그다음 프록시를 강제한 상태와 터널을 내린 상태에서 같은 요청을 반복해 어느 계층이 실제로 트래픽을 나르는지 보라. DNS 응답도 기록하라, 자체 암호화 리졸버를 가진 브라우저는 시스템 경로를 완전히 우회하고도 기대한 페이지를 표시할 수 있기 때문이다.

의도한 대응을 두 줄로 적어 두라: 어느 프로세스가 어느 경로를 쓰는지, 그리고 각각을 누가 소유하는지다. 계정 신원도 함께 보라, 두 경로가 같은 로그인이 두 목적지에 제시되는 것을 막지는 않기 때문이다. 다음 브라우저 업데이트 뒤에 다시 시험하라, 프록시 설정은 잃기 쉽고 알아차리기 어렵기 때문이다.