WireGuard服务器配置缺失咨询：VPN测试卡壳求排查建议

Let’s walk through targeted checks to get your tunnel working properly—since you can ping the server but other traffic is missing, and tcpdump confirms packets are hitting the wg0 interface, the basic tunnel is up, but return routing or filtering is likely broken.

Key Troubleshooting Steps #

• Verify WireGuard AllowedIPs Configuration
  Double-check your server’s WireGuard config (/etc/wireguard/wg0.conf):

  • The AllowedIPs field for your client should include both the client’s VPN IP and its local subnet (e.g., 10.0.0.2/32, 192.168.1.0/24 if your client is on 192.168.1.x). Without the local subnet, the server won’t know how to route return traffic to devices on the client’s side of the tunnel.
  • On the client, ensure AllowedIPs is set to cover the traffic you want to send through the tunnel (e.g., 0.0.0.0/0 for all traffic, or specific subnets).

• Check NAT/Masquerading Rules
  Even with ip_forward enabled, you need a NAT rule to let the server translate VPN subnet traffic to its public IP:

  # Replace eth0 with your server's public interface, 10.0.0.0/24 with your VPN subnet
  sudo iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
  

  Save the rule so it persists on reboot (use iptables-save or your distro’s firewall tool like ufw). Also run sudo iptables -L -v to ensure no rules in the INPUT or FORWARD chains are dropping traffic from wg0.

• Address Outdated Server Kernel
  Your server’s kernel (3.13.0-141) is extremely old for WireGuard. While WireGuard technically supports 3.10+, older kernels often have compatibility bugs that cause packet processing failures. DigitalOcean makes it easy to upgrade:

  1. SSH into your Droplet and run sudo apt update && sudo apt install linux-generic-hwe-16.04 (or a newer supported kernel package for your Ubuntu version).
  2. Reboot the server and confirm the new kernel is active with uname -r.

• Validate Proxy ARP and Routing

  • Confirm proxy_arp is enabled on all interfaces and wg0:

    cat /proc/sys/net/ipv4/conf/all/proxy_arp
    cat /proc/sys/net/ipv4/conf/wg0/proxy_arp
    

    Both should return 1. If not, set them with sudo sysctl -w net.ipv4.conf.all.proxy_arp=1 and sudo sysctl -w net.ipv4.conf.wg0.proxy_arp=1, then add these to /etc/sysctl.conf to persist.
  • Check the server’s routing table with ip route show—there should be an entry pointing your client’s local subnet to the wg0 interface (e.g., 192.168.1.0/24 dev wg0 proto kernel scope link src 10.0.0.1).

• Client-Side Checks

  • On your Mint client, run ip route show to confirm traffic intended for the VPN is routed through wg0 (e.g., a default route via 10.0.0.1).
  • Disable the client’s firewall temporarily (e.g., sudo ufw disable) to rule out local filtering blocking return traffic.

• Deep Packet Analysis
  Run simultaneous tcpdumps on the server to track packet flow:

  # Capture WireGuard traffic on public interface
  sudo tcpdump -i eth0 host <CLIENT_PUBLIC_IP> and port 51820 -vv
  # Capture traffic on wg0 interface
  sudo tcpdump -i wg0 host <CLIENT_VPN_IP> -vv
  

  Look for whether the server is sending return packets out eth0 after receiving them on wg0. If no return packets are sent, routing or NAT is misconfigured; if they are sent but the client doesn’t get them, check the client’s firewall or router.

Start with the kernel upgrade—this is the most likely culprit given the huge version gap between server and client. Let me know if any of these steps resolve the issue!

内容的提问来源于stack exchange，提问作者jimb