Windows에서 주소를 받았다가 놓아버리고 몇 초마다 이를 반복하는 OpenVPN 어댑터는 보통 DHCP 버그가 아닙니다. 어댑터는 이미 다른 무언가가 응답하고 있는 주소를 사용하라는 지시를 받으므로 Windows가 이를 사용할 수 없는 것으로 표시하고 클라이언트는 처음부터 다시 시작합니다. 충돌은 그 아래, 운영 체제 자체의 네트워크 스택 안에서 해결되기 때문에 클라이언트 로그는 조용합니다.

이 차이는 터널 구성만 겨냥한 모든 문제 해결 단계가 서버 쪽의 중복 주소를 놓치기 때문에 중요합니다.

클라이언트 로그가 아니라 Windows 이벤트 로그부터 시작하세요

Windows는 주소 충돌을 시스템 로그에 이벤트 ID 4198과 4199로 기록합니다. 첫 번째는 주소에 대해 감지된 충돌을 보고하고, 두 번째는 인터페이스가 구성된 주소를 사용할 수 없었음을 보고합니다. 어느 것도 OpenVPN을 언급하지 않으며, 바로 그래서 놓치기 쉽습니다.

최근 이벤트를 가져와 타임스탬프를 어댑터의 갱신 주기와 비교하세요: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. 십오 초마다 발생하는 충돌은 계속 응답하는 소유자를 상대로 같은 주소를 다시 시도하는 클라이언트와 일치합니다. 연결 시점의 단일 충돌은 오히려 일회성 충돌을 가리킵니다. 어느 쪽이든 다음 질문은 누가 그 주소를 더 가지고 있느냐입니다.

세 가지 배치가 두 호스트를 한 주소에 올린다

서버에 누가 주소를 가지고 있다고 보는지 묻고, 그다음 네트워크에 누가 응답하는지 물으세요. grep -H ifconfig-push /etc/openvpn/ccd/* 는 고정된 터널 주소와 그것이 속한 인증서를 나열합니다. ip -4 neigh show dev tap0 는 브리지가 두 번째 계층에서 학습한 것을 보여줍니다. 이 두 목록을 비교하면 대부분의 중복을 일 분 이내에 찾습니다.

세 가지 배치가 거의 모든 경우를 설명합니다: client-config-dir 항목이 인증서 두 개에 하나의 주소를 고정하거나, 브리지된 tap 세그먼트가 다른 호스트가 이미 정적으로 가진 주소를 한 머신에 주거나, 오래된 임대 파일이 아직 연결된 클라이언트가 자기 것이라고 믿는 주소를 돌려주는 경우입니다. 세 번째가 가장 교활한데, ifconfig-pool-persist 가 알려진 클라이언트에 대해 의도적으로 주소를 재사용하기 때문입니다.

주소를 두고 경쟁하는 대신 고유하게 만드세요

부팅 순서는 오늘 누가 이기는지만 결정하므로 재시작 순서에 기반한 모든 수정은 임시로 여기세요. 각 클라이언트에 자체 ifconfig-push 줄을 주거나 브리지나 서버 인터페이스가 건드리지 않는 범위에서 정적 주소를 할당하세요. 클라이언트 목록에서 중복된 공통 이름도 확인하세요, duplicate-cn 가 두 세션이 하나의 신원을, 따라서 하나의 고정 주소를 공유하게 하기 때문입니다. 브리지된 장치에 정말 고정 주소가 필요하다면 자체 서브넷으로 옮기거나 서버가 기록하는 위치에서 풀에서 예약하세요.

persist 파일은 어떤 임대를 담고 있는지 확인한 뒤에만 삭제하세요, 그렇지 않으면 다음 재연결이 같은 주소를 다시 배포합니다.

올바른 순서로 재시작하고 주소마다 소유자가 하나인지 확인하세요

먼저 서버에 변경을 적용한 다음 클라이언트를 다시 연결해 모든 참여자가 수정된 풀에 등록되게 하세요. 클라이언트를 먼저 재시작하면 서버가 아직 사용 중이라고 보는 주소를 그대로 들고 있게 됩니다. 재시작 후 상태 파일을 읽고 모든 공통 이름이 하나의 주소로 한 번씩 나타나는지 확인하세요. 한 이름에 항목이 두 개라는 것은 예전 세션이 닫히지 않았다는 뜻이지 풀이 망가졌다는 뜻이 아닙니다.

클라이언트가 여전히 주소를 유지하지 못하면 같은 호스트의 브리지 인터페이스가 그 주소를 가져가고 있는지 확인하세요. 벤더 장치에서 주소를 물려받은 브리지는 VPN 서버가 이미 그 주소를 클라이언트에게 넘겼더라도 ARP에 응답합니다.

티켓을 닫기 전에 전체 갱신 주기를 지켜보세요

한 번의 깨끗한 판독으로는 아무것도 증명되지 않습니다. 어댑터를 최소 십 분 동안 지켜보고 중간에 재연결을 강제하세요: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. 주소는 재연결을 견디고 선호 상태로 남아 있어야 합니다.

그다음 첫 단계의 이벤트 쿼리를 다시 실행해 새로운 것이 반환되지 않는지 확인하세요. 재연결 전반에 걸친 조용한 로그가 충돌이 사라졌다는 증거이며, 연결 한 번 후의 조용한 로그는 경합이 아직 일어나지 않았다는 뜻일 뿐입니다. 마지막으로 터널이 존재하는 이유인 리소스를 테스트하세요, 주소를 잃은 브리지는 VPN 자체가 건강해 보여도 벤더 경로를 끊을 수 있기 때문입니다.

풀 범위, 각 고정 주소, 그리고 그것을 가진 호스트를 서버 노트에 기록하세요. 그러면 다음 충돌은 반나절을 다시 들여 발견하는 대신 몇 분 만에 알아챌 수 있습니다.

관련 글