SSD Nodes Learn Hosting plans →
가이드 Matt Connor작성자 Matt Connor · 업데이트됨 2026-09-14

WireGuard 연결 후 홈 LAN 접속이 안 될 때 해결법

WireGuard 핸드셰이크는 성공하지만 내부망 호스트에 응답이 없는 문제를 해결합니다. 클라이언트 AllowedIPs, 서버 AllowedIPs, IP 포워딩 활성화, 그리고 라우팅 경로 설정 등 패킷이 목적지에 도달하기 위해 반드시 확인해야 할 4가지 필수 항목을 정리했습니다.

WireGuard를 통해 홈 LAN에 접속할 수 없는 이유

WireGuard를 통해 홈 LAN으로 라우팅하려면 4가지 설정이 모두 일치해야 합니다. 4가지 중 3가지만 설정되어도 터널은 정상적으로 작동하는 것처럼 보이기 때문에 이 문제가 혼란스럽게 느껴집니다. wg show는 최근 핸드셰이크 성공을 보고하고, ping 10.8.0.1는 몇 밀리초 만에 응답하지만, ping 192.168.20.10은 아무런 응답도 반환하지 않습니다.

패킷이 거치는 순서대로 전체 목록을 나열합니다. LAN은 홈 라우터 뒤에 있는 사설 네트워크인 근거리 통신망을 의미합니다.

  1. 클라이언트의 AllowedIPs은 원격 서브넷을 포함해야 합니다. 그렇지 않으면 패킷이 터널로 진입하지 못합니다.
  2. 서버의 AllowedIPs은 클라이언트의 터널 주소를 포함해야 합니다. 그렇지 않으면 패킷이 복호화되자마자 폐기됩니다.
  3. 서버의 net.ipv4.ip_forward는 1 상태여야 합니다. Linux는 서버 자신을 목적지로 하지 않는 모든 패킷을 폐기하기 때문입니다.
  4. LAN은 서버의 매스커레이드(masquerade) 규칙이나 홈 라우터의 정적 경로를 통해 10.8.0.0/24로 돌아가는 경로를 알고 있어야 합니다.

이 중 하나라도 실패하면 오류 메시지가 출력되지 않습니다. 로그도 남지 않고 경고도 없으며, 핸드셰이크는 계속 정상적으로 작동합니다. 순서대로 확인하면 약 1분 안에 문제가 발생한 지점을 찾을 수 있습니다.

이 가이드에서 사용하는 네트워크

아래의 모든 주소는 예시입니다. 본인의 환경에 맞게 수정하십시오. 설정 파일의 일부만 수정하면 문제가 발생할 가능성이 매우 높으므로, 모든 설정을 일관되게 변경해야 합니다.

  • 홈 LAN은 192.168.20.0/24입니다. 홈 라우터는 192.168.20.1입니다.
  • WireGuard 서버는 해당 LAN에 위치한 Linux 장비입니다. 서버의 LAN 인터페이스 enp1s0는 192.168.20.5를 사용하며, 터널 인터페이스 wg0은 10.8.0.1을 사용합니다.
  • 접근하려는 호스트는 192.168.20.10에 위치한 NAS(network attached storage)입니다.
  • 클라이언트는 외부 어딘가에 있는 노트북이며, 터널 내부 주소는 10.8.0.2입니다.

서버는 라우터 자체가 아닌 LAN 내부의 장비입니다. 이는 Raspberry Pi나 구형 미니 PC를 사용하는 일반적인 경우입니다. 이 점은 규칙 4에서 중요하게 작용합니다. 라우터에 알리지 않으면 라우터는 터널의 존재를 알 수 없으며, LAN의 모든 호스트는 서브넷 외부로 나가는 트래픽을 라우터로 보냅니다.

가정용 인터넷 연결에 공인 IP 주소가 없다면 이 방식은 단독으로 작동하지 않습니다. 인터넷상의 어떤 장치도 귀하의 집으로 핸드셰이크를 시도할 수 없기 때문입니다. 이 경우 VPS를 중간에 배치하는 섹션을 참조하십시오. 동일한 네 가지 규칙이 적용되며, 관리해야 할 피어(peer)가 하나 더 추가됩니다.

