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

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에 도달하게 됩니다. 만약 경로가 패킷을 wg0로 보냈음에도 어떤 피어도 해당 주소를 주장하지 않는다면, 커널은 패킷을 폐기하고 수신 오류가 아닌 wg0의 전송 오류 카운트를 증가시킵니다.

인바운드 관점에서 AllowedIPs은 접근 제어 목록(ACL)입니다. WireGuard가 피어로부터 받은 패킷을 복호화한 후, 내부 소스 주소가 해당 피어의 AllowedIPs와 일치하는지 확인하고 일치하지 않으면 패킷을 폐기합니다. 커널 디버그 메시지가 활성화되지 않은 경우 아무런 로그도 남지 않습니다. 유일한 흔적은 ip -s link show wg0가 출력하는 wg0의 수신 오류 카운트뿐이며, 패킷은 단순히 사라집니다.

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

일치하는 설정 파일 쌍

클라이언트, /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 (203.0.113.7:51820) did not complete after 5 seconds, retrying (try 2)가 기록됩니다. 이 가이드는 해당 단계를 이미 완료했다고 가정합니다.

일반적인 풀 터널 설정과 비교하면 4개의 줄이 다르며, 각 줄은 의도적으로 작성되었습니다.

  • 클라이언트의 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

NetworkManager로 구동되는 노트북에서는 Wi-Fi 경로가 일반적으로 600과 같은 메트릭을 가지므로, 경로 추가는 성공하고 메트릭이 0인 터널 경로가 우선순위를 갖게 됩니다. NAS는 응답하지만, 해당 대역 내의 카페 네트워크에 있는 모든 호스트(DNS 서버 포함)가 이제 터널 뒤에 위치하게 됩니다.

풀 터널(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"가 설정되어 있거나 ufw route allow 규칙이 일치하지 않는 한 포워딩된 패킷은 차단됩니다. Docker는 기본 iptables 백엔드를 사용할 경우, 시작 시 포워딩을 켜야 할 때 자체적으로 동일한 정책을 설정합니다(단, /etc/docker/daemon.json 파일에 ip-forward-no-drop가 설정된 경우는 예외입니다). 따라서 수동으로 방화벽을 설정한 적이 없는 서버에서 sudo iptables -S FORWARD | head -1 명령이 -P FORWARD DROP을 출력한다면, 보통 Docker가 이를 설정했음을 의미합니다. 물론 프로비저닝 스크립트나 다른 방화벽 관리자가 설정했을 가능성도 있습니다. 어느 경우든 터널 트래픽을 허용하려면 명시적인 accept 규칙이 필요합니다.

응답이 돌아오지 않는 이유

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

옵션 A: WireGuard 서버에서 매스커레이드(masquerade) 사용. 서버는 enp1s0를 통해 나가는 모든 터널 패킷의 출발지 주소를 해당 인터페이스의 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은 패킷 카운트 없이 규칙을 출력하며, 해당 카운트는 규칙이 실제로 사용되고 있는지 확인하는 핵심 지표입니다.

매스커레이드는 간과하기 쉬운 두 번째 이점을 제공합니다. 많은 호스트가 자신의 서브넷에서 오는 연결만 허용하는 방화벽을 실행합니다. Windows 파일 공유가 기본적으로 이렇게 동작하며, 여러 NAS 관리 패널도 마찬가지입니다. 이러한 호스트에서는 라우팅이 완벽하더라도 10.8.0.2에서 온 패킷은 차단됩니다. 매스커레이드를 적용하면 출발지가 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에 대한 자체 규칙이 필요합니다. 이미 제어 가능한 장비 외에 추가 설정이 필요 없는 매스커레이드로 시작하고, 실제 클라이언트 주소가 필요한 경우 정적 경로로 전환하십시오.

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

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

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

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에 도달하기 전 복호화 과정에서 폐기된 것입니다. 서버의 ip -s link show wg0에서 ping을 보낼 때마다 RX 오류 카운트가 증가한다면 이를 확증할 수 있습니다. 카운트가 그대로라면 클라이언트의 방화벽이 터널로 나가는 트래픽을 차단하고 있는지 확인하십시오.

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

sudo tcpdump -ni enp1s0 icmp

wg0에서는 요청이 보이지만 여기서 아무것도 보이지 않는다면 규칙 3의 문제입니다. 포워딩이 비활성화되었거나 FORWARD 규칙에 의해 패킷이 폐기된 경우입니다. 드물게 엄격한 역방향 경로 필터링(rp_filter)이 패킷을 폐기하기도 하는데, 이는 서버의 출발지로 돌아가는 경로가 다른 인터페이스를 가리킬 때 발생합니다. 여기서 출발지 10.8.0.2인 요청은 보이지만 응답이 없다면 규칙 4의 문제입니다. 응답을 위한 경로가 없거나, ping에 응답하지 않거나 자신의 서브넷에만 응답하는 호스트인 경우 동일한 증상을 보입니다. 여기서 출발지 192.168.20.5인 요청은 보이지만 응답이 없다면 마스커레이드 규칙은 정상 작동하는 것이며 대상 호스트 자체가 응답하지 않는 것입니다. NAS의 방화벽을 확인하고, 리눅스 호스트라면 net.ipv4.icmp_echo_ignore_all이 ping을 무시하도록 설정되어 있는지 확인하십시오. 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을 출발지 주소로 하는 질의에 응답할 수 있어야 합니다. 많은 홈 리졸버는 기본적으로 이를 거부합니다. 예를 들어 dnsmasq이 local-service 옵션으로 실행 중인 경우 직접 연결된 서브넷의 질의에만 응답하며, Pi-hole은 로컬 요청만 허용하는 수신 모드로 배포됩니다. 마스커레이드(masquerade) 규칙을 적용하면 질의가 재작성된 후 192.168.20.5에서 온 것처럼 보이므로 이 문제가 가려집니다.

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

DNS = 192.168.20.1

Linux 클라이언트에서는 openresolv 또는 그에 상응하는 도구가 필요합니다. 그렇지 않으면 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 범위 내에 있다면, 귀하는 CGNAT(Carrier Grade Network Address Translation) 환경에 있는 것이며 인터넷에서 오는 어떤 핸드셰이크도 가정 내 서버에 도달할 수 없습니다. 해당 위치에 사설 192.168.x.x 주소가 있다면 보통 귀하의 라우터 앞에 다른 라우터가 있는 이중 NAT 상태입니다. ISP의 모뎀 라우터를 브리지 모드로 전환하거나 해당 장비에서도 UDP 51820 포트를 포트 포워딩하십시오. 해당 장비를 변경할 수 없거나 그 장비의 WAN 주소조차 공인 IP가 아니라면 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도 필요하며, 방화벽의 forward 체인은 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를 사용 중이라면, 스플릿 터널 wg-quick up은 ip route add이 RTNETLINK answers: File exists 오류를 반환하며 실패하거나, Wi-Fi 경로의 메트릭이 더 높을 경우 터널 뒤에 있는 로컬 호스트들이 가려지게 됩니다. 풀 터널은 연결되지만, wg-quick가 메인 테이블의 더 구체적인 경로를 차단하는 정책 규칙을 설치하므로 로컬 네트워크가 우선권을 가져 원격 LAN에는 도달할 수 없게 됩니다. 홈 LAN 대역을 192.168.20.0/24과 같이 흔하지 않은 대역으로 변경하십시오. 클라이언트 측에서 해결할 방법은 없습니다.

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

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

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

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

이 글이 도움이 되었나요?

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