Passe o tráfego da web para o endpoint VPN diferente do envelope OpenVPN através da própria VPN

Se não estiver usando Strict Reverse Path Forwarding ("SRPF"), nenhum nftables deverá ser usado.

Embora o tráfego roteado (encaminhado) geralmente funcione bem quando as marcas são tratadas em iptables ou nftables , o tráfego redirecionado iniciado localmente por causa de uma marca (em type route hook outputcadeia) geralmente apresenta problemas: a verificação de redirecionamento que acontece na type route hook outputcadeia não alterará magicamente a origem local Endereço IP que já foi escolhido no soquete do cliente. Geralmente é o endereço IP errado. Portanto, geralmente requer um bandaid NAT (que seria necessário no type nat hook output) e provavelmente tornará o manuseio do UDP ainda mais difícil do que já é em um ambiente multi-homed. O uso de nftables para isso deve ser evitado sempre que possível.

Assim como o WireGuard, o OpenVPN pode definir adequadamente a própria marca do firewall no tráfego de saída do envelope, e isso acontecerá antes de qualquer pesquisa de rota acontecer para o tráfego de saída local:

--mark value

Marcar pacotes criptografados sendo enviados com valor. O valor da marca pode ser correspondido nas regras de roteamento de política e filtro de pacotes. Esta opção só é compatível com Linux e não faz nada em outros sistemas operacionais.

Isso funciona da mesma forma que o WireGuard: os pacotes de envelope de saída, na interface real, recebem a marca, provavelmente fazendo com que o cliente use SO_MARKseu soquete antes de se conectar ao servidor:

SO_MARK(desde Linux 2.6.25)

Defina a marca para cada pacote enviado através deste soquete (semelhante ao destino MARK do netfilter, mas baseado em soquete). A alteração da marca pode ser usada para roteamento baseado em marca sem netfilter ou para filtragem de pacotes.

É claro que se não houver reencaminhamento nem utilização directa de políticas de encaminhamento, incluindo marcação directa (com SO_MARKou um método equivalente), é provável que não funcione de todo.

Portanto, exclua todas as regras do nftables :

nft delete table inet vpn

e, em vez disso, adicione a configuração do cliente:

mark 4

Mantenha as regras e a tabela de roteamento (elas provavelmente devem ser integradas nos ganchos VPN):

- ip rule:
0:  from all lookup local
32764:  from all lookup main suppress_prefixlength 0
32765:  not from all fwmark 0x4 lookup vpn
32766:  from all lookup main
32767:  from all lookup default

- ip route show table vpn:
default dev tun0 scope link

Nota: as partes no final desta resposta, apenas para o caso SRPF, devem ser adicionadas antes de adicionar a entrada da tabela de roteamento acima para evitar interrupções temporárias.

Não adicione uma rota padrão através da VPN nem uma rota explícita para o terminal remoto . Não faça com que o servidor envie esta configuração. Ou faça com que o cliente ignore com:

pull-filter ignore redirect-gateway

ou:

route-nopull

Para que essas rotas não apareçam:

END.POINT.IP.ADDRESS via 192.168.1.1 dev wlp4s0 proto static metric 50 

mas apenas este é adicionado:

10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2 metric 50 

Em vez disso, as regras de roteamento da política tratarão a rota padrão selecionando a tabela de roteamento vpnsomente quando for adequado.

Conforme explicado em minha resposta à primeira pergunta/resposta vinculada, a maior parte do conjunto de regras nftables para WireGuard Table = auto+ AllowedIPs = 0.0.0.0é lidar com SRPF para tráfego de resposta. Existem alguns casos:

• rp_filter=0em todos os lugares

  incluindo net.ipv4.conf.default.rp_filtere net.ipv4.conf.all.rp_filter. Nenhuma verificação RPF: nada a fazer. Não são necessários nftables .

• rp_filter=1

  Agora o tráfego de resposta de envelope pode falhar no SRPF

  • Escolha Loose RPF na interface principal:

    sysctl -w net.ipv4.conf.wlp4s0.rp_filter=2
    

    e acabar com isso. Não são necessários nftables ,

  • ou implementar toda a lógica para marcar o tráfego do envelope de retorno assim como é feito no WireGuard

    • Faça com que o fwmark também seja usado na pesquisa de caminho reverso

      habilitando src_valid_marka interface principal (poderia ter sido ativada all), permitindo assim que o SRPF passasse:

      sysctl -w net.ipv4.conf.wlp4s0.src_valid_mark=1
      

    • Transpor (somente IPv4 aqui) a configuração do WireGuard

      conforme visto nas perguntas e respostas vinculadas, com casos adicionais descritos no final também contabilizados, portanto, o tráfego de resposta recebe a marca fw

      table ip vpn {
          chain preraw {
              type filter hook prerouting priority raw; policy accept;
              iifname != "tun0" ip daddr 10.8.0.2 fib saddr type != local drop
          }
      
          chain premangle {
              type filter hook prerouting priority mangle; policy accept;
              ct mark 4 meta mark set ct mark
          }
      
          chain postmangle {
              type filter hook postrouting priority mangle; policy accept;
              meta mark 4 ct mark set meta mark
          }
      }
      

      A corrente prerawé opcional e pode ser removida se necessário. Ele protege contra tentativas remotas (LAN) de acesso ao endereço local VPN interno.

      A marca é criada pelo OpenVPN em pacotes de envelope de saída, copiada para a marca de conexão no pós-roteamento do gancho e reinjetada nos pacotes de envelope de resposta no pré-roteamento do gancho. Nenhum endereço de endpoint ou porta aparece em nenhum lugar.

      Nenhum reencaminhamento é feito (não type route hook outputnem type nat hook outputpresente).

    Nota: o comando sysctl e o conjunto de regras nftables acima devem ser executados antes de adicionar a rota padrão na tabela de roteamento vpnou a perda temporária de conectividade acontecerá até que o soquete TCP da VPN se recupere (ainda assim, apenas quando ambos forem adicionados).

