네임스페이스에서 실행된 Firefox가 URL을 기존 인스턴스에 넘겼다

명령이 VPN 네임스페이스 안에서 실행되고 Firefox 창이 나타나지만, 페이지는 여전히 일반 연결로 나갑니다. 라우팅 설정은 아마 가장 먼저 다시 만들 대상이 아닙니다. 명령이 기대한 브라우저 인스턴스를 만들었는지, 아니면 이미 다른 곳에서 실행 중이던 인스턴스에 URL을 넘겼는지 확인하세요. 그 차이가 결과를 한 단계로 설명하고 nftables 한 시간을 아껴 줍니다.

단서는 창이 콜드 스타트 없이 즉시 나타난다는 점입니다.

새 창은 새 인스턴스가 아니다

데스크톱 애플리케이션은 기존 프로세스를 일상적으로 재사용합니다. 수신자는 애초에 실행의 일부가 아니었기 때문에, 한 네트워크 네임스페이스 안의 런처는 이미 실행 중인 수신자를 그 네임스페이스로 옮기지 않습니다. Firefox의 원격 제어 동작은 프로필과 연결되며, 이미 사용 중인 프로필을 상대로 실행하면 인수가 그 소유자에게 넘어갑니다. 새 창은 진짜지만 새 네트워크 경로는 아닙니다.

사생활 보호 브라우징과 새 창 옵션은 네트워크 격리 제어가 아닙니다.

창 모드에만 영향을 주는 명령줄 플래그도 마찬가지입니다. 프로필이 사용 중이면 요청은 그것을 소유한 프로세스로 가고, 그 프로세스는 시작할 때의 네임스페이스를 그대로 유지합니다.

별도 프로필에서 별도 인스턴스를 강제하라

브라우저가 지원하는 프로필 워크플로로 만든 전용 프로필을 사용하고, 그 프로필로 명시적으로 실행하세요. 이를 지원하는 Firefox 빌드에서는 --new-instance가 기존 인스턴스 안의 창이 아니라 새 인스턴스를 요청합니다. 사용 가능한 플래그는 버전마다 다르므로 설치된 빌드 자체의 도움말 출력을 확인하세요.

같은 활성 프로필을 동시에 열려고 하지 말고, 프로필이 사용 중이라는 경고를 잠금 파일을 지우라는 지시로 받아들이지 마세요.

브라우저를 평소의 비 root 사용자로도 실행하세요. 네트워크 설정에는 관리자 권한이 필요한 경우가 많고, 같은 실험의 일부라서 브라우저에도 같은 권한을 주고 싶어집니다. 그래픽 브라우저에는 그것이 필요 없고, root로 실행하면 프로필과 권한 문제의 별도 부류가 생깁니다. 권한과 네트워크 경로를 두 가지 독립된 결정으로 유지하세요.

어느 프로세스가 트래픽을 나르는지 확인하라

Linux에서는 프로세스의 네트워크 네임스페이스가 그 네임스페이스 링크를 통해 보입니다. 요청을 보낸다고 생각하는 프로세스에 대해 읽고, 그다음 실제로 보내는 프로세스에 대해 읽으세요.

readlink /proc/ACTUAL_PID/ns/net

브라우저는 여러 프로세스를 실행하므로 정체성이 중요합니다. 연결을 만드는 콘텐츠 프로세스가 처음에 살펴본 프로세스가 아닐 수 있습니다. 링크를 의도한 네임스페이스와 비교하고, 하나의 인스턴스에 귀속시킬 수 있는 새롭고 무해한 요청으로 확인하세요. 귀속이 곧 시험의 전부이며, 어느 프로세스가 연결을 만들었는지 말할 수 없다면 그 네임스페이스를 시험한 것이 아닙니다.

네임스페이스가 정말로 잘못되었을 때

때로는 런처가 실제로 실패하고 새 인스턴스가 잘못된 네임스페이스에서 시작됩니다. 유닛이나 데스크톱 항목은 세션 버스를 통해 다시 실행될 때 네임스페이스를 잃을 수 있으므로, 그것을 낳은 서비스나 래퍼를 확인하세요. 그다음 브라우저를 탓하기 전에 올바른 네임스페이스 안의 셸에서 다시 시험하세요. 한 번에 변수 하나만 바꾸는 것이 이것을 진단 가능하게 유지하는 유일한 방법입니다.

화면을 공유해도 리졸버는 공유되지 않습니다.

프로세스가 올바른 네임스페이스에 있는데도 이름 해석이 계속 실패한다면,그 리졸버 환경을 별도 문제로 조사하세요. 다른 라우팅 변경으로는 시작되기도 전에 잘못된 인스턴스에 넘겨진 요청을 옮길 수 없습니다.