RRAS VPN 클라이언트에는 전용 IPv4 풀과 돌아오는 경로가 필요합니다

VPN 클라이언트는 연결되어 주소를 받지만, 필요한 LAN 호스트는 여전히 응답할 수 없습니다. Windows Routing and Remote Access에서 VPN 클라이언트의 내부 주소는 서버의 LAN 어댑터와 별도로 구성된 풀에서 나오며, LAN 쪽에는 그 풀로 돌아가는 경로가 필요합니다. 두 가지 변경이며 하나가 아니고, 서로 다른 방식으로 실패합니다. 이전 범위를 폐기하기 전에 주소 계획과 돌아오는 경로가 입증되도록 순서대로 진행하십시오.

콘솔을 열기 전에 범위를 예약하십시오

LAN, 다른 VPN 범위, 사이트로 라우팅되는 어떤 것과도 겹치지 않는 접두사를 고르십시오. 테스트에는 /24가 편리한 크기이며, 처음 사용 가능한 부분을 클라이언트에 주고 나머지는 성장을 위해 비워 둘 수 있습니다. 콘솔에 입력하기 전에 목적과 소유자와 함께 기록하십시오. 나중의 분할이 재번호 부여를 강요하지 않도록 블록 양 끝에 여유를 두십시오.

콘솔 안에만 존재하는 주소 계획은 재구축 한 번이면 충돌에 이릅니다. 또한 커지는 경향이 있으며, 나중에 누군가 두 번째 범위를 추가하고 아무도 첫 번째를 확인하지 않습니다. 계획은 채팅 스레드가 아니라 서버 문서 옆에 두십시오.

서버의 LAN 어댑터는 이 풀을 정의하지 않습니다. 공용 수신기를 바꾸거나 LAN에 어댑터를 추가하는 것은 전혀 다른 일을 합니다. 그래서 클라이언트가 연결되어도 잘못된 위치에서 주소를 받을 수 있습니다. 풀은 서버의 IPv4 속성에 있으며 어댑터 목록에 있지 않습니다.

방식을 바꾸는 것은 범위를 추가하는 것이 아닙니다

RRAS에는 할당 방식과 범위 집합이 있습니다. DHCP에서 정적 풀로 전환은 방식 변경입니다. 정적 풀이 이미 활성인 상태에서 다른 블록을 추가하는 것은 범위 변경입니다.

둘 중 하나를 실행하기 전에 두 작업을 모두 미리 보고, 어느 것이 서버의 현재 상태와 맞는지 읽으십시오:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

서버가 아직 DHCP 할당이면 두 번째 cmdlet은 실패하거나 쓸 수 없는 풀을 만듭니다. 첫 번째는 기존 풀을 확장하는 대신 방식을 대체합니다. 어느 미리 보기도 아무것도 적용하지 않으므로 맞는 것을 실행한 다음 결과 풀을 콘솔에서 확인하십시오. 서버가 어떤 상태인지 확실하지 않으면 IPv4 속성 페이지에서 할당 방식을 읽고 구성된 범위를 나열하십시오:

Get-VpnIPAddressRange

범위 목록이 빈 DHCP 방식이면 첫 번째 미리 보기가 적용됩니다. 기존 범위가 있는 정적 주소 풀이면 두 번째가 적용됩니다.

설정에 필요할 수 있는 서비스 다시 시작을 고려하고, 연결된 클라이언트가 즉시 재번호 부여된다고 가정하지 마십시오. 다시 연결할 때까지 이전 주소를 유지하는 클라이언트는 정상적으로 동작합니다. 재연결이 허용되는 시간대에 변경을 계획하십시오.

LAN에는 돌아오는 경로가 필요합니다

LAN이 10.60.0.0/24이고 RRAS 서버가 그 위의 10.60.0.10이라고 가정하십시오. 그 LAN의 호스트가 10.250.50.0/24의 클라이언트에 응답하려면 RRAS 서버를 거쳐 풀로 가는 경로가 필요합니다. 그 경로가 없으면 요청은 도착하고 응답은 죽습니다.

호스트의 기본 게이트웨이가 다른 라우터라면 그 라우터에 VPN 접두사용 돌아오는 경로가 필요합니다. RRAS 서버의 정적 경로는 여기서 도움이 되지 않으며, 돌아오는 경로는 LAN 게이트웨이를 가진 장치에 있어야 하므로 사이트가 사용하는 방식에 따라 라우팅 테이블이나 동적 라우팅 프로세스에 추가하십시오.

새 원본 범위에 대해 호스트 방화벽과 모든 네트워크 액세스 규칙도 확인하십시오. 이전 클라이언트 범위용으로 작성된 규칙은 할당이 성공했더라도 새 범위를 거부합니다. 클라이언트의 LAN 방향 경로와 DNS 확인은 별개의 요구 사항이며, 터널이 정상으로 보여도 둘 다 실패할 수 있습니다. 각각을 따로 시험하십시오.

이전 풀을 폐기하기 전에 한 장치에서 새 풀을 입증하십시오

직접 제어하는 권한 부여를 하나 선택해 다시 연결하고 클라이언트가 받은 풀 주소를 읽으십시오. 그 하나의 숫자가 할당과 라우팅을 구분합니다. 그다음 이름 있는 애플리케이션을 실행하고 돌아오는 트래픽을 관찰하며 거부된 채로 남아야 할 목적지를 시험하십시오. 세 가지 관찰, 세 가지 서로 다른 실패 방식입니다.

이름 확인은 자체 시험이 필요합니다: IP로 접근하는 것은 동작해도 클라이언트의 DNS가 도달할 수 없는 리졸버를 가리킬 수 있습니다. LAN의 DNS 서버는 클라이언트에 그 서버로 가는 경로가 있고 서버가 새 범위의 질의를 받아들일 때만 도달할 수 있습니다. 풀이 옮겨질 때 흔히 놓치는 부분입니다.

이전 범위와 그 예외는 활성 세션과 유지 관리 절차를 고려한 뒤에만 폐기하십시오. 새 주소로 연결된 클라이언트는 할당을 입증할 뿐 액세스 정책을 입증하지 않습니다. 그 범위를 사용한 마지막 세션이 만료될 때까지 이전 범위를 문서로 남기십시오.

세 가지 관찰로 결과를 확인하십시오

승인에는 세 가지 사실이 필요합니다: 클라이언트가 새 풀의 주소를 가지고 있고, LAN 호스트가 그에게 도달해 응답을 받을 수 있으며, 거부된 목적지가 여전히 거부됩니다. 각각 자체 검사가 있으므로 실패는 할당, 라우팅 또는 정책을 가리킵니다. 그 순서대로 실행하십시오.

클라이언트에서 주소와 한 LAN 호스트로 가는 경로를 확인하십시오:

ipconfig | findstr /i "IPv4"
route print -4

LAN 호스트에서 한 번에 돌아오는 경로와 정책을 확인하십시오. ping은 실패하지만 애플리케이션은 동작한다면 빠진 부분은 경로가 아니라 ICMP 규칙일 가능성이 큽니다. 둘 다 실패하면 VPN을 편집하기 전에 호스트의 경로를 읽으십시오. 세 결과를 변경 티켓에 기록해 다음 사람이 증거에서 시작하게 하십시오.