AllowedIPs는 두 가지 의미를 가집니다

하나의 설정이 두 가지 역할을 수행하며, 양쪽 끝에서 이를 동일하게 해석하는 것이 대부분의 관련 문의가 발생하는 원인입니다. WireGuard는 이 메커니즘을 cryptokey routing이라 부르며, 이에 대한 자세한 내용은 WireGuard가 공개 키를 IP 대역에 바인딩하는 방식에서 설명합니다.

아웃바운드 관점에서 읽을 때, AllowedIPs은 라우팅 테이블입니다. wg-quick은 각 항목을 wg0를 가리키는 경로로 변환합니다. 192.168.20.10으로 향하는 패킷은 특정 피어가 해당 주소를 포함하는 대역을 주장할 때만 암호화되어 해당 피어에게 전송됩니다. 10.8.0.0/24만 나열하면 노트북은 LAN 트래픽을 로컬 Wi-Fi를 통해 외부로 내보내게 되며, 이 트래픽은 소멸하거나 완전히 다른 192.168.20.10에 도달하게 됩니다.

인바운드 관점에서 읽을 때, AllowedIPs은 접근 제어 목록(ACL)입니다. WireGuard가 피어로부터 받은 패킷을 복호화한 후, 내부 소스 주소가 해당 피어의 AllowedIPs과 일치하는지 확인하고 일치하지 않으면 패킷을 폐기합니다. 이 폐기 동작에 대한 로그나 카운터는 존재하지 않습니다. 패킷은 단순히 사라집니다.

따라서 두 설정 파일은 결코 서로 대칭적인 형태가 아닙니다. 클라이언트는 서버를 통해 도달하고자 하는 대상을 나열합니다. 서버는 해당 클라이언트가 소스 주소로 사용할 수 있도록 허용된 대상을 나열합니다.

일치하는 설정 파일 쌍

클라이언트, /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <laptop private key>
Address = 10.8.0.2/32

[Peer]
PublicKey = <server public key>
Endpoint = home.example.com:51820
AllowedIPs = 10.8.0.0/24, 192.168.20.0/24
PersistentKeepalive = 25

서버, /etc/wireguard/wg0.conf:

[Interface]
PrivateKey = <server private key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <laptop public key>
AllowedIPs = 10.8.0.2/32

가정용 라우터에서도 UDP 51820 포트를 192.168.20.5으로 포트 포워딩해야 합니다. 그렇지 않으면 핸드셰이크가 시작되지 않으며 클라이언트 로그에 Handshake for peer 1 did not complete after 5 seconds, retrying이 기록됩니다. 이 가이드는 해당 단계를 이미 완료했다고 가정합니다.

일반적인 풀 터널 설정과 다른 네 줄이 있으며, 각 줄은 의도적으로 작성되었습니다.

  • 클라이언트의 AllowedIPs = 10.8.0.0/24, 192.168.20.0/24는 0.0.0.0/0, ::/0을 대신합니다. 이는 스플릿 터널입니다. 터널 서브넷과 홈 LAN은 wg0를 통과하며, 그 외의 모든 트래픽은 기존 로컬 경로를 유지합니다. NAS만 필요한 경우라면 보통 웹 브라우징 트래픽을 홈 네트워크로 보내지 않는 것이 좋습니다.
  • 서버의 AllowedIPs = 10.8.0.2/32는 범위가 아닌 단일 주소입니다. 여기에 10.8.0.0/24을 작성하면 해당 클라이언트가 터널 내부의 어떤 주소든 점유할 수 있게 됩니다. 나중에 범위가 겹치는 두 번째 피어를 추가하면, 오류 메시지 없이 마지막으로 설정된 피어로 트래픽이 전달됩니다.
  • 클라이언트에만 설정된 PersistentKeepalive = 25입니다. 클라이언트는 NAT(네트워크 주소 변환) 뒤에 위치하며, 라우터는 일정 시간 동안 통신이 없으면 UDP 매핑을 삭제하므로 서버가 클라이언트에 도달할 수 없게 됩니다. 서버는 공인 주소를 사용하므로 keepalive가 필요하지 않습니다.
  • 아직 DNS = 줄은 없습니다. 이를 추가하면 클라이언트 전체 시스템의 이름 해석 방식이 변경됩니다. 아래 DNS 섹션에서 이 설정을 활성화하기 전에 수행하는 작업에 대해 설명합니다.

