Perguntas[iptables](server)

Preciso expor um serviço Wireguard no Kubernetes por meio de um AWS Network Load Balancer.

O Load Balancer não roteia tráfego para meu pod wireguard a menos que as verificações de integridade sejam aprovadas. Como os AWS Load Balancers não oferecem suporte a verificações de integridade UDP, e o wireguard é executado em UDP, anexei um serviço TCP simples ao pod wireguard, mas ele não pode ser alcançado e, portanto, falha nas verificações de integridade.

Aqui está o snippet de especificação de implantação do yaml relevante.

    spec:
      containers:
        - name: "wireguard"
          image: "linuxserver/wireguard:latest"
          ports:
            - containerPort: 51820
              protocol: UDP
          securityContext:
            privileged: true
            capabilities:
              add:
                - NET_ADMIN
        - name: healthcheck
          image: istio/tcp-echo-server:latest
          imagePullPolicy: IfNotPresent
          args: [ "9000", "hello" ]
          ports:
          - containerPort: 9000

Se eu deixar de fora o contêiner wireguard ou comentar a parte NET_ADMIN, garantindo assim que nenhuma configuração de rede seja alterada, posso acessar com sucesso o pod heathcheck, executando, por exemplo:

kubectl run -i --rm --restart=Never dummy --image=busybox -- sh -c "echo world | nc wireguard-service.wg-test 9000"
hello world

