OpenConnect는 끊어진 VPN을 얼마나 계속 재시도해야 할까요?

--reconnect-timeout 하나의 좁은 질문에 답합니다. 터널이 끊긴 뒤 이 클라이언트 프로세스가 포기하고 종료할 때까지 얼마나 계속 시도하는가입니다. OpenConnect 매뉴얼 페이지는 이 옵션을 링크 상실이나 응답을 멈춘 피어 이후의 재시도에 대해 문서화된 기본값 300초와 함께 기록하며, 이 숫자는 실행 중인 클라이언트 하나에 대한 기한이지 VPN이 계속 도달 가능하다는 증거가 아니며, 프로세스를 살려 두는 정책도 아니어서 혼란의 대부분은 여기서 시작합니다.

그 위에 두 번째 메커니즘이 앉으면 혼란이 커집니다. 클라이언트를 재시작하는 감시자, 게이트웨이에 핑을 보내는 탐지기, 내장된 재시도 창은 모두 하나의 장애에 반응할 수 있고, 그러면 사건은 누구도 맞출 수 없는 세 개의 시간선을 낳습니다.

재연결 창이 실제로 제한하는 것

액세스 네트워크가 몇 초 동안 사라진다고 상상해 보십시오. 클라이언트는 링크 단절을 보거나 죽은 피어의 응답을 더는 듣지 못하고, 유지할 수 있는 상태를 붙든 채 세션 재수립을 시작합니다. 재시도는 게이트웨이가 다시 받아들이거나 창이 소진될 때까지 계속되고, 소진된 창은 영이 아닌 종료로 끝납니다. 수명 주기의 소유권이 프로세스를 감시하는 쪽으로 넘어가는 지점은 타임아웃 값이 아니라 바로 그 종료입니다.

창은 탐지기가 얼마나 자주 도는지에 대해서는 아무 말도 하지 않으며 인증을 연장할 수도 없습니다. 게이트웨이가 세션을 취소했거나 계정이 이제 새로운 두 번째 요소를 요구한다면, 더 오래 기다린다고 해서 오래된 세션이 다시 유효해지지는 않습니다. 재시도는 경로가 돌아오고, 게이트웨이가 세션을 여전히 인식하고, 요구하는 자격 증명이 사용 가능하게 남아 있을 때만 성공하므로, 이 숫자는 생존 간격이 아니라 기한으로 읽으십시오.

창은 실행되는 동안 애플리케이션이 무엇을 하는지도 규정하지 않습니다. 플랫폼과 장애가 얼마나 진행되었는지에 따라 클라이언트는 경로가 아직 설치된 채로 또는 경로가 제거된 뒤에 재연결하고 있을 수 있습니다. 그래서 장애 도중에 나간 요청은 빠르게 실패하는 대신 타임아웃까지 매달리는 경향이 있습니다.

감시자 재시작과 클라이언트 재시도는 두 개의 계층

실행 중인 클라이언트가 자기 창을 쓰게 하고, 종료에는 서비스 관리자가 반응하게 하십시오. systemd 아래에서 재시작 정책을 가진 포그라운드 클라이언트가 바로 그 분담, 즉 제한된 기간 동안의 재시도와 그다음 한 번의 재시작 결정을 제공합니다. 결과는 나중에도 재구성할 수 있는 하나의 시간선입니다.

백그라운드 클라이언트에 더해 인터페이스가 보이지 않을 때 다른 복사본을 시작하는 독립 폴러를 두는 것이 잘못되는 패턴인데, 그러면 두 프로세스가 같은 장치 노드, 경로, 리졸버 설정을 두고 다툽니다. 정말로 데몬을 원한다면, 클라이언트가 실제로 시작되는 명령줄에 그 옵션을 넣으십시오.

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

