WireGuard 리눅스에서: 터널, 경로 및 DNS 확인

WireGuard 클라이언트는 활성화된 wg0 인터페이스를 표시할 수 있지만 패킷은 일반 연결을 통해 계속 나갈 수 있습니다. 이 경우는 Debian 또는 Ubuntu에 구성 파일을 가져온 후 자주 발생합니다.

클라이언트를 수정하기 전에 인터페이스, 피어와의 연결 및 실제로 선택된 경로를 확인하십시오. 이 점검은 터널이 모든 트래픽을 전송하는지 아니면 내부 네트워크만 전송하는지를 표시합니다.

가져올 클라이언트와 이미 활성화된 터널 구별하기

WireGuard 파일에 기본 경로가 포함되어 있는 경우 로컬 콘솔이나 두 번째 SSH 세션을 열어두십시오. AllowedIPs = 0.0.0.0/0 줄은 wg-quick를 실행할 때 IPv4 트래픽이 터널을 통해 지나가게 할 수 있습니다. ::/0와 함께 사용하면 IPv6에도 동일한 원칙이 적용됩니다.

먼저 wg0가 이미 존재하는지 확인하십시오. 인터페이스가 있으면 파일을 교체하지 말고 wg-quick up를 다시 실행하지 마십시오. wg show 및 ip route get 명령어로 바로 이동하십시오.

ip link show wg0
sudo wg show wg0

만약 wg0가 없다면 인터페이스 이름과 관리자가 제공한 파일의 권한을 확인하십시오. 개인 키를 티켓, Git 저장소 또는 스크린샷에 복사하지 마십시오.

if sudo test -e /etc/wireguard/wg0.conf; then
  sudo cp -a /etc/wireguard/wg0.conf /etc/wireguard/wg0.conf.bak && sudo install -m 600 /chemin/client.conf /etc/wireguard/wg0.conf
else
  sudo install -m 600 /chemin/client.conf /etc/wireguard/wg0.conf
fi
sudo grep -E '^(Address|DNS|Endpoint|AllowedIPs)' /etc/wireguard/wg0.conf

grep 명령어는 키 없이 네트워크 매개변수를 다시 읽습니다. 특히 AllowedIPs를 확인하십시오. 10.44.0.0/24와 같은 범위는 보통 원격 네트워크를 가리킵니다. 0.0.0.0/0 경로는 SSH를 통해 서버에 연결되어 있는 경우 더 신중한 검토가 필요합니다.

파일이 기존 구성 파일을 대체해야 한다면, /etc/wireguard/ 밖의 이름으로 이전 파일을 보관하거나 관리 백업에 저장하십시오. 저는 원격 서버의 기본 경로를 변경하기보다는 VM 또는 클라이언트 콘솔에서 먼저 테스트하는 것을 선택하겠습니다.

WireGuard 실행 및 피어와의 교환 확인

만약 wg0가 없었다면, 이제 wg-quick를 사용하여 인터페이스를 활성화하고 검사가 끝날 때까지 여러분의 콘솔이나 두 번째 세션을 열어 두십시오. wg0에 할당된 주소는 원격 피어가 응답하고 있는 것을 확인하지 않습니다.

sudo wg-quick up wg0
ip -brief address show wg0
sudo wg show wg0

wg show wg0 출력에서 latest handshake 및 transfer 카운터를 확인하십시오. 원격 네트워크에 요청 후 최근 타임스탬프와 수신된 바이트가 피어가 응답하고 있음을 나타냅니다. 핸드셰이크가 없으면 엔드포인트, UDP 포트, 방화벽 또는 예상하는 피어에 맞지 않는 키를 의심해야 합니다. WireGuard 빠른 시작 문서에서 여기서 사용된 wg와 wg-quick 명령어를 설명합니다.

시험 중 교환을 모니터링하려면 아래 명령어를 다시 실행할 수 있습니다. 이 명령어는 진단 중 구성 변경을 방지합니다.

watch -n 2 'sudo wg show wg0 latest-handshakes transfer'

서버가 ICMP를 허용하는 경우 ping이 도움이 될 수 있지만 응답이 없다고 해서 터널이 실패하는 것은 아닙니다. 피어가 접근할 수 있도록 되었어야 하는 서비스로 테스트를 선호하십시오. 예를 들어 내부 DNS 또는 관리 애플리케이션입니다.

결론을 내리기 전에 선택된 경로 확인하기

ip route get를 사용하여 Linux가 패킷을 대상을 향해 보내기 위해 선택할 장치를 확인하십시오. 이 명령어는 어떤 트래픽도 전송하지 않습니다.

ip route get 10.44.0.10
ip route get 1.1.1.1

내부 리소스의 경우 첫 번째 출력은 AllowedIPs에 선언된 네트워크에 10.44.0.10가 속하는 경우 dev wg0를 언급해야 합니다. 두 번째 출력은 인터넷으로의 출력도 wg0를 통해 이루어지는지 아니면 일반 인터페이스를 유지하는지 표시합니다. 이러한 문서 예시 주소를 실제 네트워크 내 예상 목표로 바꾸십시오.

VPN이 내부 리졸버를 제공하는 경우, 해당 주소가 터널 문서에 있는 경우에만 직접 테스트하십시오. Linux가 이를 위해 wg0를 올바르게 선택하는 것이 중요합니다. dig 명령어가 없는 경우 Debian 또는 Ubuntu에 dnsutils를 설치하십시오:

ip route get 10.44.0.53
sudo apt install dnsutils
dig @10.44.0.53 intranet.exemple.lan
sudo wg show wg0 latest-handshakes transfer

첫 번째 명령어는 dev wg0를 표시해야 합니다. DNS 요청은 기대되는 응답을 반환하고 수신 또는 송신 트래픽을 진행해야 합니다. 경로가 wg0를 사용하지만 핸드셰이크가 없다면 클라이언트는 로컬 인터페이스로 패킷을 전송하지만 원격 피어에 도달하지 못하고 있는 것입니다.

테스트를 중지하고 wg-quick가 추가한 경로를 복원하려면 sudo wg-quick down wg0를 사용하십시오. 이 명령어는 NetworkManager 또는 systemd-networkd에서 다른 곳에 설정된 경로를 수정하지 않습니다. 단순히 이 터널을 위해 wg-quick가 설치한 인터페이스와 요소를 제거합니다.

유효한 WireGuard 터널은 세 가지 증거로 식별할 수 있습니다: 존재하는 인터페이스, 최근 핸드셰이크 및 기대되는 대상에 대해 wg0를 가리키는 경로. ip addr, IP 경로 및 dig에 대한 기사들은 문제가 단순한 터널을 넘어설 때 이러한 점검을 별도로 상세하게 설명합니다.