풀 터널 역시 0.0.0.0/0가 모든 주소와 일치하므로 LAN에 도달할 수 있습니다. 하지만 모든 트래픽을 소모하게 되며, 클라이언트 측에서 해결할 수 없는 서브넷 충돌이 발생할 수 있습니다.

양쪽 끝의 서브넷이 동일할 때 문제가 발생하는 이유

다른 사람이 거의 사용하지 않는 홈 서브넷(예: 192.168.20.0/24 또는 10.44.7.0/24)을 선택하십시오. 192.168.1.0/24와 192.168.0.0/24은 대부분의 소비자용 라우터에서 공장 초기값으로 설정되어 있으므로, 언젠가는 카페나 호텔 네트워크에서 노트북이 정확히 해당 대역을 할당받게 됩니다.

이러한 충돌은 치명적인 문제이며, 두 가지 경우에 따라 증상이 다르게 나타납니다. 스플릿 터널(split tunnel) 환경에서는 wg-quick가 이미 Wi-Fi 인터페이스에 존재하는 프리픽스에 대한 경로를 추가하려고 시도하지만, ip route add가 이를 거부하여 인터페이스가 활성화되지 않습니다.

RTNETLINK answers: File exists

풀 터널(full tunnel) 환경에서는 wg-quick이 메인 테이블의 더 구체적인 경로를 의도적으로 배제하는 정책 라우팅 규칙을 설치합니다. 로컬 192.168.1.0/24 경로가 터널보다 우선순위를 가지므로, 원격 LAN으로 향하는 모든 패킷이 로컬 링크를 통해 전송됩니다. 터널은 정상적으로 연결되고 핸드셰이크도 성공하지만, NAS에는 접근할 수 없습니다. 홈 LAN의 IP 대역을 변경하는 것이 유일한 근본적인 해결책입니다.

서버를 라우터로 전환하기

ip route show default
printf 'net.ipv4.ip_forward = 1\n' | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

첫 번째 명령은 LAN 인터페이스의 실제 이름을 알려줍니다. 현재 이미지들은 enp1s0이나 ens3 같은 이름을 사용하며, eth0은 드물게 사용됩니다. 잘못된 인터페이스 이름을 지정한 매스커레이드(masquerade) 규칙은 아무것도 일치시키지 못합니다. 마지막 명령은 net.ipv4.ip_forward = 1을 출력해야 합니다. 단순히 sudo sysctl -w를 실행해도 같은 값이 설정되지만, 재부팅 후에는 사라지므로 "화요일까지는 잘 작동했다"는 식의 전형적인 문제 보고가 발생합니다.

포워딩 설정은 방화벽 정책도 통과해야 합니다. ufw가 활성화된 Ubuntu 환경에서는 /etc/default/ufw 파일 내의 DEFAULT_FORWARD_POLICY="ACCEPT" 설정이 되어 있지 않으면 포워딩된 패킷이 차단됩니다. Docker는 자체적으로 동일한 정책을 설정하므로, 수동으로 방화벽을 설정한 적이 없는 서버에서 sudo iptables -S FORWARD | head -1 명령이 -P FORWARD DROP을 출력한다면 이는 Docker가 설정한 것입니다. 이 경우 터널 트래픽을 허용하는 명시적인 규칙을 추가해야 합니다.

응답이 돌아오지 않는 이유

규칙 1에서 3까지 올바르게 설정하면 ping은 실제로 NAS에 도달합니다. 하지만 응답이 돌아올 경로가 없기 때문에 여전히 아무것도 볼 수 없습니다. NAS는 자신의 서브넷 외부 주소인 10.8.0.2로 응답을 보내려 하므로, 패킷을 기본 게이트웨이인 192.168.20.1의 홈 라우터로 전달합니다. 해당 라우터는 10.8.0.0/24에 대해 알지 못하므로 응답을 자신의 기본 게이트웨이인 인터넷 연결로 전달하고, 그곳에서 패킷은 폐기됩니다. 요청은 도착하지만 응답은 버려지는 것입니다.

