openfortivpn이 연결될 때 경로와 DNS는 누가 소유해야 할까?

작동하는 openfortivpn 세션에서는 네 단계가 서로 겹쳐 쌓입니다. 클라이언트는 게이트웨이에서 인증하고 TLS 연결을 시작한 다음, 그 연결 안에서 PPP를 실행하고, 그다음 주소와 DNS 정보를 받고, 마지막으로 호스트 경로와 리졸버 설정을 적용합니다. 다음 단계가 살아 있지 않아도 각 단계는 살아 있을 수 있으며, 그래서 “연결됨”은 지원 스레드에서 그렇게 미끄러운 단어입니다.

혼란의 대부분을 없애는 결정은 마지막 단계를 누가 소유하는가입니다. VPN 클라이언트가 호스트 변경을 직접 적용하든, 다른 구성 요소가 하든, 둘을 중간에서 섞는 것이 경로와 리졸버 파일이 서로 다른 세션을 설명하게 되는 방식입니다.

하나의 연결처럼 보이는 네 단계

첫 번째 단계는 승인입니다. 이름 있는 인증 도메인 또는 일회용 코드를 통해, 계속하는 데 필요한 매개변수를 받습니다. 클라이언트가 게이트웨이에 연결되었다고 출력하면 TLS 전송이 살아 있다는 뜻입니다. PPP가 협상했다는 뜻이 아니며, 내부 애플리케이션에 도달할 수 있다는 뜻은 더더욱 아닙니다.

두 번째 단계는 PPP 링크입니다. 클라이언트는 터널 장치에 대해 PPP 프로세스를 시작하고, 양측은 링크 옵션과 주소를 협상합니다. 그 후에야 호스트는 세션이 어떤 로컬 및 원격 주소를 사용하는지 알게 되고, 그때서야 터널로 향하는 경로가 의미를 가질 수 있습니다.

세 번째 단계는 그 정보를 호스트에 적용하는 것이며, 여기서 소유권이 중요합니다. 클라이언트가 경로를 추가하고 리졸버 구성을 다시 쓸 수도 있고, 물러나서 둘 다 그 머신의 네트워크를 관리하는 다른 무언가에 맡길 수도 있습니다. 프로젝트의 README는 이를 하나의 자동 동작이 아니라 별도의 책임으로 설명합니다.

누가 라우팅 테이블을 편집하는가

기본적으로 클라이언트가 소유자입니다. 물리 인터페이스를 통해 게이트웨이로 향하는 경로, 터널 피어용 경로, 세션이 사용하도록 허용된 네트워크용 경로를 추가한 다음 프로세스가 종료될 때 제거합니다. 이 기본값은 네트워크 관리자가 하나이고 다른 VPN 소프트웨어가 없는 노트북에서 편리합니다.

다른 무언가가 정말로 라우팅을 소유할 때만 인계를 선택하세요. 네트워크 관리자 통합, 컨테이너 네트워크 네임스페이스, 또는 사이트 전체 라우팅 에이전트가 동일한 접두사를 설치하고 정리하는 방법을 이미 알 수 있습니다. 그때 no-routes 옵션을 넘기면 두 작성자가 같은 테이블을 두고 싸우는 것을 막는데, 이는 깔끔한 실패가 아니라 한 서브넷이 간헐적으로 사라지는 형태로 나타나는 경쟁입니다.

겹침은 인계할 두 번째 이유입니다. 푸시된 경로에 로컬 네트워크가 이미 사용하는 접두사가 포함되어 있으면 클라이언트가 그 충돌을 대신 해결할 수 없습니다. 그 접두사가 터널을 통해, 물리 링크를 통해, 또는 더 구체적인 경로를 통해 도달 가능한지 누군가 결정해야 하며, 그 결정은 토폴로지를 소유한 사람의 몫입니다.

정리가 세 번째입니다. 경로를 제거하기 전에 충돌한 클라이언트는 세션보다 오래 살아남는 블랙홀을 남기고, 다음 연결이 그 위에 중복을 추가할 수 있습니다. 라우팅을 소유하는 사람은 오래된 항목이 사라졌는지 확인하는 일도 소유합니다. 그 확인을 선택적 정리 단계가 아니라 시작 경로의 일부로 만드세요.

누가 DNS와 리졸버 파일을 소유하는가

DNS는 더 날카로운 모서리를 가진 같은 결정입니다. 클라이언트는 게이트웨이나 PPP 피어가 보고하는 DNS 서버를 받아들여 호스트 리졸버 구성에 기록할 수 있습니다. 단순한 머신에서는 그것이 바로 원하는 것이며, 내부 이름은 터널이 살아 있는 동안에만 확인됩니다.

현대 Linux 호스트에서는 리졸버가 로컬 스텁에 의해 관리될 수 있으며, 그 스텁의 뒤에서 리졸버 파일을 다시 쓰면 올바르게 보이지만 일관성 없이 동작하는 구성이 됩니다. 호스트가 이미 리졸버 관리자를 실행한다면 DNS는 그것이 소유하게 하고, 지원되는 인터페이스를 통해 터널의 서버를 넘기세요. 클라이언트의 no-dns 옵션은 거기서 올바른 선택이며 우회가 아닙니다.

분할 DNS는 파일을 누가 쓰는가와는 별개의 질문입니다. 모든 쿼리를 터널로 보내는 것은 단순하고 느리며, 내부 영역만 터널로 보내려면 대부분의 단순 클라이언트가 제공하지 않는 도메인별 구성이 필요합니다. 클라이언트의 리졸버 변경을 활성화하기 전에 호스트에 어떤 동작이 필요한지 결정하세요. 여기서 잘못 선택하면 터널 자체가 괜찮아도 이름 확인 중단처럼 보입니다.

권한, 준비 상태, 그리고 인계

터널 장치를 만들고 호스트 경로나 리졸버 상태를 편집하려면 상승된 네트워크 권한이 필요합니다. 흔한 실수는 그래서 브라우저나 터널을 사용하는 애플리케이션까지 모두 root로 실행해야 한다고 결론 내리는 것입니다. 권한 있는 부분은 작게 유지하세요: 클라이언트와 그 구성 파일은 관리자가 소유하고, 사용자 애플리케이션은 평소 계정을 유지합니다.

준비 상태는 소비자별로 정의해야 합니다. 감독자는 클라이언트 프로세스가 실행 중이고 터널 장치가 존재할 때 서비스가 시작되었다고 볼 수 있습니다. 백업 작업은 스토리지 엔드포인트가 터널을 통해 응답할 때만 VPN을 사용 가능하다고 보아야 합니다. 이것들은 서로 다른 확인이며, 약한 것을 더 강한 목적에 쓰면 너무 일찍 시작하고 간헐적으로 실패하는 작업이 생깁니다. 준비 상태에 동의하지 않는 감독자와 작업은 일어나기를 기다리는 지원 티켓이므로 선택한 정의를 적어 두세요.

네 가지 관찰로 계약을 시험하세요: 게이트웨이 단계가 완료되고, PPP가 주소를 할당하며, 의도한 경로가 존재하고, 내부 호스트에 대한 요청이 성공합니다. 그다음 클라이언트를 중지하고 그 각각이 제거되거나 복원되었는지 확인하세요. 터널이 닫힌 뒤에도 호스트가 내부 이름을 확인하거나 경로를 유지한다면 소유권 인계는 불완전합니다.