O sistema cliente agora pode alcançar o servidor de dentro do túnel.

Os testes de conectividade podem ser feitos assim:

socat -d -d TCP4:END.POINT.IP.ADDRESS:443 -

Os OPs tcpdumpdevem chegar a END.POINT.IP.ADDRESS em um único salto: através da VPN.

Pelo menos em uma arquitetura amd64 (x86-64), a VPN pode ser ignorada (como root) com:

socat -d -d TCP4:END.POINT.IP.ADDRESS:443,setsockopt-listen=1:36:L4 -

onde setsockopt-listensignifica: usar SO_MARKantes de conectar (em vez de ouvir, neste caso). e 4 pol L4é o mesmo valor de marca usado pelo OpenVPN.

Nota: o caso específico do cliente que consulta através do túnel um serviço UDP no servidor com o endereço IP público de um servidor pode atingir um problema comum não relacionado realmente à VPN, mas ao uso de UDP e ao fato de ser multi-homed. Isso requer que o serviço UDP seja compatível com multi-homed: geralmente usando vários soquetes UDP, vinculando uma vez para cada endereço local (geralmente pelo menos uma vez por interface) ou com um único soquete UDP não vinculado usando IP_PKTINFOcódigo de manipulação adicional.

Primeiramente muito obrigado pela pronta resposta.

Ah, ok. Entendo que, como a decisão inicial de roteamento logo após o processo de solicitação já ocorreu, sem NAT, o reencaminhamento enviará os pacotes com uma fonte errada e, portanto, falhará.

Então eu fiz o seguinte:

Em relação ao rp_filter, o padrão da minha distribuição é 2, não vou adicionar mais complexidade a isso. Então, deixando tudo isso fora do caminho, conforme recomendado. Eu configurei tudo isso como 0 por enquanto.

Eu mantive nftables apenas para rastrear pacotes e garantir que o openvpn marcasse os pacotes conforme abaixo).

- ip rule
0:  from all lookup local
32764:  from all lookup main suppress_prefixlength 0 **I tried with and without that one with no effect on reaching the webserver**
32765:  not from all fwmark 0x4 lookup vpn
32766:  from all lookup main
32767:  from all lookup default

- ip route show table vpn:
default dev tun0 scope link

- ip route
default via 192.168.1.1 dev wlp4s0 proto dhcp src 192.168.1.10 metric 600 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2 
192.168.1.0/24 dev wlp4s0 proto kernel scope link src 192.168.1.10 metric 600 

- nft list ruleset (kept just for seeing if openvpn did mark the packets, and it did)
table inet vpn {
    chain premangle {
        type filter hook prerouting priority mangle; policy accept;
        meta mark 0x00000004 meta nftrace set 1
    }

    chain postmangle {
        type route hook output priority mangle; policy accept;
        meta mark 0x00000004 meta nftrace set 1
    }
}

No entanto, agora não consigo mais acessar o servidor web:

traceroute -n --fwmark=0x4 END.POINT.IP.ADDRESS
    Shows it goes via the physical interface and my ISP ips outside of the vpn envelope (as expected). Wireshark shows all the Icmp packets.

traceroute -n END.POINT.IP.ADDRESS
    **attempts the 30 hops without success and fails to find a route. Wireshark does not show any Icmp packet on any interface**

socat -d -d TCP4:END.POINT.IP.ADDRESS:443 -
socat[56833] N opening connection to AF= ** and stalls until Ctrl-C

Eu fiz ip route flush cacheapenas por precaução. Sem sucesso, enquanto tudo parece em ordem com:

ip route get END.POINT.IP.ADDRESS
END.POINT.IP.ADDRESS dev tun0 table vpn src 10.8.0.2 uid 0 cache 

ip route get END.POINT.IP.ADDRESS mark 4
END.POINT.IP.ADDRESS via 192.168.1.1 dev wlp4s0 src 192.168.1.10 mark 4 uid 0 cache 

O Wirehshark não mostra nenhum pacote relacionado à solicitação, nem mesmo para endereço errado ou sem resposta.

Alguma pista de algo que possa atrapalhar, por favor?! Desculpe se entendi mal algum ponto, a configuração que você propôs faz sentido para mim, francamente. Obrigado !