OpenVPN Access Server: 데몬을 다시 시작할까, 설정을 적용할까
systemctl restart openvpnas는 데몬을 다시 시작하고, sacli start는 내부 서비스를 올립니다. 설정 문서가 말하는 대로 한 뒤 active 이상을 확인하세요.
OpenVPN Access Server에서 같은 작업처럼 보이는 일에 두 명령이 붙여지지만 하는 일은 다릅니다. systemctl restart openvpnas는 제품 전체를 멈추고 다시 시작합니다. sacli start는 방금 바꾼 구성을 읽는 내부 서비스를 올립니다. 둘 중 무엇을 고르는지는 취향의 문제가 아닙니다. 설정 자체의 문서가 무엇이라고 하는지, 지금 세션이 다시 시작하려는 서버를 지나가는지, 그리고 애초에 올바른 제품을 보고 있는지에 달려 있습니다.
두 계층, 하나의 데몬
Access Server는 단일 systemd 유닛인 openvpnas로 실행되며, 그 데몬이 웹 인터페이스 뒤의 내부 서비스와 VPN 리스너를 감독합니다. sacli는 같은 설치에 대한 명령줄 인터페이스로 /usr/local/openvpn_as/scripts/sacli에 있으며, 유닛을 교체하지 않고 그 내부 구성 요소를 시작하고 멈추고 조회할 수 있습니다.
그래서 두 명령이 모두 존재합니다. 데몬 재시작은 클라이언트 터널을 끊는 프로세스를 포함해 모든 것을 다시 실행합니다. sacli start는 이미 실행 중인 데몬에 구성 요소를 올리라고 요청해 새 구성을 읽게 하며, 대부분의 속성 변경이 실제로 요구하는 것이 이것입니다.
첫 조건: 설정 문서가 말하는 것
바꾼 설정의 페이지를 읽으세요. 지난달에 바꾼 설정의 페이지가 아닙니다. ConfigPut으로 쓴 속성 뒤에는 보통 sacli start가 따르며, 그 짝이 문서화된 적용 단계입니다. 리스너 수준 동작의 변경, 또는 페이지가 서비스 재시작이 필요하다고 설명하는 모든 것은 유닛 재시작이 옳은 부류입니다.
두 명령은 서로 바꿀 수 없으므로 추측했을 때의 실패 방식은 비대칭입니다. 완전한 재시작이 필요할 때 sacli start를 쓰면 이전 구성으로 계속 서비스하는 옛 프로세스가 남아 설정이 무시된 것처럼 보입니다. sacli start로 충분할 때 완전한 재시작을 하면 이유 없이 연결된 모든 클라이언트를 끊습니다.
둘째 조건: 내 세션이 터널 안에 있는가
Access Server가 제공하는 VPN을 통해 관리한다면 재시작은 셸을 실어 나르는 연결을 제거합니다. 세션이 죽은 뒤에 명령이 끝날 수 있어 성공했는지 추측하게 됩니다. 같은 이유로 sacli start도 다시 시작되는 구성 요소가 트래픽을 처리할 때 세션을 잠깐 끊을 수 있습니다.
어느 명령이든 전에 대역 밖 경로를 열어 두세요. 제공자 콘솔, 하이퍼바이저 콘솔, 또는 직렬 세션입니다. 이 조건은 명령을 언제 실행할지를 정하지, 어느 명령인지를 정하지 않으며, 짧은 변경을 장애 보고서로 바꾸는 것이 바로 이것입니다.
셋째 조건: 이것이 생각하는 그 제품인가
Access Server는 Community OpenVPN이 아니다. 커뮤니티 설치는 openvpn@server나 openvpn-client@profile 같은 유닛을 실행하고 구성은 /etc/openvpn에 있으며, 거기에는 sacli가 없습니다. 공유 호스트에서 이름에 openvpn이 들어간 모든 유닛을 재시작하는 것이 무관한 터널을 함께 떨어뜨리는 방법입니다.
무언가를 만지기 전에 확인하세요. systemctl status openvpnas --no-pager는 Access Server가 실행 중인지 답하고, sacli status는 내부 구성 요소를 나열하며, systemctl list-units --type=service는 이름에 openvpn이 포함된 유닛을 나열합니다. 마지막 명령이 프로필 이름의 유닛을 보여 준다면 커뮤니티 제품이며 여기서 나머지는 해당하지 않습니다.
적용한 뒤 active 너머로 검증하라
active를 보고하는 유닛에는 실행 중인 프로세스가 있지만 그것은 동작하는 인증 경로와 같지 않습니다. 적용 단계 뒤에 다시 시작되리라 예상한 구성 요소에 대해 sacli status를 확인하고, 값이 sacli ConfigQuery로 저장되었는지 확인한 다음, 테스트 계정으로 제한된 클라이언트 로그인을 한 번 실행하세요.
응용 수준의 무언가로 끝내세요. 터널을 통해 사설 리소스에 도달하는 것이지 서버의 공인 주소로 핑만 하는 것이 아닙니다. 밀어 넣은 경로나 DNS 설정이 틀린 상태에서 성공하는 핸드셰이크는 모든 서비스 점검을 통과하고도 문제를 신고한 사람을 실패하게 만듭니다.
공급자의 서비스 관리 안내서는 어떤 작업이 sacli에 속하는지에 대한 참조이며, 재시작이 안전한 선택이라고 정하기 전에 열어 볼 가치가 있습니다.
한 번의 흐름으로 내리는 결정
이 네 줄을 따라 내려가 처음 맞는 줄에서 멈추세요.
- 설정 페이지가 sacli start를 언급하거나 방금 ConfigPut을 실행했습니다. sacli start를 쓰세요.
- 페이지가 재시작을 요구하거나 변경이 속성이 아니라 리스너에 닿습니다. systemctl restart openvpnas를 쓰세요.
- 셸이 이 서버를 통해 들어옵니다. 먼저 콘솔 접근을 마련하고, 그다음 위 두 줄이 고른 명령을 실행하세요.
- 검증. sacli status, 값에 대한 ConfigQuery, 로그인 한 번, 사설 리소스 하나. 서비스 상태만으로는 결승선이 아닙니다.
그 줄 중 둘은 점검이고 둘은 행동이며, 순서의 의미가 여기에 있습니다. 제품 질문에 답할 수 없다면 멈추세요. 실행하려던 명령은 다른 설치의 것이고, 떨어뜨릴 터널은 의도한 것이 아닙니다.