Início / computer / Perguntas / 1819292
Accepted
cruunnerr
Asked: 2023-12-04 19:56:52 +0800 CST

Wireguard no Nginx Proxy Manager e VPS - Roteamento correto

  • 772

Em casa tenho um ISP que me dá CGNAT.

Portanto, tenho um VPS como servidor wireguard instalado e funcionando. No meu homelab tenho uma VM com Ubuntu e Nginx Proxy Manager instalados. Nesta VM também instalei o wireguard para conectar ao VPS.

Imagem de topologia:

Imagem de topologia

Na minha LAN, a GUI NginxProxyManager (NPM) está disponível em 172.16.0.9:81

O roteamento funciona conforme o esperado. Se eu me conectar ao VPS público através dos meus subdomínios, vejo meus servidores web. Então isso funciona muito bem. Mas tenho que usar "AllowedIPs=0.0.0.0/0" na configuração do NPM wireguard. Qualquer outra configuração não funciona.

No que diz respeito ao túnel wireguard, não consigo me conectar ao meu NPM via rede local. Mas tem conexão com a internet. Tem algo a ver com a configuração AllowedIPs.

Eu visito https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/ e tentei muitas configurações diferentes com a proibição de intervalos de endereços locais, etc.... Mas nada funciona. Posso acessar meus servidores web através do IP público do VPS ou posso acessar meu NPM localmente, mas não simultaneamente.

Aqui estão minhas configurações até agora:

Configuração VPS:

[Interface]
PrivateKey = ****
ListenPort = 51999
Address = 192.168.200.1/24

PostUp = iptables -t nat -A PREROUTING -p tcp -i ens192 '!' --dport 22 -j DNAT --to-destination 192.168.200.2
PostUp = iptables -t nat -A POSTROUTING -o ens192 -j SNAT --to-source z.z.z.z
PostUp = iptables -t nat -A PREROUTING -p udp -i ens192 '!' --dport 51999 -j DNAT --to-destination 192.168.200.2
PostUp = iptables -A FORWARD -i wg0 -o ens192 -j ACCEPT
PostUp = iptables -A FORWARD -i eth0 -o wg0 -j ACCEPT

PostDown = iptables -t nat -F
PostDown = iptables -F FORWARD;

[Peer]
PublicKey = *****
AllowedIPs = 192.168.200.2/32

Configuração NPM:

[Interface]
PrivateKey = ****
Address = 192.168.200.2/24

[Peer]
PublicKey = ****
AllowedIPs = 0.0.0.0/0
Endpoint = z.z.z.z:51999
PersistentKeepalive = 25

EDIT: No NPM wireguard, antes de abrir o túnel, obtive:

rota IP:

default via 172.16.0.1 dev ens18 proto static
172.16.0.0/24 dev ens18 proto kernel scope link src 172.16.0.9
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-00d63081655a proto kernel scope link src 172.18.0.1

regra de IP:

0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

depois de abrir o túnel:

rota IP:

default via 172.16.0.1 dev ens18 proto static
172.16.0.0/24 dev ens18 proto kernel scope link src 172.16.0.9
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-00d63081655a proto kernel scope link src 172.18.0.1
192.168.200.0/24 dev wg0 proto kernel scope link src 192.168.200.2

regra de IP:

0:      from all lookup local
32764:  from all lookup main suppress_prefixlength 0
32765:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main
32767:  from all lookup default
vpn

1 respostas

  1. Best Answer
    32764:  from all lookup main suppress_prefixlength 0
32765:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main

    Primeiro de tudo você precisa entender o significado das regras de IP aqui, especialmente a primeira. Quando você usa AllowedIPs = 0.0.0.0/0, o wg-quick não faz exatamente com que seu sistema roteie todos os tráfegos não encapsulados pelo WG para fora da interface wg. A regra principal aqui significa efetivamente que todas as rotas, exceto a defaultrota na sua maintabela, ainda serão usadas, já que é a única rota que tem comprimento de prefixo igual ou menor que 0. ( defaulté basicamente um apelido de 0.0.0.0/0.)

    Normalmente um host teria rotas específicas, nomeadamente as "rotas de prefixo", para a(s) sua(s) "rede(s) local(is)". No entanto, no seu caso, aparentemente o que você quer dizer com "rede local" é na verdade uma rede "remota" ao host NPM.

    Não vou me aprofundar em como definimos se uma rede é "local" ou "remota" aqui, e de qualquer maneira, não é a causa raiz do problema aqui, mas resulta mais ou menos na causa raiz, ou seja, sua maintabela não possui rota específica/não- defaultrota que cubra essa "rede local" de interesse (ou seja, 10.0.0.0/8). O resultado é que os tráfegos com um destino que pertence à sub-rede serão roteados para o túnel em vez de para 172.16.0.1encaminhamento adicional, uma vez que a defaultrota na maintabela é efetivamente substituída por aquela na 51820tabela (com os tráfegos encapsulados em WG marcados sendo a exceção).

    Portanto, IMHO, a solução mais simples é adicionar uma rota específica à 10.0.0.0/8mesa main(e não mexer com Table=você ip rulemesmo). Isso pressupõe que você não precisa acessar o NPM de outro 10.0.0.0/8(que não seja o NAT/IP de origem mascarado em nenhum ponto) no lado do VPS. (Por exemplo, digamos que você tenha vários VPSes que pertencem à mesma rede que faz uso 10.0.0.0/8ou a um subconjunto dela.)

    FWIW, se esta "rede local" não tiver realmente um comprimento de prefixo de /8(mas, por exemplo, apenas alguns /24sendo 10o primeiro octeto), é melhor rotear mais especificamente.

    • 0

relate perguntas