VPN이 아니라 무선 드라이버였다 — 서버만 보다가 놓친 것 (Part 9)

같은 증상으로 검색해 오신 분들께

증상: 특정 노트북 모델에서만 IPsec VPN 접속 실패 또는 접속 후 수십 초~수 분 뒤 끊김. 다른 장비는 동일 프로파일로 정상. 환경: Windows 10/11 / Intel Wi-Fi 6 AX201 / FortiClient 7.4.3 결론: 두 가지 클라이언트 측 원인. ① 무선 드라이버가 심하게 구형 (2020년 버전), ② 어댑터 고급 설정의 MIMO 전력 절감 모드가 "SMPS" 로 되어 있어 마이크로 단절이 발생. 조치: 드라이버 최신화 + MIMO Power Save Mode를 "No SMPS" 로 변경. 추가: 장치 관리자에 남은 중복 Fortinet 가상 어댑터(#2, #3 등)도 별개 원인으로 확인됐다. 검색 키워드: Intel AX201 VPN disconnect MIMO Power Save Mode SMPS FortiClient duplicate virtual adapter IPsec drops wifi

---

1. 증상 — "특정 장비에서만"

Part 8의 이원화 전략을 배포한 뒤에도 남은 문의가 있었다. 패턴이 있었다.

관찰내용

실패 장비	특정 노트북 모델에 집중
유선 연결	문제 없음
무선 연결	접속 실패 또는 수십 초~수 분 후 끊김
프로파일	정상 동작하는 장비와 동일
사용자 계정	같은 계정으로 다른 장비에서는 정상

"유선은 되고 무선은 안 된다" 가 결정적인 단서였는데, 이걸 알아내는 데 시간이 걸렸다. 사용자에게 "지금 와이파이로 접속 중이신가요, 랜선인가요?"를 물어볼 생각을 못 했기 때문이다.

2. 처음 세운 가설과, 그것이 왜 틀렸는가

첫 가설: 프로파일 배포가 일부 장비에 제대로 안 됐다.

Part 4~6에서 XML 문제를 세 개나 잡았으니, 또 프로파일 문제일 것 같았다. Part 8과 정확히 같은 종류의 편향이다.

그런데 이번엔 서버 로그도 봤다. Part 8에서 배운 것이 여기서 작동했다.

 

bash

diagnose vpn ike log filter clear
diagnose vpn ike log filter rem-addr4 <해당사용자공인IP>
diagnose debug application ike -1
diagnose debug enable

서버 로그에서 본 것:

• 접속 실패 사례: IKE_SA_INIT 요청이 도착하지 않거나, 도착 후 응답에 대한 후속 메시지가 오지 않음
• 접속 후 끊김 사례: 터널이 정상 수립된 뒤 DPD(Dead Peer Detection) 실패로 종료

두 번째가 특히 중요했다. DPD 실패는 "상대가 응답하지 않는다"는 뜻이다. 서버 설정 문제가 아니라 클라이언트가 실제로 잠깐씩 사라지고 있다는 신호였다.

서버 로그에 "클라이언트가 응답하지 않음"이 찍히면, 서버 설정을 더 보는 건 시간 낭비다.

3. 관측 — 클라이언트 로그와 이벤트 로그

FortiClient 로그를 봤다.

 

C:\Users\<사용자>\AppData\Roaming\Fortinet\FortiClient\logs\trace\FortiIKE_1.log

여기서 소켓 오류와 재전송이 반복되는 구간이 보였다. 그리고 그 시각을 Windows 이벤트 로그와 맞춰봤다.

 

powershell

# 무선 연결 관련 이벤트
Get-WinEvent -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" -MaxEvents 100 |
    Where-Object { $_.TimeCreated -gt (Get-Date).AddHours(-2) } |
    Select-Object TimeCreated, Id, Message | Format-List

무선 연결이 짧게 재협상되는 이벤트가 반복되고 있었다.

사용자 체감으로는 인터넷이 끊긴 게 아니다. 브라우저는 재시도로 넘어가니까 눈치채지 못한다. 하지만 IPsec 세션은 이 짧은 단절에 훨씬 민감하다. 이게 문제의 형태였다.

4. 원인 1 — 드라이버가 6년 전 것이었다

어댑터 정보를 확인했다.

 

powershell

Get-NetAdapter | Where-Object { $_.InterfaceDescription -like "*Wi-Fi*" } |
    Select-Object Name, InterfaceDescription, DriverVersion, DriverDate

결과:

 

InterfaceDescription : Intel(R) Wi-Fi 6 AX201 160MHz
DriverVersion        : 21.120.2.1
DriverDate           : 2020-09-06

2020년 드라이버였다. 노트북 출하 시점의 드라이버가 그대로 남아 있었던 것이다.

이게 왜 지금까지 문제가 안 됐나? SSL VPN은 TCP 기반이라 짧은 단절에 관대하다. TCP가 재전송으로 복구한다. IPsec은 그렇지 않다. UDP 위에서 동작하고, IKE와 IPsec SA는 상태를 갖고 있으며, DPD가 응답 없음을 감지하면 세션을 내린다.

VPN 프로토콜을 바꾸면 이전에 문제가 아니던 클라이언트 환경이 문제가 된다. SSL VPN에서 IPsec으로 옮기는 프로젝트라면 이건 예측 가능한 리스크였다. 나는 예측하지 못했다.

조치는 단순하다. 제조사 지원 페이지에서 최신 무선 드라이버를 받아 설치한다. Windows Update가 제공하는 버전은 최신이 아닌 경우가 많으므로 제조사 쪽을 쓴다.

5. 원인 2 — MIMO 전력 절감 모드

드라이버를 올린 뒤에도 일부 장비에서 마이크로 단절이 남았다.

어댑터 고급 설정을 확인했다.

장치 관리자 → 네트워크 어댑터 → 해당 무선 어댑터 → 속성 → 고급

여기에 MIMO Power Save Mode(MIMO 전력 절약 모드)가 있고, 값이 "SMPS"(Static/Dynamic SM Power Save)로 되어 있었다.

이 옵션은 배터리 절약을 위해 안테나 체인을 줄인다. 그 과정에서 짧은 링크 재협상이 발생할 수 있다. 웹 브라우징에서는 체감되지 않지만 IPsec 세션에는 충분히 치명적이다.

"No SMPS"로 변경하면 이 동작이 멈춘다. 대가는 배터리 소모 약간 증가다.

같이 확인할 값들:

설정 항목권장

MIMO Power Save Mode	No SMPS
Roaming Aggressiveness	Medium 이하 (높으면 불필요한 AP 전환)
전원 관리 탭 → "절전을 위해 이 장치 끄기"	체크 해제

세 번째는 별도 탭에 있어서 놓치기 쉽다.

6. 원인 3 — 중복 가상 어댑터

Part 8의 실험 6에서 잠깐 언급한 것이다. 일부 장비에서 이것도 원인이었다.

FortiClient를 여러 번 설치/제거한 이력이 있는 장비에서, 장치 관리자에 Fortinet 가상 어댑터가 여러 개 남아 있었다.

 

Fortinet Virtual Ethernet Adapter (NDIS 6.30)
Fortinet Virtual Ethernet Adapter (NDIS 6.30) #2
Fortinet Virtual Ethernet Adapter (NDIS 6.30) #3

#2, #3이 있으면 클라이언트가 어느 어댑터를 쓸지 혼동한다. 커뮤니티에서도 이걸 제거해서 해결한 사례가 보고돼 있다.

확인 (숨겨진 장치 포함):

 

powershell

# 숨겨진 장치까지 표시
Get-PnpDevice -Class Net | Where-Object { $_.FriendlyName -like "*Fortinet*" } |
    Select-Object Status, FriendlyName, InstanceId

또는 장치 관리자에서 보기 → 숨겨진 장치 표시를 켜고 확인한다. 숨겨진 장치 표시를 켜지 않으면 안 보이는 경우가 있다.

제거 후 FortiClient 재설치가 가장 확실하다.

7. 조치 — 점검 스크립트로 만들었다

세 가지를 매번 수동으로 확인할 수 없어서 진단 스크립트를 만들었다. 사용자에게 실행시키고 결과를 받는다.

 

powershell

# vpn-check.ps1 — 사용자에게 실행 요청, 출력을 캡처해서 보내달라고 안내
Write-Output "=== 무선 드라이버 ==="
Get-NetAdapter | Where-Object { $_.InterfaceDescription -like "*Wi-Fi*" -or $_.InterfaceDescription -like "*Wireless*" } |
    Select-Object Name, InterfaceDescription, DriverVersion, DriverDate | Format-List

Write-Output "=== Fortinet 어댑터 (숨김 포함) ==="
Get-PnpDevice -Class Net | Where-Object { $_.FriendlyName -like "*Fortinet*" } |
    Select-Object Status, FriendlyName | Format-Table -AutoSize

Write-Output "=== CA 인증서 ==="
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*example*" } |
    Select-Object Subject, NotAfter | Format-List

Write-Output "=== 최근 무선 이벤트 (2시간) ==="
Get-WinEvent -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" -MaxEvents 50 -ErrorAction SilentlyContinue |
    Where-Object { $_.TimeCreated -gt (Get-Date).AddHours(-2) } |
    Select-Object TimeCreated, Id | Format-Table -AutoSize

이 스크립트 하나가 문의 처리 시간을 크게 줄였다. "안 돼요"로 시작하는 문의에서 필요한 정보를 왕복 없이 한 번에 받을 수 있게 됐기 때문이다.

MIMO 설정은 PowerShell로 읽기가 까다로워서(레지스트리 키가 어댑터별로 다르다) 스크린샷 요청으로 처리했다. 안내문에 캡처할 화면 위치를 그림으로 넣었다.

8. 여기서 배운 것

• "특정 장비에서만"이라는 조건은 거의 항상 클라이언트 상태 차이를 가리킨다. 서버 설정을 아무리 봐도 나오지 않는다. Part 5의 CA 인증서 사례와 같은 패턴이었는데, 같은 교훈을 두 번 배웠다.
• 서버 로그에 "상대가 응답하지 않음"(DPD 실패 등)이 찍히면 그건 서버 문제가 아니다. 이 신호를 읽는 게 진단 방향을 결정한다.
• 프로토콜을 바꾸면 클라이언트 환경 요구사항이 바뀐다. SSL VPN(TCP)은 짧은 단절에 관대하고 IPsec은 그렇지 않다. 마이그레이션 계획에 "클라이언트 환경 인벤토리"가 들어 있어야 했다.
• 사용자에게 "유선인가요 무선인가요"를 먼저 묻는다. 이 한 질문이 며칠을 아꼈을 것이다.
• 반복되는 문의 유형은 진단 스크립트로 만든다. 왕복 횟수를 줄이는 것이 1인 운영에서 가장 효과적인 자동화였다.

9. 마이그레이션 프로젝트에 넣었어야 했던 항목

이 편의 문제들은 전부 사전 조사로 발견 가능했던 것들이다. 뒤늦게 만든 체크리스트를 남긴다.

 

[ ] 클라이언트 OS 버전 분포 조사
[ ] 무선 어댑터 모델 및 드라이버 버전 분포 조사
[ ] 드라이버가 2년 이상 구형인 장비 목록 → 사전 업데이트
[ ] 어댑터 전력 절감 옵션 표준값 정의 (GPO로 강제 가능하면 그렇게)
[ ] 기존 VPN 클라이언트 잔여물 정리 절차 정의
[ ] 사내 인증서 배포 상태 확인
[ ] "유선/무선" 구분을 문의 접수 양식의 첫 항목으로

대상 사용자가 100명을 넘으면, 클라이언트 환경 조사가 서버 구축보다 중요할 수 있다.

다음 편에서는

Part 10에서 파트너사용 별도 터널을 만든다. 같은 공인 IP에 PSK 터널을 여러 개 붙이려다 막혔고, 우회로는 IP를 하나 더 쓰는 것이었다.