옵션 A: WireGuard 서버에서 masquerade 사용. 서버는 전달되는 모든 패킷의 출발지 주소를 자신의 LAN 주소인 192.168.20.5으로 다시 씁니다. 이제 NAS는 같은 서브넷에 있는 이웃으로부터 온 요청으로 인식하여 서버에 직접 응답을 보내고, 서버는 다시 쓰기를 되돌려 터널을 통해 응답을 보냅니다. LAN의 다른 설정은 변경할 필요가 없습니다.

서버의 [Interface] 블록에 규칙을 추가하여 인터페이스와 함께 규칙이 생성되고 삭제되도록 합니다.

PostUp = iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o enp1s0 -j MASQUERADE

이미 nftables로 관리되는 시스템이라면 /etc/nftables.conf에 작성하십시오.

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "enp1s0" counter masquerade
  }
}

counter 키워드를 유지하십시오. 이 키워드가 없으면 sudo nft list ruleset는 패킷 카운트 없이 규칙을 출력하며, 해당 카운트는 규칙이 실제로 사용되고 있는지 확인하는 핵심 지표입니다.

Masquerade는 간과하기 쉬운 두 번째 이점을 제공합니다. 많은 호스트가 자신의 서브넷에서 오는 연결만 허용하는 방화벽을 실행합니다. Windows 파일 공유가 기본적으로 이렇게 동작하며, 여러 NAS 관리 패널도 마찬가지입니다. 10.8.0.2에서 온 패킷은 라우팅이 완벽하더라도 대상 호스트에 의해 차단됩니다. Masquerade를 거치면 출발지가 LAN 주소가 되므로 이러한 규칙을 통과할 수 있습니다. 단점은 모든 LAN 호스트의 로그에서 모든 터널 클라이언트가 192.168.20.5으로 표시되므로 클라이언트를 구분할 수 없으며, LAN 장치에서 클라이언트별 규칙을 적용할 수 없다는 점입니다.

옵션 B: 홈 라우터에 정적 경로(static route) 추가. 라우터에 10.8.0.0/24이 192.168.20.5 뒤에 있다고 알려줍니다. Linux 라우터에서는 다음 명령 하나로 가능합니다.

sudo ip route add 10.8.0.0/24 via 192.168.20.5

일반 가정용 라우터는 고급 설정 내에 '정적 경로(Static Routes)' 또는 '라우팅(Routing)'이라는 페이지를 제공합니다. 대상(destination) 10.8.0.0, 마스크(mask) 255.255.255.0, 게이트웨이(gateway) 192.168.20.5를 입력하십시오. Linux 장비에서 입력한 ip route add는 재부팅 시 사라지므로 라우터의 저장된 설정에 반드시 저장해야 합니다.

이 방식은 실제 클라이언트 주소를 유지하므로 LAN의 로그와 클라이언트별 규칙을 그대로 사용할 수 있습니다. 단, 정적 경로를 지원하는 라우터가 필요하며, 해당 라우터를 기본 게이트웨이로 사용하는 호스트에만 유효합니다. 서브넷 범위의 로컬 방화벽을 사용하는 호스트는 여전히 10.8.0.0/24에 대한 자체 규칙이 필요합니다. 이미 제어 가능한 장비 외에 추가 설정이 필요 없는 masquerade로 시작하고, 실제 클라이언트 주소가 필요한 경우 정적 경로로 전환하십시오.

네 가지 요소 중 무엇이 잘못되었는지 확인하는 방법

클라이언트에서 시작하여 외부로 단계별로 확인하십시오. 각 단계는 패킷이 해당 지점까지 도달했는지 알려줍니다.

패킷이 터널로 진입합니까? 클라이언트에서 다음을 실행합니다:

ip route get 192.168.20.10

결과에는 dev wg0가 표시되어야 합니다. 만약 Wi-Fi 인터페이스가 표시된다면 규칙 1이 잘못된 것이며, 클라이언트의 AllowedIPs가 LAN 서브넷을 포함하지 않는 상태입니다. ping: connect: Network is unreachable도 같은 줄을 가리킵니다.

패킷이 서버에 도착합니까? 서버에서 다음을 실행한 뒤, 클라이언트에서 NAS로 ping을 보냅니다:

