핸드셰이크는 되는데 인터넷이 안 될 때: Windows 11에서 먼저 고칠 것

Windows 11에서는 최근 핸드셰이크가 있는데도 브라우저가 아무것도 열지 못하는 일이 흔합니다. 핸드셰이크는 피어와의 UDP 교환이 끝났다는 것만 증명합니다. Windows가 넣은 경로, 사용하는 확인자, 그리고 출구가 무언가를 전달하는지에 대해서는 아무 말도 하지 않습니다.

네 가지 조건이 그 계층 중 어느 것이 실패했는지를 결정합니다. 순서대로 확인하면 몇 분이면 되지만, 키를 다시 쓰는 데는 더 오래 걸리고 아무것도 바뀌지 않습니다.

키를 건드리기 전에 계층을 정하십시오

세 목적지를 이 순서로 확인합니다. 터널 쪽 주소로 시작하고, 다음은 숫자로 된 공인 IP, 마지막은 호스트 이름입니다. 연쇄가 끊기는 지점이 계층의 이름입니다. 첫 단계에서 실패하면 라우팅, 두 번째는 전달이나 NAT, 세 번째는 이름 확인입니다.

이 순서가 방법의 전부입니다. DNS 결함을 고장 난 터널로 오진하는 것을 막아 주며, 여기서 가장 흔한 잘못된 방향입니다.

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

핸드셰이크 시각이 비어 있다면

핸드셰이크 시각이 비어 있으면 암호화된 교환은 끝난 적이 없습니다. 따라서 결함은 라우팅보다 앞에 있습니다. 먼저 엔드포인트 주소와 포트를 보고, 다음으로 네트워크가 UDP를 걸러 내는지 봅니다. WireGuard 트래픽을 버리는 호스팅 사업자가 정확히 이 일을 만들고, 오래된 프로필에서 엔드포인트를 복사한 클라이언트도 마찬가지입니다.

나가는 바이트는 있는데 들어오는 바이트가 없는 것은 다른 경우입니다. 이는 NAT나 트래픽을 엉뚱한 곳으로 돌려보내는 방화벽을 가리킵니다.

경로가 물리 어댑터에 밀린다면

전체 터널이라면 피어 구간이 사용할 목적지를 모두 덮어야 합니다. Windows는 모든 목적지를 덮는 규칙을 두고도 물리 어댑터의 기본 경로를 남겨 두는 경우가 있습니다. 그 규칙을 0.0.0.0/1과 128.0.0.0/1로 나누면 조회에서 이기는 더 구체적인 두 접두사가 생깁니다. 이 분할은 문서화된 우회 방법이며 선호가 아닙니다.

route print이나 공인 주소 조회로 확인하십시오. 선택된 인터페이스는 터널 어댑터여야 합니다. 물리 어댑터가 여전히 이기면 서버를 건드리기 전에 피어 범위를 고치십시오.

주소는 되고 이름이 실패한다면

WireGuard는 IP 패킷을 나를 뿐 DNS에 대한 의견은 없습니다. 인터페이스 구간에 DNS = 줄을 넣거나 Windows에서 어댑터를 설정하십시오. 그것이 없으면 주소로 하는 핑은 성공하지만 모든 호스트 이름이 실패하고, 사용자는 이를 인터넷 없음으로 보고합니다.

연결 후 Windows가 실제로 쓰는 서버를 확인하십시오. 물리 어댑터에 남은 확인자는 일부 이름만 풀리는 부분 실패를 설명합니다. 두 번째를 위에 더하지 말고 그것을 지우십시오.

Windows 컴퓨터가 출구라면

Internet Connection Sharing은 켜져 있을 때 주소 지정을 다시 쓰므로 공유 어댑터가 다른 범위로 옮겨질 수 있습니다. 원래 주소를 계속 가리키는 클라이언트는 그러면 동작을 멈춥니다. 레지스트리 값 ScopeAddress와 StandaloneDHCPAddress이 그 범위를 제어하며, 재부팅 후 설정이 되돌아갈 수 있습니다.

Windows에 특유한 충돌 두 가지를 더 볼 만합니다. Routing and Remote Access 서비스가 터널을 방해할 수 있습니다. 잘못된 아키텍처용으로 만든 설치 프로그램은 아키텍처를 언급조차 하지 않는 메시지와 함께 실패합니다.

테스트가 지목한 계층을 고친 뒤 같은 세 목적지를 다시 실행하십시오. 호스트 이름 테스트는 고치지만 터널 주소를 깨뜨리는 변경은 잘못된 계층에 적용된 것입니다.