Juju charm이 VPN이 되기 전에: 아이덴티티, 계약, 포트

누군가 VPN을 실행한다고 주장하는 charm을 찾아 배포하고, 애플리케이션을 노출한 뒤 클라이언트가 연결되기를 기다립니다. 배포는 성공하고 포트는 열리지만 터널은 여전히 작동하지 않습니다. 서로 무관한 세 가지 약속이 하나로 합쳐졌기 때문입니다. charm은 특정 계약을 가진 배포 구현입니다. 그 약속들을 하나씩 살펴보면 격차는 출시 후가 아니라 전에 드러납니다.

첫 번째 단계: 읽고 있는 아티팩트를 고정하세요

후보의 자체 메타데이터를 읽으세요: 게시자, 소스 저장소, 채널, 리비전, 베이스, 아키텍처입니다. 그런 다음 워크로드 내부의 VPN 소프트웨어를 누가 유지 관리하고 누가 보안 업데이트를 제공하는지 확인하세요. 이 둘은 흔히 서로 다른 주체입니다. 잘 관리된 charm 안의 관리되지 않는 upstream은 나쁜 주를 기다리는 지원 문제입니다.

juju info CHARM_NAME은 Juju 3.6에서 채널, 베이스, 아키텍처를 보고하며, 문서는 특정 리비전 질의를 그 필터와 결합할 수 없다고 언급합니다. 명령이 거부하는 조합을 만드는 대신 리비전을 따로 질의하세요. 채널은 하나 이상을 포함할 수 있으므로 베이스와 아키텍처도 읽으세요.

검토한 정확한 조합을 배포 옆에 기록하세요. 그러면 채널을 옮기는 리프레시는 전과 후가 있는 의도된 변경이며, 월요일의 예상치 못한 일이 아닙니다.

두 번째 단계: 구성을 계약으로 읽으세요

charm이 하는 역할을 정하세요. 원격 액세스를 종료하는지, 기존 VPN에 참여하는지, 아니면 전혀 다른 것인지. 그런 다음 클라이언트 등록, 신뢰할 수 있는 발급자, 자격 증명 교체, 폐기를 어떻게 문서화하는지 찾으세요. 이 네 가지가 운영 가능 여부를 결정하며, 생성된 클라이언트 파일은 티켓용 파일이 아니라 민감한 출력입니다.

charm이 실제로 노출하는 인터페이스와 작업을 따르세요. 같은 소프트웨어의 다른 charm에 등록 작업이 있다고 해서 여기에도 있다고 가정하지 마세요.

조정이 수동 편집에 무엇을 하는지 물으세요. charm이 다음 업데이트에서 구성 파일을 덮어쓴다면 수동 수정의 수명은 업그레이드 한 번입니다. 그 동작이 어디에 문서화되어 있는지 유지 관리자에게 묻고, 침묵은 알 수 없는 것으로 다루세요.

세 번째 단계: 리스너와 전달 경로를 분리하세요

외부 리스너는 터널을 받아들이는 소켓입니다. 전달은 그 내부의 트래픽에 일어나는 일이고, 반환 경로는 응답이 돌아오게 하는 것입니다. charm은 첫 번째를 제공하고 나머지 둘을 인프라 팀에 맡길 수 있습니다.

이그레스는 세 번째 조각입니다. 터널 클라이언트가 이 호스트를 통해 인터넷에 도달해야 한다면 주소 지정이나 변환 방식이 있어야 하며, 그것은 포트를 여는 것으로 만들어지지 않습니다. 첫 클라이언트가 오기 전에 그 조각에 소유자를 지정하세요.

네 번째 단계: 노출은 방화벽 작업입니다

Juju 3.6에서 애플리케이션 노출은 클라우드 방화벽 규칙을 조정하며, 기본적으로 모든 소스에서 워크로드가 연 포트로의 트래픽을 허용합니다. 명령의 endpoint 및 CIDR 선택자는 바로 이 기본값을 좁힐 수 있도록 존재합니다.

노출은 VPN 사용자를 만들지 않고, 자격 증명을 검증하지 않으며, 전달 정책을 설치하지 않습니다. 또한 워크로드가 당신이 기대하는 주소와 전송에서 수신 중임을 증명하지 않으므로, 노출 후 테스트가 성공 메시지보다 중요합니다. 유닛의 수신 소켓과 클라우드 규칙을 모두 확인하세요.

다섯 번째 단계: 네 가지 테스트로 승인하세요

승인된 배포 후 새 클라이언트를 등록하고 의도한 프라이빗 서비스를 확인하세요. 그런 다음 그 아이덴티티를 폐기하고, 다음 로그인만 거부되는 것이 아니라 액세스가 실제로 끝나는지 확인하세요. 통제하지 않는 네트워크에서, 그다음 사무실 내부에서 검사를 반복하세요. 이 두 경로는 서로 다른 질문에 답합니다.

업그레이드와 재연결로 마무리하세요. 바로 거기서 조정, 자격 증명 처리, 서비스 재시작이 상호 작용합니다. 문서가 그 작업 중 하나의 소유자를 설명할 수 없다면, 같은 charm 이름 뒤의 관리되지 않는 레시피로 채우는 대신 도입 격차로 적어 두세요. 적어 둔 격차는 결정이고, 조용히 채운 격차는 미래의 장애입니다. 서비스 결정의 소유자에게 발견한 날짜와 함께 넘기세요.