Raspberry Pi에서 업무용 VPN: 먼저 이 질문들을 확인하세요

고용주의 네 가지 답, 즉 어떤 게이트웨이 프로토콜을 쓰는지, 어떤 운영 체제와 아키텍처를 지원하는지, 인증이 어떻게 이루어져야 하는지, 공식 클라이언트가 아닌 다른 클라이언트가 허용되는지가 Pi가 업무용 VPN에 참여할 수 있는지를 결정합니다. 포털 URL과 Linux라는 단어로는 그중 어느 것도 결정되지 않습니다. 무엇이든 내려받기 전에 물어보세요. 답에 따라 어떤 패키지를 설치할지, 화면 없는 구성이 아예 가능한지가 달라지기 때문입니다.

네 가지 답을 적어 두세요. 나머지는 각 답이 무엇을 바꾸는지에 대한 이야기입니다.

게이트웨이 프로토콜이 클라이언트를 결정한다

게이트웨이는 하나 이상의 프로토콜을 사용하며, 클라이언트는 조직이 실제로 운영하는 프로토콜을 구현해야 합니다. OpenConnect는 Cisco AnyConnect 호환성으로 시작해 이제 여러 다른 기업용 게이트웨이를 포괄하는 독립 구현입니다. 벤더의 브랜드 클라이언트가 아니며, 프로토콜 호환성이 게이트웨이의 모든 기능, 포스처 검사, 장치 정책에 대한 지원을 보장하지는 않습니다. 포털 URL에서 추측하지 말고 네트워크 팀과 프로토콜을 확인하세요. 그런 다음 고용주가 이 배포에 이 클라이언트를 허용하는지 확인하세요.

호환성 근거는 고용주의 문서나 같은 모델에서 해 본 동료에게서 나와야 하며, 저장소에 패키지가 있다는 사실에서 나오는 것이 아닙니다.

아키텍처는 세부 사항이 아니다

Pi의 OS 릴리스와 사용자 공간 아키텍처, 사용하려는 클라이언트 버전, 그 패키지의 출처를 기록하세요. 파일 이름이 바뀌었다고 해서 x86 설치 프로그램이 다른 아키텍처에 적합해지는 것은 아니며, x86 빌드만 제공하는 벤더 클라이언트는 Pi에서 아예 실행될 수 없습니다. 이 한 가지 사실만으로 인증을 논하기 전에 문제 전체가 정리될 수 있습니다. 포럼 스레드에서 떠도는 바이너리를 설치하는 대신 패키지 출처의 유지 관리를 확인하세요.

64비트 커널의 64비트 사용자 공간은 단순한 경우입니다. 64비트 보드의 32비트 사용자 공간이야말로 사람들이 잘못된 패키지를 설치하는 곳입니다. dpkg --print-architecture와 uname -m는 두 부분 모두에 한 줄씩 답합니다.

인증이 작업 흐름을 결정한다

암호, MFA, 브라우저를 통한 로그인은 각자 고유한 작업 흐름을 강요합니다. 하드웨어 토큰에 보관된 인증서는 Pi에 없는 드라이버를 필요로 할 수 있고, SSO 흐름은 화면 없는 세션이 보여 줄 수 없는 브라우저 창을 열 수 있습니다. 일부 게이트웨이는 바로 그런 경우를 위해 장치 코드나 수동 복사 경로를 제공하고, 일부는 제공하지 않습니다. 조직이 화면 없는 Linux 호스트에 어떤 방식을 지원하는지 물어보고, 의존하기 전에 시험해 보세요.

프런트엔드 통합은 인증과 별개의 선택입니다. NetworkManager 플러그인은 연결을 구성하고 그 비밀을 저장할 수 있지만, 지원되지 않는 인증 방식을 호환되게 만들 수는 없습니다. 이 두 질문을 분리해 두세요.

고용주의 경계를 지켜라

조직이 공식 클라이언트, 관리형 장치, 지원되는 배포판을 요구한다면 그 요구를 따르거나 승인된 대안을 요청하세요. 인증서 검사를 끄고, 포스처 결과를 흉내 내고, 다른 클라이언트가 허용된 것처럼 보이게 하려고 엔드포인트 제어를 끄는 것은 호환성 문제를 정책 위반으로 바꿉니다. 암호, 세션 쿠키, 개인 키를 셸 기록과 채팅 기록 밖에 두세요. 작동하는 챌린지-응답은 세션 자료를 공개할 권한이 아닙니다.

승인된 등록 후에는 사설 DNS, 의도한 리소스, 거부된 리소스, 재연결을 Pi 자체에서 확인하세요. 로그인된 터널도 여전히 잘못 라우팅되거나 권한이 없을 수 있습니다.

산출물은 이름이 있는 책임자와의 지원 가능한 합의입니다. 어떤 클라이언트, 어떤 버전, 어떤 등록 경로인지. 벤더에 가까운 클라이언트를 설치하고 나머지 요구가 선택 사항이기를 바라는 것보다 낫습니다.