L'handshake de WireGuard funciona, però la subxarxa de l'oficina no respon

L'handshake es completa, wg show informa d'una transferència recent, i l'adreça del túnel del servidor respon a un ping. Un amfitrió de la LAN del servidor, no. Tres condicions s'han de complir alhora: el client ha d'encaminar el prefix de la LAN cap al túnel, el servidor ha de reenviar els paquets, i la resposta necessita un camí de tornada. Quan falta una de les tres, el símptoma és idèntic.

AllowedIPs és alhora una llista d'accés i una taula d'encaminament

Al client, la llista AllowedIPs decideix tant què es pot enviar a aquest parell com quines rutes instal·la WireGuard. Una entrada de parell que només llista l'adreça del túnel del servidor instal·la una ruta d'amfitrió, de manera que les destinacions de la LAN no entren mai al túnel. Afegir el prefix de la LAN és la primera cosa a verificar, i també és el canvi que més sovint falta després d'una configuració copiada. Un parell ampliat a una ruta per defecte és un disseny diferent, i també mourà el trànsit d'internet del client.

Manteniu la ruta d'amfitrió i el prefix de la LAN com a entrades separades. Si l'oficina té dues subxarxes, totes dues pertanyen a la llista, i el segon prefix absent produeix una fallada que sembla selectiva en lloc de total.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

El reenviament i la traducció pertanyen al servidor

El servidor necessita el reenviament d'IP activat, una regla de reenviament que accepti el trànsit provinent del túnel, i una regla de traducció cap a la seva interfície de LAN. La traducció és el que fa funcionar el disseny sense tocar cada amfitrió de la xarxa de l'oficina. Llavors les respostes tornen al servidor en lloc d'una adreça que la LAN no ha sentit mai. Sense això, cada amfitrió necessita una ruta per a la subxarxa del túnel i una regla de tallafoc que la permeti, cosa que rarament és acceptable en una xarxa que gestiona una altra persona.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Les regles afegides a mà desapareixen en reiniciar, així que lligueu-les a la interfície amb les ordres de ganxo de la configuració del servidor. Un conjunt de regles que sobreviu a la seva interfície és com una màquina acaba traduint trànsit per a un túnel que ja no existeix.

Quan la LAN es va moure i la regla no

La substitució d'un encaminador que renumera la subxarxa de l'oficina és la versió clàssica d'aquesta fallada. El túnel continua actiu, l'handshake continua fresc, i res darrere del servidor no respon, perquè la regla de traducció encara anomena l'adreça antiga. Els scripts d'instal·lació sovint incrusten l'adreça de LAN del servidor en una regla POSTROUTING, i després d'una renumeració aquesta adreça no existeix a cap interfície. Llavors els paquets es reescriuen cap a una destinació que no pot respondre.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Compareu les dues sortides. Un objectiu de traducció que no apareix a la llista d'interfícies és l'error, i corregir-lo és un canvi d'una línia un cop l'heu vist. La regla pot viure en una unitat generada en lloc de la configuració de WireGuard, així que torneu a carregar aquesta unitat després d'editar i confirmeu que la propera arrencada no reescriu el vostre canvi.

Dos llocs darrere de NAT necessiten un lloc on trobar-se

Quan cap dels dos costats accepta connexions entrants, la resposta pràctica és un petit amfitrió amb una adreça pública i dues interfícies de WireGuard. Cada lloc es connecta cap a fora, l'amfitrió central llista la LAN de cada parell a la seva pròpia AllowedIPs, i el reenviament transporta paquets entre els dos túnels. No cal canviar res del tallafoc de cap dels dos llocs, i per això aquest disseny s'estén fàcilment.

L'encaminament entre els llocs conserva les adreces d'origen originals i, per tant, manté significatiu el registre per amfitrió. Traduir a l'amfitrió central és més simple quan les dues LAN se superposen, a costa de perdre la identitat de l'origen als registres. Decidiu quina propietat importa abans de triar.

Separeu les capes amb quatre comprovacions

Feu una comprovació per capa en lloc de canviar tres coses i esperar. La primera mostra l'edat de l'handshake i els comptadors de cada parell. La segona mostra si el client encamina realment aquella destinació cap al túnel. La tercera i la quarta us diuen si la sol·licitud va arribar i si una política la va descartar després d'arribar.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Una sol·licitud que arriba i no obté resposta apunta al camí de resposta o a l'amfitrió de la LAN. Una sol·licitud que no arriba mai apunta a AllowedIPs o a la ruta del client. Aquests dos resultats necessiten correccions diferents, i la captura és el que els distingeix.