sudo tcpdump -ni wg0 icmp

정상적인 경로라면 IP 10.8.0.2 > 192.168.20.10: ICMP echo request이 표시됩니다. 여기서 ICMP는 ping이 사용하는 인터넷 제어 메시지 프로토콜입니다. 핸드셰이크는 정상인데 아무런 반응이 없다면 규칙 2의 문제입니다. 서버의 해당 피어에 대한 AllowedIPs에 10.8.0.2이 포함되어 있지 않아, 패킷이 wg0에 도달하기 전 복호화 단계에서 폐기된 것입니다.

패킷이 LAN으로 나갑니까? 서버에서 LAN 쪽 인터페이스를 모니터링합니다:

sudo tcpdump -ni enp1s0 icmp

wg0에서는 요청이 보이지만 여기서 아무것도 보이지 않는다면 규칙 3의 문제입니다. 포워딩이 꺼져 있거나 FORWARD 규칙에 의해 패킷이 폐기된 것입니다. 여기서 소스 10.8.0.2으로 요청은 보이지만 응답이 없다면 규칙 4의 문제입니다. 즉, 응답이 돌아올 경로가 없는 상태입니다. 여기서 소스 192.168.20.5로 요청은 보이지만 응답이 없다면 마스커레이드 규칙은 정상 작동 중이나 대상 호스트 자체가 거부하는 것이므로 NAS의 방화벽을 확인하십시오. icmp를 port 445이나 확인하려는 다른 포트로 바꾸면 동일한 방식으로 다른 서비스도 점검할 수 있습니다.

IP 주소는 접속되지만 도메인 이름은 접속되지 않습니다

ssh 192.168.20.10은 작동하지만 ssh nas.home.arpa은 실패합니다:

ssh: Could not resolve hostname nas.home.arpa: Name or service not known

터널에는 아무런 문제가 없습니다. 이름 해석은 별도의 경로를 따르며, 사용자의 노트북은 여전히 로컬 Wi-Fi에서 학습한 리졸버(resolver)에 질의를 보내고 있기 때문입니다. 해당 리졸버는 사용자의 홈 네트워크에 있는 도메인 이름을 알지 못합니다.

홈 네트워크의 도메인 이름이 작동하려면 두 가지 조건이 충족되어야 합니다. 첫째, 리졸버의 주소가 클라이언트의 AllowedIPs 내부에 위치해야 합니다. 그렇지 않으면 DNS(domain name system) 질의가 터널로 진입하지 않습니다. 둘째, 리졸버가 10.8.0.2인 소스 주소로부터 오는 질의에 응답할 수 있어야 합니다. 많은 홈 리졸버는 기본적으로 이를 거부합니다. 예를 들어 local-service 옵션으로 실행되는 dnsmasq은 직접 연결된 서브넷에서 오는 질의에만 응답하며, Pi-hole은 로컬 요청만 허용하는 리스닝 모드로 배포됩니다. 마스커레이드(masquerade) 규칙을 사용하면 이 문제가 가려지는데, 주소 재작성(rewrite) 과정을 거치면 질의가 192.168.20.5에서 오는 것처럼 보이기 때문입니다.

클라이언트 측 설정은 한 줄로 가능합니다:

DNS = 192.168.20.1

openresolv 또는 그에 상응하는 도구가 필요한 Linux 클라이언트에서는 이 설정을 해야 합니다. 그렇지 않으면 wg-quick가 resolvconf: command not found 오류와 함께 중단됩니다. systemd-resolved를 사용하는 시스템에서 이 설정을 적용하기 전에 그 영향을 파악하십시오. wg-quick은 해당 서버들을 전용 리졸버로 등록하므로, 터널이 활성화된 동안 노트북의 모든 조회 요청은 홈 이름뿐만 아니라 모든 도메인에 대해 홈 리졸버로 전달됩니다. resolvectl status wg0 명령으로 결과를 확인하십시오. 홈 네트워크 이름은 홈 리졸버에서, 그 외의 이름은 로컬에서 해석하는 분할 DNS(split DNS)를 원하신다면 WireGuard 터널을 통한 DNS 설정 수정에서 전체 구성 방법을 다룹니다.

