Windows는 터널을 연결됨으로 표시하고 인터넷 액세스 없음이라는 레이블을 붙이는데, 사람들은 이를 Windows의 특이점으로 읽습니다. 이것은 클라이언트가 무엇을 받았는지에 대한 진술입니다. 쓸 수 있는 기본 게이트웨이가 없거나, 작동하는 확인자가 없거나, 터널 안 주소로 돌아갈 경로가 없는 것입니다. 서버가 Windows Incoming Connection일 때는 한 가지 설정으로 이런 보고의 대부분이 설명됩니다. 레이블은 진단이 아니지만 검색 범위를 세 곳으로 좁힙니다.

바꾸기 전에 임대를 읽으십시오

클라이언트에서 ipconfig /all을 실행하고 항목 중에서 VPN 어댑터를 찾으십시오. 그것이 나열하는 주소, 기본 게이트웨이, DNS 서버가 필요한 사실이며, 관리자가 배포되었다고 가정하는 것과 자주 다릅니다.

세 가지 패턴이 세 가지 결함에 대응합니다. 169.254.0.0/16의 주소는 클라이언트가 아무것도 받지 못하고 스스로 링크 로컬 주소를 부여했다는 뜻입니다. 그럴듯한 주소에 게이트웨이가 없으면 클라이언트에 기본 경로를 주는 옵션 없이 풀이 제공되었다는 뜻입니다. 완전한 임대인데도 아무 곳에 닿지 못하면 서버 측 전달이나 변환을 가리킵니다.

서버를 건드리기 전에 값을 적어 두십시오. 다음 단계에서 서버가 배포한다고 생각하는 범위와 비교합니다. 기억은 임대의 좋은 대체물이 아닙니다.

자동 할당이 게이트웨이를 남기지 못하는 이유

Incoming Connections 항목에는 실제 어댑터와 별도로 자체 IPv4 속성이 있습니다. 그곳의 기본값은 주소 자동 할당을 제공하며, 주소, 마스크, 게이트웨이, DNS를 공급하기 위해 연결의 내장 할당자에 의존합니다.

독립 실행형 워크스테이션에서는 컴퓨터의 다른 무엇인가가 하나를 제공하지 않는 한 그 할당자가 끌어올 범위가 없으므로, 클라이언트는 링크 로컬 주소로 끝나거나 주소는 있지만 게이트웨이가 없을 수 있습니다. 링크가 올라왔기 때문에 연결은 설정된 것처럼 보이지만 그 뒤의 구성은 불완전합니다.

그래서 지정된 범위로 전환하면 이런 보고가 많이 고쳐집니다. 실행 중이 아닐 수도 있는 서비스에 임대를 지어내 달라고 요청하는 것을 멈추고 직접 임대를 말하기 시작합니다.

같은 혼란이 LAN 라우터의 DHCP 서버가 터널 클라이언트를 서비스할 것이라고 기대할 때 나타납니다. 브로드캐스트 검색은 라우팅된 터널을 넘지 않으므로 그 서버는 요청을 절대 보지 못합니다. 반대로 가정하는 것이 아무것도 묻지 않은 클라이언트 때문에 풀이 비난받는 가장 흔한 이유입니다.

서버가 라우팅할 수 있는 명시적 범위를 설정하십시오

서버가 도달할 수 있는 서브넷 안에서, LAN 라우터가 배포하는 범위 밖이고 네트워크의 다른 풀 밖인 작은 블록을 고르십시오. 서버가 172.20.10.0/24에 있고 라우터가 172.20.10.1을 가지고 있다면, 그 서브넷 상단 근처의 짧은 블록, 예를 들어 172.20.10.201에서 172.20.10.209까지가 터널 임대를 라우터가 이미 관리하는 배포에서 떨어뜨려 둡니다.

Incoming Connection의 IPv4 속성에 입력하고, 클라이언트를 다시 연결하고, 다른 것을 바꾸기 전에 어댑터를 다시 읽으십시오. 두 번째 읽기가 풀이 결함이었는지 아니면 여러 결함 중 하나였는지를 알려줍니다.

이 명령들은 결과 구성과 클라이언트가 지금 가진 경로를 출력합니다:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

임대의 게이트웨이는 서버가 가진 주소여야 하고, 클라이언트의 기본 경로는 그것을 가리켜야 합니다. 임대가 완전한데 경로가 없으면 서버가 게이트웨이를 밀어 넣지 않고 할당한 것이며, 풀 설정이 여전히 살펴볼 곳입니다.

주소는 인터넷 경로가 아닙니다

임대를 받는 것은 패킷을 클라이언트에서 서버로 옮길 뿐입니다. 인터넷 액세스를 위해서는 서버가 그 패킷을 전달하고 자체 업링크 쪽으로 변환해야 하며, 그것은 자체 실패 모드를 가진 별도의 구성입니다.

Internet Connection Sharing이 지름길입니다. 인터넷 쪽 어댑터를 공유 게이트웨이로 바꾸고 자체 주소 지정을 실행하는데, 그것은 그 어댑터의 주소를 다시 쓸 수 있고 기존 NAT 규칙이 더 이상 존재하지 않는 값을 가리키게 남길 수 있습니다. 활성화하기 전에 원래 설정을 기록하십시오.

라우팅 방식은 주소 지정을 안정적으로 유지하고 전달과 변환을 명시적으로 구성하라고 요구합니다. 어느 접근도 틀리지 않았습니다. 둘을 반쯤 섞으면 임대는 있고 출구는 없는 터널이 생기는데, 그것이 바로 처음의 증상입니다. 한 모델을 골라 다른 것을 더하기 전에 끝내십시오.

먼저 바깥 경로를 배제하십시오

터널이 형성되지 않으면 어떤 풀도 도움이 되지 않습니다. 프로토콜이 경로가 실어야 할 것을 결정합니다. PPTP는 TCP 1723과 GRE를 원하는데 GRE는 포트가 아니라 IP 프로토콜 47입니다. L2TP/IPsec은 UDP 1701과 500, 4500을 원합니다. SSTP는 TCP 443을 원합니다.

포트는 전달하지만 프로토콜은 전달하지 않는 라우터는 절대 인증되지 않는 연결 시도를 만듭니다. 그것은 터널이 형성된 뒤 아무 곳에 닿지 못하는 경우와 다른 실패이며, 둘을 함께 디버그해서는 안 됩니다.

같은 LAN과 원격 네트워크에서 시험하십시오. LAN 시도가 통하고 원격이 인증에 도달하지 못하면 바깥 경로가 문제입니다. 둘 다 인증되고 원격 클라이언트만 인터넷이 없으면 풀과 출구로 돌아가십시오.

관련 글