그 줄에서 두 가지 세부가 무게를 가집니다. --background는 프로세스를 분리하므로 pid 파일이 그것을 붙잡는 유일하게 믿을 만한 손잡이가 되며, 타임아웃은 바로 그 프로세스가 살아 있는 동안에만 소모되고, 그것을 죽이는 감시자는 계속할 예산을 남기지 않습니다.

의도적인 연결 해제에는 고유한 신호가 필요합니다. 계획된 일시 중지와 실제 장애는 순진한 관찰자에게 똑같이 보이고, 둘 다 '연결되지 않음'으로 읽힙니다. 일시 중지는 감시자의 중지 작업이나 래퍼가 이해하는 표식을 통해 이끌어, 의도적인 정지가 아무도 요청하지 않은 재시작을 일으키지 않게 하십시오.

인계가 재시도 루프와 경쟁하지 않게 하기

무인 복구는 사람의 입회 없이 갱신되는 자격 증명에 의존합니다. 대화형 데스크톱 세션 안에서만 잠금이 풀리는 키링이나 항상 입력된 코드를 요구하는 토큰은 경로가 돌아온 순간 클라이언트를 인증 단계에 발이 묶이게 하므로, 창을 늘리기 전에 그 워크플로를 정리하십시오. 더 긴 창은 같은 차단된 프롬프트에 실패할 시간을 더 줄 뿐입니다.

프롬프트를 줄이려고 서버 검증을 완화해서는 안 됩니다. 게이트웨이를 검증하는 핀이나 신뢰 앵커가 바로 자동 재연결을 안전하게 만들며, 인증서 질문을 피하려고 그것을 끄는 것은 보이는 중단을 보이지 않는 중단과 맞바꾸는 일입니다. 검증된 신원을 유지하고 대신 프롬프트를 고쳐야 하며, 어느 게이트웨이에든 연결하려는 클라이언트는 멈춰서 기다리는 쪽보다 나쁩니다.

인터페이스의 존재도 건강 신호가 아닙니다. 터널 장치는 뒤에 죽은 세션을 둔 채 존재할 수 있고, 실행 프로세스는 터널이 전혀 없이도 존재할 수 있습니다. 그 관찰 중 어느 것도 실제 요청 앞에서 버티지 못합니다. 건강은 사용자가 필요로 하는 것에서 와야 하며, 예를 들어 터널을 지나 알려진 내부 서비스로 가는 요청입니다.

장애 중과 장애 후에 무엇을 검증할지

네 가지 사건, 즉 창보다 짧은 중단, 그것보다 긴 장애, 인증 실패, 의도적인 정지를 별도 테스트로 실행하십시오. 각각은 서로 다른 예측 가능한 상태로 끝나야 하며, 첫 두 사건의 경계가 값을 고르는 이유 전부입니다.

점검은 바깥을 향하게 유지하되 프로세스 표만으로는 증명하는 것이 거의 없으므로, 짧은 단절 동안 pid가 안정적으로 유지되는지 보고 긴 단절 뒤에는 그것이 사라져 한 번 교체되었는지 확인하십시오.

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

짧은 중단 동안 클라이언트가 일찍 종료하지 않고 실제로 재시도했는지, 경로와 리졸버 항목이 중복 없이 돌아왔는지 확인하십시오. 더 긴 장애에서는 깨끗한 종료와 그 뒤에 정확히 한 번의 재시작이 있었는지 확인하십시오. 인증 실패에서는 클라이언트가 계속 거부할 게이트웨이를 상대로 헛돌지 않는지 확인하십시오. pid가 쌓이지 않고 단일 값으로 돌아오는지도 점검에 추가하십시오.

의도적인 정지에서는 상태 URL이 도달 불가능한 채로 남고 프로세스가 내려가 있어야 합니다. 그다음 애플리케이션 쪽에서 고리를 닫아, 같은 요청이 터널이 없을 때는 실패해야 하고 돌아온 뒤에는 정책이 기대하는 원본 주소에서 성공해야 합니다. 초록 터널 아이콘은 증거가 아니지만 완료된 요청은 증거입니다.