집에 공인 IP가 없습니까? 중간에 VPS를 두십시오

라우터의 상태 페이지에서 WAN 주소가 100.64.0.0/10 범위 내에 있거나 사설 192.168.x.x 주소로 표시된다면, 귀하는 CGNAT(통신사급 네트워크 주소 변환) 환경에 있는 것이며 외부 인터넷에서 들어오는 핸드셰이크는 가정 내로 도달할 수 없습니다. 외부로 나가는 핸드셰이크는 정상적으로 작동하므로, 공인 IP를 가진 제3의 노드를 사용하는 것이 해결책입니다. 소형 VPS를 허브로 운영하고, 가정용 장비가 그곳으로 연결을 시도하게 합니다.

네 가지 규칙은 변하지 않습니다. 이제 두 개의 홉(hop)에 걸쳐 적용되므로 관리해야 할 정보가 두 배로 늘어납니다.

  • VPS에서 가정용 장비의 피어 항목은 AllowedIPs = 10.8.0.3/32, 192.168.20.0/24을 가집니다. 즉, 자체 터널 주소와 해당 장비가 통신을 담당하는 서브넷을 포함합니다.
  • VPS에서 노트북의 피어 항목은 AllowedIPs = 10.8.0.2/32로 유지됩니다.
  • 노트북에서 VPS 피어는 AllowedIPs = 10.8.0.0/24, 192.168.20.0/24을 가집니다. 이제 모든 트래픽이 허브를 거쳐 가기 때문입니다.
  • 가정용 장비에서 VPS 피어는 AllowedIPs = 10.8.0.0/24를 가지며, 가정용 장비는 PersistentKeepalive = 25를 수행합니다. 이제 NAT 뒤에 있는 측이 되었기 때문입니다.
  • VPS 역시 net.ipv4.ip_forward = 1이 필요하며, 포워딩 체인은 wg0에서 wg0로의 통신을 허용해야 합니다. 노트북의 트래픽이 동일한 인터페이스로 들어와서 나가기 때문입니다. 일반적인 풀 터널 VPS용으로 작성된 방화벽은 정확히 이 흐름을 차단합니다.

아직 VPS 측 설정을 완료하지 않았다면, VPS에서 WireGuard 설정하기에서 키 생성, 방화벽, systemd 유닛에 관한 내용을 다룹니다. 들어오는 연결을 수락할 수 없는 장비에 접근하는 더 넓은 패턴은 CGNAT 뒤에서 리버스 터널 열기에 있습니다. 피어 주소를 수동으로 관리하는 것이 번거로워지면, Tailscale 서브넷 라우터 실행하기를 통해 주소 관리 자동화와 함께 동일한 라우팅 작업을 수행할 수 있습니다.

재부팅 후에도 유지되도록 설정하기

sudo systemctl enable --now wg-quick@wg0
sudo systemctl enable --now nftables
sudo wg show

enable --now는 많은 사용자가 간과하는 부분입니다. 수동으로 실행한 wg-quick up wg0은 커널 업그레이드나 재부팅 이후에는 사라집니다. wg show을 실행하면 최근 latest handshake 항목이 포함된 피어 목록과 양방향으로 0이 아닌 전송 카운터가 표시되어야 합니다.

나중에 두 번째 클라이언트를 추가할 때 재시작은 필요하지 않으며, 재시작을 수행하면 현재 연결된 모든 사용자의 연결이 끊어집니다.

sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

wg-quick strip은 wg-quick만 이해할 수 있는 키를 제외한 설정을 출력하며, syncconf는 라이브 세션을 유지한 채 변경 사항을 적용합니다. 이 명령은 피어 정보만 업데이트합니다. Address이 변경되거나 새로운 PostUp 항목이 추가된 경우에는 여전히 전체 인터페이스를 down한 뒤 up해야 합니다.

FAQ

WireGuard 서버에 ping은 가는데 홈 LAN의 다른 장비에는 왜 접속할 수 없습니까?

