Início / server / Perguntas / 1162028
Accepted
intelfx
Asked: 2024-07-04 23:35:13 +0800 CST

Como rotear um endereço IP “para” um túnel WireGuard?

  • 772

Eu tenho duas máquinas A e B. A é um VPS que possui endereços IPv4 e IPv6 globalmente roteáveis, B é um servidor físico atrás de um NAT de nível de operadora:

  • A:

    • Endereços IPv4 A1 e A2 (on-link);
    • Prefixo IPv6 A3::/56 (roteado).

  • Bpossui apenas um endereço IPv4 B1 no bloco de endereços RFC 6598 100.64.0.0/10.

A e B estão em redes diferentes, em ISPs diferentes, nada em comum, exceto que A1 e A2 são acessíveis a partir de B.

Preciso configurar um túnel entre A e B, de forma que B se comporte como se A2 fosse seu endereço.

Especificamente, preciso ser capaz de:

  1. receber conexões para A2 na máquina B,
  2. iniciar novas conexões usando A2 da máquina B e
  3. execute DNAT em algumas das conexões de entrada e redirecione-as para outras máquinas C1..Cn que estão "atrás" de B.

Como faço isso?

routing

1 respostas

  1. Best Answer

    A maioria dos túneis pode lidar com isso da mesma maneira, mas comece configurando um túnel WireGuard simplesmente porque é baseado em UDP e tem maior probabilidade de passar por NAT (CG) do que, por exemplo, GRE bruto. (Como alternativa, GRE-over-IPsec também funcionaria, pois o IPsec usará automaticamente o encapsulamento UDP, fornecendo GRE-ESP-UDP. Acredito que L2TP e VXLAN também podem funcionar bem, ambos baseados em UDP.)

    Além disso, será necessário ter algum tipo de keepalive devido ao (CG)NAT, caso contrário, perderá o controle dos fluxos ociosos, e o "PersistentKeepalive" integrado do WireGuard será útil. Habilite o envio de pacotes keepalive de B (no [Peer] que representa A), pois é ele que precisa ser "perfurado".

    Depois de montar o túnel:

    Para o endereço IP, o roteamento para B é simples; você literalmente roteia esse endereço através da interface do túnel.

    É mais importante fazer respostas da rota B através desse túnel também. A melhor maneira de fazer isso é usar "roteamento de política" se B for capaz disso, embora SNAT em A (como visto em situações de "NAT hairpin") possa ser usado em caso de emergência. (O Linux também implementa uma terceira opção mais fácil, rotas específicas de origem, mas apenas para IPv6; não para IPv4.)

    "On-link" significa que o servidor original ainda precisa responder às consultas ARP para A2, não há outra diferença. Se A2 não estiver atribuído diretamente a uma interface em A, então A precisará responder em seu nome de qualquer maneira (proxy ARP).

    1. Desatribua A2 de qualquer uma das interfaces de A.
    2. Habilite o proxy ARP para A2 usando ip neigh add ... proxy. (Ou o parpddaemon, se preferir; o que for mais fácil de configurar.)
      Infelizmente, o [Neighbor] do systemd-networkd não funcionará para substituir 'ip neigh add' - ainda falta o equivalente ao sinalizador 'proxy'.
      Nota: Eu não sugeriria usar o proxy_arp "blanket enable" ou IPv4ProxyARP= sysctls - eles são um pouco amplos demais e você não deseja fazer proxy acidental de toda a rede de A de volta para si mesmo.
    3. Verifique com tcpdump se A ainda responde às consultas ARP para A2, por exemplo, quando A2 recebe ping de fora e o gateway upstream de A tenta fazer a consulta ARP.tcpdump -e -n -i eth0 'arp'
    4. Rota A2/32 via wg0. Se estiver usando wg-quick, ele fará isso automaticamente de acordo com AllowedIPs na próxima etapa.
    5. Atualize wg0 "AllowedIPs" em A para rotear internamente A2/32 para o [Peer] que representa B (o que também faz com que A aceite pacotes "de A2" desse peer).
    6. Verifique com o tcpdump se os pacotes para A2 saem pelo wg0 de A.
    7. Atualize wg0 "AllowedIPs" em B para 0.0.0.0/0 no peer que representa A, tanto para aceitar pacotes de qualquer origem quanto para rotear pacotes internamente para qualquer destino. Não recarregue a configuração ainda (se você não tiver acesso físico ao console).
    8. Supondo que wg-quick esteja sendo usado, atualize a configuração wg0 de B para que "Tabela" seja definida como um ID de tabela de rota atualmente não utilizado. Verifique ip route list table Xse possui uma rota 0.0.0.0/0 via wg0 (correspondente a AllowedIPs). Se wg-quick não estiver sendo usado, adicione essa rota manualmente.
    9. Verifique com tcpdump se os pacotes para A2 chegam ao wg0 de B. Isso deve ser feito após AllowedIPs.
    10. Atribua A2/32 à interface wg0 de B (ou qualquer outra interface de B).
    11. Adicione uma regra de roteamento de política em B para selecionar a tabela X para qualquer pacote com A2 como origem. Por exemplo, ip rule add from A2/32 lookup Xou [RoutingPolicyRule] do systemd-networkd.
    12. Verifique com o tcpdump se B agora está respondendo aos pings e se essas respostas estão saindo através do seu wg0.
    13. Verifique com tcpdump se A está recebendo essas respostas através de seu wg0 e encaminhando-as através da interface WAN para o pinger.
    14. B agora pode fazer o que quiser com os pacotes.

    As etapas seriam muito semelhantes para qualquer tipo de túnel, por exemplo, GRE, menos o negócio "AllowedIPs" (GRE ou IPIP têm apenas um único peer, portanto permitem automaticamente qualquer endereço) e menos as rotas automáticas relacionadas (crie-as manualmente).

    Um processo alternativo sem proxy-ARP também é possível, onde A2 permanece atribuído a A, mas A faz um DNAT geral para o endereço do túnel de B. Isso não permite que B "possua" A2, mas mesmo assim é muito comum, como visto, por exemplo, em grandes provedores de nuvem (GCE, EC2, Oracle) que implementam "IPs flutuantes" exatamente dessa maneira, e também visto em gateways domésticos que o chamam "DMZ". Ele ainda permite que B roteie/DNAT os pacotes ainda mais.

    • 1

relate perguntas