Nos logs do contêiner do wireguard, posso ver esses comandos sendo executados. Suspeito que algo na configuração de roteamento do nó seja alterado para que a porta 9000 se torne inacessível.

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.11.0.1/16 dev wg0
[#] ip link set mtu 1450 up dev wg0
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n
[#] iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
[#] sysctl -w -q net.ipv4.ip_forward=1

Tentei adicionar iptables -A INPUT -p tcp --dport 9000 -j ACCEPTe iptables -A FORWARD -p tcp --dport 9000 -j ACCEPTnão adiantou. O que estou esquecendo aqui?

Solução de problemas de conectividade IPv4 limitada na porta 25.

Tenha regras ipTables:

  Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  185.121.228.0/24     anywhere            
ACCEPT     all  --  127.0.0.0/24         anywhere            
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:smtp

Uma vez que a política de ENTRADA padrão é ACEITAR,

root@mail:/home/ubuntu# echo “HELO” | nc -4 smtp.google.com 25
220 mx.google.com ESMTP ffacd0b85a97d-38a1c8bb5f7si23003263f8f.375 - gsmtp
502-5.5.1 Unrecognized command. For more information, go to
502 5.5.1  https://support.google.com/a/answer/3221692 ffacd0b85a97d-38a1c8bb5f7si23003263f8f.375 - gsmtp

Quando a política de ENTRADA padrão é DROP, o mesmo comando trava indefinidamente.

Agora, a parte mais interessante é que a mudança na política de INPUT não tem efeito sobre

root@mail:/home/ubuntu# echo “HELO” | nc -6 smtp.google.com 25

que está recebendo resposta do Google de qualquer maneira.

É preciso que o servidor de e-mail envie e-mails para todos os outros servidores de e-mail, não apenas para aqueles compatíveis com IPv6.

Se alguém pudesse explicar o que está acontecendo, seria fantástico!

Atualizado: a impressão do ip-save é:

:INPUT DROP [41791:1739301]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6390374:3802889072]
-A INPUT -i ens3 -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -s 127.0.0.0/24 -i lo -j ACCEPT
-A INPUT -s 185.121.228.0/24 -i ens3 -j ACCEPT
COMMIT

Olá e feliz NYE que se aproxima!

Tentando fazer um firewall na instalação do iRedMail. É preciso manter abertas apenas as portas necessárias para conexões de entrada. Atualmente as regras são:

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:submission
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:submissions
ACCEPT     all  --  localhost            anywhere  
ACCEPT     all  --  185.121.228.0/24     anywhere

      

A última regra é manter sua conexão SSH ativa.

Atualmente, não há e-mails entrando e saindo, nenhum erro e nenhum e-mail devolvido. Suspeito que isso pode ter algo a ver com certificados SSL usados ​​para SMTP não resolverem nomes de host, mas habilitei a porta 53 "domain" para ele e não está ajudando.

Preso aqui. Assim que a política padrão mudou de DROP para ACCEPT, funcionou como uma brisa.

Qualquer ideia sobre como aplicar firewall no servidor iRedMail corretamente será muito bem-vinda!

Editar: SMTP (porta 25) habilitado por si só, que não está sendo usado de qualquer maneira. Não fez efeito

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:smtp
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:submission
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:submissions
ACCEPT     all  --  localhost            anywhere            
ACCEPT     all  --  185.121.228.0/24     anywhere    

    

Onde a configuração do iptables é persistida? A pesquisa não produziu resultados:

/etc/iptables - no such file or directory
/etc/sysconfig - no such file or directory
/etc/init.d/iptables - no such file or directory
/etc/network/if-up.d/ contains ethtool only
/etc/network/if-pre-up.d/ contains ethtool only

Algum outro lugar? Executando Ubuntu 24.04.1 LTS

Suas ideias são muito apreciadas.

Estou executando meu cliente proxy na mesma máquina Linux em que estou usando a conexão. Na configuração, posso dizer para ele fazer tproxy para a porta 2500. O proxy é executado na porta 443, usando TLS (embora o proxy assuma o gerenciamento dessa parte)

Então preciso usar iptables ou nftables para rotear todos os pacotes para o proxy. Mas preciso marcá-los também, para não criar um loop.

Minhas tentativas iniciais não tiveram sucesso, parece que meus pacotes UDP não passaram (estou atrás de um NAT, mas não sei se é esse o problema, já que estou fazendo proxy de qualquer maneira). Gostaria de saber como funciona melhor para que eu possa depurar sozinho.

Aqui está minha tentativa:

ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

#Setup a chain DIVERT to mark packets
iptables -t mangle -N DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT

#Use DIVERT to prevent existing connections going through TPROXY twice:
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A PREROUTING -p udp -m socket -j DIVERT

#Mark all other (new) packets and use TPROXY to pass into xray
iptables -t mangle -A PREROUTING -p tcp -j TPROXY --tproxy-mark 0x1/0x1 --on-port 2500
iptables -t mangle -A PREROUTING -p udp -j TPROXY --tproxy-mark 0x1/0x1 --on-port 2500

#disable rp_filter and enable ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv4.conf.default.rp_filter=0
sysctl -w  net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.wlp38s0.rp_filter=0

os pacotes simplesmente passam pelas minhas regras como se não existissem

Quero uma máquina virtual na nuvem ( VM1) para atuar como proxy TCP para um servidor ( VM2), para que o endereço IP de VM2não seja exposto aos clientes. Os clientes devem se conectar ao endereço IP público de VM1na porta 9735, e todo o tráfego deve ser encaminhado para VM2na mesma porta. As respostas devem ir na direção oposta.

VM1e VM2são conectados via wireguard. Ambos têm duas interfaces: a interface wireguard ( wg0), e uma interface de internet ( ens5, eth0respectivamente). O VM1endereço IP em wg0é 10.200.200.1, enquanto VM2é 10.200.200.2. A conexão wireguard funciona bem. Eu posso com sucesso telnet 10.200.200.2:9735de VM1.

O problema surge quando tento fazer telnet no IP público de VM1.

Configurei o iptables VM1desta maneira.

# Enable IP forwarding
# https://serverfault.com/questions/240532/iptables-dnat-not-working
echo 1 > /proc/sys/net/ipv4/ip_forward

# Reset and allow everything
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -t raw -F
iptables -t raw -X
iptables -t security -F
iptables -t security -X

export WAN=ens5
export LAN=wg0

# Filter rules, default accept, log some
iptables -P INPUT ACCEPT
iptables -A INPUT -p tcp --dport 9735 -j LOG --log-level info --log-prefix "fiter_in"

iptables -P OUTPUT ACCEPT
iptables -A OUTPUT -p tcp --dport 9735 -j LOG --log-level info --log-prefix "fiter_out"

iptables -P FORWARD ACCEPT
iptables -A FORWARD -p tcp --dport 9735 -j LOG --log-level info --log-prefix "filter_forward"

iptables -t nat -A PREROUTING -p tcp -i $LAN -j LOG --log-level info --log-prefix "prerouting_fr_wg0"
iptables -t nat -A PREROUTING -p tcp -i $WAN --dport 9735 -j LOG --log-level info --log-prefix "prerouting_9735"
iptables -t nat -A PREROUTING -p tcp -i $WAN --dport 9735 -j DNAT --to-destination 10.200.200.2:9735

iptables -t nat -A POSTROUTING -o $LAN -j LOG --log-level info --log-prefix "postrouting_to_wg0"
iptables -t nat -A POSTROUTING -o $WAN -j LOG --log-level info --log-prefix "postrouting_to_ens5"
iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE

No VM1, o encaminhamento do iptables funciona perfeitamente, consigo ver os pacotes sendo encaminhados usando tcpdump.

root@myserver:~# tcpdump -n -A tcp -i wg0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
19:53:56.838847 IP [client public ip address].16190 > 10.200.200.2.9735: Flags [S], seq 2996679219, win 64240, options [mss 1420,sackOK,TS val 1658363264 ecr 0,nop,wscale 7], length 0
E..<[email protected].......
...?>&....3.........r.........
b...........

Em VM2, tcpdumpa saída é simplesmente nada. É como VM2se simplesmente não recebesse nada.

Alguma sugestão sobre como posso depurar melhor esse problema?

Eu uso o AlmaLinux 9 e entendo que há um novo serviço de backend nftables que pode ser gerenciado pelo comando iptables-nft, então eu defini algumas regras e meu conjunto de regras se parece com:

# Warning: table ip nat is managed by iptables-nft, do not touch!
table ip nat {
    chain DOCKER {
        iifname "docker0" counter packets 0 bytes 0 return
        iifname != "docker0" tcp dport 8080 counter packets 3 bytes 180 dnat to 172.17.0.2:80
        iifname != "docker0" tcp dport 9001 counter packets 4 bytes 240 dnat to 172.17.0.3:9001
    }

    chain POSTROUTING {
        type nat hook postrouting priority srcnat; policy accept;
        ip saddr 172.17.0.0/16 oifname != "docker0" counter packets 0 bytes 0 masquerade
        ip saddr 172.17.0.0/16 oifname != "docker0" counter packets 0 bytes 0 masquerade
        ip saddr 172.17.0.0/16 oifname != "docker0" counter packets 0 bytes 0 masquerade
        ip saddr 172.17.0.2 ip daddr 172.17.0.2 tcp dport 9001 counter packets 0 bytes 0 masquerade
        ip saddr 172.17.0.2 ip daddr 172.17.0.2 tcp dport 9001 counter packets 0 bytes 0 masquerade
        ip saddr 172.17.0.2 ip daddr 172.17.0.2 tcp dport 80 counter packets 0 bytes 0 masquerade
        ip saddr 172.17.0.3 ip daddr 172.17.0.3 tcp dport 9001 counter packets 0 bytes 0 masquerade
    }

    chain PREROUTING {
        type nat hook prerouting priority dstnat; policy accept;
        fib daddr type local counter packets 236 bytes 12653 jump DOCKER
        fib daddr type local counter packets 39 bytes 1732 jump DOCKER
        fib daddr type local counter packets 39 bytes 1732 jump DOCKER
        fib daddr type local counter packets 23 bytes 1056 jump DOCKER
        fib daddr type local counter packets 23 bytes 1056 jump DOCKER
    }

    chain OUTPUT {
        type nat hook output priority dstnat; policy accept;
        ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER
        ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER
        ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER
    }
}
# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
    chain FORWARD {
        type filter hook forward priority filter; policy drop;
        counter packets 178 bytes 55546 jump DOCKER-USER
        counter packets 178 bytes 55546 jump DOCKER-ISOLATION-STAGE-1
        oifname "docker0" ct state related,established counter packets 84 bytes 11338 accept
        oifname "docker0" counter packets 7 bytes 420 jump DOCKER
        iifname "docker0" oifname != "docker0" counter packets 87 bytes 43788 accept
        iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept
    }

    chain DOCKER-USER {
        counter packets 178 bytes 55546 return
    }

    chain INPUT {
        type filter hook input priority filter; policy drop;
        ct state established,related counter packets 195 bytes 18089 accept
        tcp dport 22 counter packets 2 bytes 120 accept
        tcp dport 443 counter packets 0 bytes 0 accept
    }

    chain DOCKER {
        ip daddr 172.17.0.2 iifname != "docker0" oifname "docker0" tcp dport 80 counter packets 3 bytes 180 accept
        ip daddr 172.17.0.3 iifname != "docker0" oifname "docker0" tcp dport 9001 counter packets 4 bytes 240 accept
    }

    chain DOCKER-ISOLATION-STAGE-1 {
        iifname "docker0" oifname != "docker0" counter packets 87 bytes 43788 jump DOCKER-ISOLATION-STAGE-2
        counter packets 178 bytes 55546 return
    }

    chain DOCKER-ISOLATION-STAGE-2 {
        oifname "docker0" counter packets 0 bytes 0 drop
        counter packets 87 bytes 43788 return
    }
}

esse conjunto de regras é salvo para /etc/sysconfig/nftables.confser carregado toda vez que o servidor é reiniciado, como você pode ver na cadeia INPUT, tudo deve ser descartado, exceto as portas 22 e 443, então tentei executar o teste do servidor nginx na porta 8080 e ainda consigo acessá-lo, meu firewall não está bloqueando nada... por quê? mesmo quando a política INPUT está definida para ser descartada.

EDITAR2:

então eu li que o docker usa a cadeia DOCKER-USER para regras definidas pelo usuário, então eu fiz:

table ip filter {
    chain FORWARD {
        type filter hook forward priority filter; policy drop;
        counter packets 0 bytes 0 jump DOCKER-USER
        counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1
        oifname "docker0" ct state related,established counter packets 0 bytes 0 accept
        oifname "docker0" counter packets 0 bytes 0 jump DOCKER
        iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept
        iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept
        oifname "docker0" ct state established,related counter packets 184 bytes 27570 accept
        oifname "docker0" ct state established,related counter packets 85 bytes 28483 accept
    }

    chain DOCKER-USER {
        counter packets 534 bytes 178277 return
        tcp dport 8080 drop
        tcp dport 9001 drop
    }

    chain INPUT {
        type filter hook input priority filter; policy drop;
        ct state established,related counter packets 584 bytes 54071 accept
        tcp dport 22 counter packets 8 bytes 460 accept
    }

    chain DOCKER {
        ip daddr 172.17.0.2 iifname != "docker0" oifname "docker0" tcp dport 80 counter packets 0 bytes 0 accept
        ip daddr 172.17.0.3 iifname != "docker0" oifname "docker0" tcp dport 9001 counter packets 0 bytes 0 accept
    }

    chain DOCKER-ISOLATION-STAGE-1 {
        iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2
        counter packets 0 bytes 0 return
    }

    chain DOCKER-ISOLATION-STAGE-2 {
        oifname "docker0" counter packets 0 bytes 0 drop
        counter packets 0 bytes 0 return
    }
}

e ainda não funciona, consigo acessar as portas 8080 e 9001, tentei até reiniciar o servidor.

EDIÇÃO 3:

mudei minha corrente para isso:

chain DOCKER-USER {
    tcp dport 8080 drop
    tcp dport 9001 drop
    return
}

servidor reiniciado e a porta 8080 ainda está acessível

Estou tentando entender o módulo physdev iptables, e estou tendo problemas com a tabela nat, especialmente com a cadeia POSTROUTING. Então meu objetivo é fazer SNAT no tráfego de saída na interface bridge usando o módulo physdev.

Aqui está minha mini configuração de rede: PC1 - (enp6s0f0)BRIDGE(enp6s0f1) - PC2 . PC1 é 192.168.100.1/24 e PC2 é 192.168.100.2/24.

Minha configuração de ponte é:

ifconfig enp6s0f0 down
ifconfig enp6s0f1 down
brctl addbr br0
brctl addif enp6s0f0 br0
brctl addif enp6s0f1 br0
ifconfig enp6s0f0 0.0.0.0 up
ifconfig enp6s0f1 0.0.0.0 up
ifconfig br0 169.254.100.1/32 up

essa configuração de ponte funciona bem e o PC1 e o PC2 podem se comunicar entre si e não com a ponte, como esperado.

Agora, por exemplo, quero configurar a comunicação entre os PCs e a BRIDGE de tal forma que o PC1 veja a BRIDGE como 192.168.100.100 e o PC2 veja a BRIDGE como 192.168.100.200.

Então adiciono a rota:

route add -net 192.168.100.0/24 dev br0

e agora se eu fizer ping da BRIDGE para qualquer um dos PCs, posso ver o tráfego de saída da bridge com o IP de origem 169.254.100.1, conforme esperado.

Agora é tudo sobre iptables. Minhas regras:

iptables -t nat -A POSTROUTING -s 169.254.100.1 -m physdev --physdev-out enp6s0f0 -j SNAT --to-source 192.168.100.100
iptables -t nat -A POSTROUTING -s 169.254.100.1 -m physdev --physdev-out enp6s0f1 -j SNAT --to-source 192.168.100.200

Depois disso, espero que todo o tráfego de saída da ponte seja SNATed para 192.168.100.100 ou 192.168.100.200 dependendo do physdev-out, MAS isso não acontece. Por quê? Não sei. O que acontece é que as regras são ignoradas. iptables -t nat -vnL mostra que 0 pacotes correspondem à regra e tcpdump -i enp6s0f0 -p arp -n mostra que todas as solicitações arp têm o antigo endereço IP de origem 169.254.100.1.

Também é importante observar que tenho o módulo br-netfilter carregado e o bridge-nf-call-iptables definido como 1.

O sistema operacional que estou usando é o Ubuntu 20.04, mas tentei outros também. Também procurei informações na Internet e sei que há várias outras maneiras de obter o comportamento que desejo, mas quero descobrir por que esse método em particular não funciona.

Também dei uma olhada em https://ebtables.netfilter.org/br_fw_ia/br_fw_ia.html e depois de ler tenho a sensação de que tudo deve funcionar. Por favor me ajude

Quero testar a tabela NAT usando uma interface fictícia. Tenho a interface enp1s0 conectada à internet e configurei a tabela NAT para pacotes MASQUERADE conforme mostrado abaixo.

random@debian:~$ ip addr
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host noprefixroute 
           valid_lft forever preferred_lft forever
    2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
        link/ether 52:54:00:4d:63:c0 brd ff:ff:ff:ff:ff:ff
        inet 192.168.122.10/24 brd 192.168.122.255 scope global enp1s0
           valid_lft forever preferred_lft forever
        inet6 fe80::5054:ff:fe4d:63c0/64 scope link 
           valid_lft forever preferred_lft forever
    3: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
        link/ether 5e:81:f3:78:47:c0 brd ff:ff:ff:ff:ff:ff
        inet 10.0.0.10/24 scope global dummy0
           valid_lft forever preferred_lft forever
        inet6 fe80::5c81:f3ff:fe78:47c0/64 scope link 
           valid_lft forever preferred_lft forever

random@debian:~$ ip route
default via 192.168.122.1 dev enp1s0 onlink 
10.0.0.0/24 dev dummy0 proto kernel scope link src 10.0.0.10 
192.168.122.0/24 dev enp1s0 proto kernel scope link src 192.168.122.10

random@debian:~$ sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

random@debian:~$ lsmod | grep dummy
dummy                  16384  0

random@debian:~$ ipt
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

random@debian:~$ sudo iptables -t nat -A POSTROUTING -j MASQUERADE -s 10.0.0.0/24 -o enp1s0

random@debian:~$ ipt -t nat
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  all  --  any    enp1s0  10.0.0.0/24          anywhere 

Com essas configurações de ip. Testando com ping

random@debian:~$ ping -I 10.0.0.10 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 10.0.0.10 : 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=28.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=30.9 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 28.302/29.583/30.865/1.281 ms

random@debian:~$ ping -I dummy0 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 10.0.0.10 dummy0: 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4095ms
      

O envio de pacotes através de interface fictícia não funciona. Os pacotes podem ser vistos na interface fictícia dummy0, mas não são encaminhados para enp1s0 conforme observado usando o wireshark.

Eu tenho uma rede doméstica com um roteador DSL. Uma máquina na rede abre uma conexão openvpn com um provedor VPN de terceiros. Esta máquina atua como um roteador para todas as máquinas da minha rede que têm seu gateway configurado para esta máquina, fornecendo-lhes acesso à Internet pela VPN. Algumas máquinas precisam configurar um roteador DSL como gateway e acessar a internet sem VPN.

Gostaria de usar o roteador DSL para acessar minha rede doméstica quando estiver ausente. Para isso, criei uma segunda conexão openvpn na máquina que fornece o vpn que escuta na porta 1194 e encaminhei essa porta no meu roteador DSL. No entanto, só consigo acessar a porta quando a primeira VPN está inativa.

Suspeito que haja algum erro simples de roteamento que não entendo.

Algumas informações básicas:

# 192.168.178.1 is my DSL router.
# 192.168.178.8 is the machine that opens the tun0 vpn connection and routes all traffic through tun0.
# xx.xxx.xxx.xxx is the ip of my third party vpn provider.
# (not relevant but shows up below) Port 33075 is open from the vpn side and is forwarded to a specific machine on the network.
# tun1 was created on 192.168.178.8 with port 1194 for access from outside.
# Port 1194 is opened on the DSL router (192.168.178.1) and forwarded to 192.168.178.8

Com tun0 e tun1 desativados:

% route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eno1
192.168.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eno1

% ip route
default via 192.168.178.1 dev eno1 proto static
192.168.0.0/16 dev eno1 proto kernel scope link src 192.168.178.8

% sudo iptables-save
(empty output)

Com apenas tun1 ativado: a porta encaminhada 1194 do exterior não VPN mostra aberta

% route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eno1
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun1
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun1
192.168.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eno1

% ip route
default via 192.168.178.1 dev eno1 proto static
10.8.0.0/24 via 10.8.0.2 dev tun1
10.8.0.2 dev tun1 proto kernel scope link src 10.8.0.1
192.168.0.0/16 dev eno1 proto kernel scope link src 192.168.178.8

% sudo iptables-save
(empty output)

Com tun0 e tun1 ativados: a porta encaminhada 1194 do exterior não VPN mostra fechada

% route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.28.78.1      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eno1
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun1
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun1
10.28.78.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
xx.xxx.xxx.xxx  192.168.178.1   255.255.255.255 UGH   0      0        0 eno1
128.0.0.0       10.28.78.1      128.0.0.0       UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eno1

% 0.0.0.0/1 via 10.28.78.1 dev tun0
default via 192.168.178.1 dev eno1 proto static
10.8.0.0/24 via 10.8.0.2 dev tun1
10.8.0.2 dev tun1 proto kernel scope link src 10.8.0.1
10.28.78.0/24 dev tun0 proto kernel scope link src 10.28.78.159
xx.xxx.xxx.xxx via 192.168.178.1 dev eno1
128.0.0.0/1 via 10.28.78.1 dev tun0
192.168.0.0/16 dev eno1 proto kernel scope link src 192.168.178.8

%  sudo iptables-save
# Generated by iptables-save v1.8.10 (nf_tables) on 
*filter
:INPUT ACCEPT [44:5124]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i eno1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j ACCEPT
-A FORWARD -d 192.168.178.138/32 -p tcp -m tcp --dport 33075 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 192.168.178.138/32 -p udp -m udp --dport 33075 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on 
# Generated by iptables-save v1.8.10 (nf_tables) on 
*nat
:PREROUTING ACCEPT [76:7067]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i tun0 -p tcp -m tcp --dport 33075 -j DNAT --to-destination 192.168.178.138:33075
-A PREROUTING -i tun0 -p udp -m udp --dport 33075 -j DNAT --to-destination 192.168.178.138:33075
-A POSTROUTING -o eno1 -j MASQUERADE
-A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on