10.8.0.1에 ping이 간다는 것은 터널이 정상적으로 연결되었다는 의미일 뿐입니다. LAN의 나머지 장비에 접속하지 못하는 것은 라우팅 문제입니다. 클라이언트의 AllowedIPs 설정에 192.168.20.0/24이 포함되어 있어야 패킷이 터널로 진입합니다. 서버는 net.ipv4.ip_forward이 1로 설정되어 있어야 하며, 그렇지 않으면 서버 자신을 목적지로 하지 않는 패킷을 모두 폐기합니다. 또한 LAN 장비들은 10.8.0.0/24으로 돌아가는 경로를 알고 있어야 합니다. ping을 보내는 동안 서버에서 sudo tcpdump -ni enp1s0 icmp를 실행해 보십시오. 소스 주소가 10.8.0.2인 요청은 나가는데 응답이 돌아오지 않는다면, 반환 경로가 설정되지 않은 것입니다.

홈 라우터에 고정 경로(static route)를 추가해야 합니까?

masquerade 규칙을 사용하지 않을 때만 필요합니다. WireGuard 서버의 masquerade 규칙은 터널 트래픽의 소스 주소를 서버 자신의 LAN 주소로 재작성합니다. 따라서 LAN 호스트들은 이미 알고 있는 이웃 장비로부터 온 것으로 간주하여 응답하며, 라우터는 관여하지 않습니다. 대안으로 서버의 LAN 주소를 경유하는 10.8.0.0/24에 대한 고정 경로를 추가할 수 있습니다. LAN 호스트의 로그에 실제 클라이언트 주소를 남기거나 클라이언트별 방화벽 규칙을 적용하고 싶다면 이 방법이 유용합니다.

양쪽 끝의 서브넷이 같으면 왜 터널이 작동하지 않습니까?

노트북은 동일한 프리픽스에 대해 두 개의 경로를 가질 수 없습니다. 로컬 네트워크가 192.168.1.0/24을 할당하고 홈 LAN도 192.168.1.0/24인 경우, ip route add이 RTNETLINK answers: File exists 오류를 반환하면서 스플릿 터널 wg-quick up 설정이 실패합니다. 대신 풀 터널이 활성화되지만, wg-quick가 메인 테이블의 더 구체적인 경로를 차단하는 정책 규칙을 설치하므로 로컬 네트워크가 우선시되어 원격 LAN에 도달할 수 없게 됩니다. 홈 LAN의 대역을 192.168.20.0/24과 같이 흔하지 않은 대역으로 변경하십시오. 클라이언트 측에서 해결할 방법은 없습니다.

IP로는 NAS에 접속되는데 이름으로는 안 됩니다. 무엇이 문제입니까?

이름 해석(name resolution)은 자동으로 터널을 따라가지 않습니다. 클라이언트의 [Interface] 블록에 홈 네트워크의 DNS 해석기인 DNS = 192.168.20.1를 추가하십시오. 이때 해당 주소가 피어의 AllowedIPs 범위 내에 있어야 쿼리가 터널로 전달됩니다. 또한 해석기가 자신의 서브넷 외부에서 오는 쿼리에 응답하도록 설정되어 있는지 확인하십시오. dnsmasq의 local-service 설정이나 Pi-hole의 로컬 전용 수신 모드는 외부 쿼리를 거부하기 때문입니다. WireGuard 서버에 masquerade 규칙을 적용하여 쿼리의 소스 주소를 재작성하면 이 문제를 우회할 수 있습니다.

홈 인터넷 연결에 공인 IP가 없습니다. 그래도 LAN에 접속할 수 있습니까?

네, 제3의 노드를 사용하면 가능합니다. CGNAT 환경에서는 라우터의 WAN 주소가 사설 IP이므로 인터넷상의 다른 피어가 핸드셰이크를 시작할 수 없지만, 외부로 나가는 핸드셰이크는 정상적으로 작동합니다. 공인 IP를 가진 VPS에서 WireGuard를 실행하고, 홈 서버가 PersistentKeepalive = 25를 사용하여 VPS로 연결하게 하십시오. 그리고 VPS의 피어 설정에서 홈 서버의 항목에 터널 주소와 192.168.20.0/24을 포함한 AllowedIPs을 지정하십시오. 마지막으로 VPS에서 포워딩을 활성화하고 wg0에서 wg0으로의 트래픽을 허용하는 포워드 규칙을 추가해야 합니다.

#wireguard#routing#allowedips#vpn#linux-networking