RRAS는 부팅 시 OpenVPN 터널이 준비되기 전에 시작됩니다

종속성은 서비스 시작 순서를 정할 뿐 터널을 사용 가능하게 만들지 않습니다. RRAS에 필요한 리소스의 이름을 대고, 재시작을 대기 시간이 아니라 그 리소스에 걸어 두십시오.

서버가 재부팅되고 OpenVPN이 시작되며, RRAS가 의존하는 어댑터나 경로가 아직 없을 때 RRAS가 올라옵니다. 일 분 뒤에 RRAS를 수동으로 재시작하면 고쳐지므로 문제가 해결된 것처럼 보이고 진짜 문제는 가려집니다. 여기서 두 가지 다른 조건, 즉 사전 서비스가 실행 중이라는 것과 RRAS가 실제로 필요로 하는 네트워크 리소스가 사용 가능해졌다는 것이 혼동됩니다. Windows 서비스 종속성은 첫 번째 조건을 표현할 수 있지만 두 번째는 결코 표현할 수 없으므로, 리소스를 정의하지 않고 종속성을 추가하면 겉보기만 깔끔한 부팅과 같은 실패를 얻게 됩니다.

콜드 부팅에서 증상은 어떻게 보이는가

단서는 콜드 시작과 재시작의 차이입니다. 콜드 시작에서는 터널 어댑터가 없거나 경로가 사라졌거나 피어 주소가 아직 확인되지 않은 상태에서 RRAS가 실행 중이라고 보고합니다. 수동 재시작이 그 뒤에 성공하는 것은 그때는 리소스가 존재하고 서비스가 일 분 전에는 볼 수 없었던 세상을 다시 읽기 때문입니다. 서비스 로그는 두 경우 모두 깨끗한 시작을 보여 주므로 이벤트 뷰어만으로는 이것을 거의 설명하지 못합니다.

무엇이든 바꾸기 전에, 부팅 시 RRAS가 무엇을 보고하는지와 수동 재시작이 성공하는 순간 무엇이 존재하는지의 두 상태를 기록하십시오. 이 두 관찰이 동일하다면 시작 순서는 설명이 아니며 종속성은 도움이 되지 않습니다. 이 비교는 십 분이면 되고 일주일의 추측을 아껴 줍니다.

«재시작 후에는 된다»는 근거로 추가한 종속성은 사전 서비스가 RUNNING을 보고할 때까지 같은 실패를 미룰 뿐입니다. 순서 제약이 이제 설명처럼 보이므로 부팅을 이해하기도 더 어려워집니다. 종속성이 어떤 객체를 보장하는지, 그 객체가 RRAS가 볼 수 없었던 것인지 물으십시오.

리소스의 이름을 대고, 서비스만 대지 말 것

빠진 구체적인 것을 적으십시오. 주소가 있는 터널 어댑터, 피어 서브넷으로 가는 경로, DNS 응답, 또는 아직 발급 중인 인증서일 수 있습니다. «VPN 서비스가 실행 중»은 리소스 설명이 아니며 클라이언트의 녹색 아이콘도 아닙니다. 객체와 그것을 보여 주는 명령을 댈 수 있을 때까지 기다리려는 조건을 정의한 것이 아닙니다.

이 OpenVPN 인스턴스가 어떻게 시작되는지도 확인하십시오. GUI로 관리되는 터널과 서비스로 관리되는 터널은 부팅 수명 주기가 다르며, 서비스 이름은 다른 설치 프로그램을 위해 쓰인 예제가 아니라 눈앞의 머신에서 가져와야 합니다. 기억 속 이름을 믿지 말고 후보를 나열하십시오.

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

추가하기 전에 종속성 사슬을 읽으십시오

서비스 제어 관리자는 START_PENDING과 RUNNING 같은 상태를 보고하며, SERVICE_STATUS reference는 각 필드의 의미를 정확히 정의합니다. 이 상태들 중 어느 것도 피어, DNS 이름, 하위 애플리케이션에 도달할 수 있다고 약속하지 않습니다. 이 간극이 바로 올바르게 구성된 종속성에서도 이 실패가 살아남는 이유 전부입니다.

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

sc.exe qc의 DEPENDENCIES 줄은, sc.exe config RemoteAccess depend=가 목록 전체를 바꾸며 덧붙이지 않기 때문에 보존해야 할 목록입니다. VPN 서비스를 추가할 때 무관한 사전 조건을 떨어뜨리면 다른 부팅에서 나타나는 두 번째 결함이 생기고, 원래보다 진단하기가 훨씬 어렵습니다. 건드리기 전에 기존 목록을 변경 기록에 복사하십시오.

종속성은 사전 조건을 멈추면 그것에 의존하는 서비스도 멈추기 때문에 종료 동작도 바꿉니다. 자주 재시작하는 것에 RRAS를 연결하기 전에 유지 관리 중에 무슨 일이 일어나는지 확인하십시오.

재시작을 타이머가 아니라 조건에 걸어 두십시오

고정 대기는 그 시간 안에 터널이 항상 준비된다고 가정하며, 인증서가 느리거나 링크가 끊긴 부팅에서 실패하는 것이 바로 그 가정입니다. 리소스 자체를 기한과 함께 확인하고, 재시작이 정말 필요한지 확인이 결정하게 하십시오.

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

부팅 시 실행되는 예약 작업이 그 확인을 수행하고 어댑터나 경로가 아직 없을 때만 RRAS를 재시작한다면 범위가 한정되고 감사 가능하며 제거하기 쉽습니다. 대안인 재연결마다 RRAS를 재시작하는 것은 정상 세션을 방해하고 불안정한 링크를 재시작 루프로 만듭니다. 그 루프는 이제 멀쩡했던 사용자에게 영향을 주기 때문에 원래 결함보다 나쁩니다.

하드웨어에서 터널이 합리적으로 걸리는 시간에 맞는 최대 대기를 확인에 주고, 포기할 때 작업이 영이 아닌 상태로 종료되게 하십시오. 시도를 그만두기만 하는 조용한 작업은 성공한 작업과 구별할 수 없습니다.

전환을 기록해 다음 부팅이 스스로를 설명하게 하십시오

같은 줄에 종속 서비스가 RUNNING에 도달한 시각, 필요한 리소스가 나타난 시각, RRAS가 마침내 받아들인 시각이라는 세 개의 타임스탬프를 기록하십시오. 그 한 줄이 다음 엔지니어의 질문에 답하며, 만드는 데 거의 비용이 들지 않습니다. 그것이 없으면 다음 조사는 이번과 같은 추측에서 시작합니다.

정해진 횟수의 시도 뒤에 자동화를 멈추고 영원히 재시도하는 대신 실패를 보고하십시오. «리소스가 끝내 나타나지 않았다»는 분명한 메시지로 끝나는 부팅은 어둠 속에서 서비스를 계속 재시작하는 부팅보다 가치가 있습니다. 그 메시지가 나타날 때 두 번째 절에 적어 둔 리소스 이름이 바로 다음 사람이 찾을 것입니다.

관련 글