인터페이스 인덱스에 고정된 VPN 경로는 재연결 시 깨진다

어댑터 번호에 묶인 경로는 그 번호가 바뀌면 죽는다. 저장소를 확인하고, 접두사를 프로필에 묶은 다음, 새로운 순서로 다시 연결하라.

경로는 몇 주 동안 잘 동작했는데, 목적지는 그대로이고 아무것도 편집하지 않았는데도 갑자기 트래픽을 어디로도 보내지 않기 시작했다. 바뀐 것은 번호다: 특정 인터페이스 인덱스를 기준으로 만든 경로는 재연결 후 더 이상 존재하지 않는 어댑터를 가리키고, 목적지 접두사는 교체된 배관을 계속 가리킨다. 그 명령에 영속성을 더해도 소용이 없다: 문제는 경로가 재부팅을 견디느냐가 아니었기 때문이다. 해결책은 의도를 연결에 붙이는 것이며, 연결은 설계상 어댑터 교체를 견딘다.

경로가 실제로 무엇을 가리키는지 확인하라

경로 항목과 어댑터를 나란히 읽는 것으로 시작하라. VPN 인터페이스에 다음 홉이 있고 현재 어떤 어댑터와도 일치하지 않는 인덱스를 가진 경로가 이 장애의 특징이며, 다른 인덱스에 있는 같은 접두사는 잔재이거나 실제로 원하는 경로다. 둘 중 하나를 바꾸기 전에 두 목록을 모두 읽어라: 흥미로운 비교는 경로 안의 번호와 지금 존재하는 번호 사이에 있기 때문이다. 경로의 인덱스가 어댑터 목록에 있으면 인덱스는 문제가 아니며 조사는 메트릭, 정책 또는 원격 끝으로 옮겨간다. 없다면 경로는 더 이상 존재하지 않는 배관에 붙어 있으므로 더 진단할 것이 없다.

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

Store 열은 재부팅을 넘어 유지되는 항목과 어댑터와 함께 사라지는 항목을 구분한다. 그 차이가 내일 장애가 다시 나타날지를 결정하며, 사라진 인덱스를 가리키는 영구 저장소의 항목은 재부팅을 견디면서도 어떤 것과도 결코 일치하지 않으므로 최악의 경우다.

접두사를 어댑터가 아니라 프로필에 묶어라

Windows 기본 VPN은 자체 경로 목록을 실을 수 있으므로 연결이 올라올 때마다 올바른 어댑터를 다시 사용한다. 그러면 경로는 한 번 관찰한 번호가 아니라 프로필을 따르며, 전화를 걸 때마다 스크립트가 인덱스를 추측할 필요도 없다. 접두사 추가는 대응하는 제거 명령으로 되돌릴 수 있어 변경이 감사 가능하게 유지된다. 접두사는 시작 스크립트가 아니라 연결과 함께 저장되므로 다른 사용자에게 복사한 프로필이 의도를 함께 가져간다.

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

Add-VpnConnectionRoute 참조는 연결과의 연관을 문서화하며, 사용자별 프로필과 모든 사용자 프로필이라는 전화번호부 범위가 중요하다. 이 메커니즘은 Windows 자체 VPN 클라이언트에 속하므로 자체 서비스가 관리하는 공급업체 어댑터는 전혀 다른 정책 원본에서 경로를 가져올 수 있다.

새 경로를 추가하기 전에 오래된 경로를 정리하라

같은 접두사에 소유자가 다른 경로 두 개는 누가 이길지가 아무도 기록하지 않은 메트릭에 달려 있으므로 잘못된 경로 하나보다 나쁘다. 접두사에 이미 무엇이 있는지 영구 저장소 항목까지 포함해 살펴보고, 실패한 시도에 속한 것만 제거하라. 이전 설계의 잔재는 이 영역에서 흔한데, 실패하는 경로가 보통 작동하던 무언가를 대체했기 때문이다. 무엇이든 제거하기 전에 어느 항목이 어느 연결에 속하는지 적고, 목록을 변경 기록에 남겨라.

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

접두사, 다음 홉, 저장소, 소유자를 함께 맞춰 보되, 비슷해 보이는 것을 모두 지우지 말라. 다른 연결이 그 공간의 일부에 정당하게 의존할 수 있고, 광범위한 삭제는 정돈된 수리를 지원 사건으로 바꾼다.

다른 순서로 다시 연결하라

첫 시도가 대표적이었기를 바라지 말고 조건을 재현하라. 연결을 끊고 다시 연결한 뒤 터널이 올라온 상태에서 같은 원격 리소스로의 선택 경로를 확인하고, 여러 VPN이 관련되면 다른 순서로 올려 선택 경로가 바뀌는지 지켜보라. 순서는 대부분이 건너뛰는 변수이며, 잘못된 연결에 붙은 경로를 드러내는 것도 바로 이것이다.

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

원하는 결과는 어댑터가 번호를 한 번 유지하는 것이 아니다. 연결이 받는 어떤 번호로든 경로가 매번 나타나고, 연결이 닫히면 사라지는 것이다. 두 번 다시 연결하는 것이 그 결과들을 구분하는 가장 싼 방법이다.

경로가 할 수 없는 일을 알아라

프로필 경로는 경로 하나를 제공할 뿐이며, 원격 방화벽을 열지 않고, 원격 끝에 반환 경로를 만들지 않으며, 같은 주소 범위를 쓰는 두 사이트를 해결하지 않는다. 이들 각각은 별도의 소유자가 있는 별도의 구성이다. 따라서 경로 확인은 인수 테스트의 시작이며 전부가 아니다.

접두사 목록을 프로필과 함께 두고 어떤 범위에서 추가되었는지 적어라. 그러면 다음 사람이 경로 테이블에서 추론하는 대신 의도된 설계를 읽을 수 있고, 누군가의 기억에만 있는 경로가 다음 재연결 후 잘못 재구성된다. 배포 노트의 한 줄 주석은 반나절의 재발견보다 싸다.

관련 글