Início / server / Perguntas / 1164687
Accepted
Crazy Polenta
Asked: 2024-09-03 01:21:09 +0800 CST

usando várias tabelas para rotear ips de DOIS ISPs

  • 772

Preciso configurar meu roteador (Ubuntu Server 24/ NNFTables) para que os computadores conectados às interfaces lan1 e lan2 possam navegar na internet usando as interfaces wan1 ou wan2, dependendo do IP da sub-rede.

Recebo internet através de 2 provedores diferentes.

ISP 1: Bloco ip: 111.11.111.0/28

ISP 2: Bloco ip: 222.22.222.8/29

configurar netplan yaml:

rede:
    ethernet:
        wan1:
            endereços:
            - 111.11.111.2/28
            - 111.11.111.3/28
            - 111.11.111.4/28
            - 111.11.111.5/28
            - 111.11.111.6/28
            - 111.11.111.7/28
            - 111.11.111.8/28
            - 111.11.111.9/28
            - 111.11.111.10/28
            - 111.11.111.11/28
            - 111.11.111.12/28
            - 111.11.111.13/28
            - 111.11.111.14/28
            servidores de nomes:
                endereços:
                - 8.8.8.8
                - 8.8.4.4
                procurar: []
            rotas:
            - para: padrão
                via: 111.11.111.1
        wan2:
            endereços:
            - 222.22.222.10/29
            - 222.22.222.11/29
            - 222.22.222.12/29
            - 222.22.222.13/29
            - 222.22.222.14/29
            servidores de nomes:
                endereços:
                - 8.8.8.8
                - 8.8.4.4
                procurar: []
            rotas:
            - para: padrão
                via: 222.22.222.9                
        lan1:
            endereços:
            - 192.168.10.1/24
            servidores de nomes:
                endereços: []
                procurar: []
        lan2:
            endereços:
            - 192.168.20.1/24
            servidores de nomes:
                endereços: []
                procurar: []
    versão: 2`

usertest@router1:~$ rota ip
padrão via 111.11.111.1 dev wan1 proto estático
192.168.10.0/24 dev enp4s0 proto kernel escopo link src 192.168.10.1
192.168.20.0/24 dev enp5s0 proto kernel escopo link src 192.168.20.1
111.11.111.0/28 dev enp1s5 proto kernel escopo link src 111.11.111.2
222.22.222.8/29 dev enp8s0 proto kernel escopo link src 222.22.222.9

Estações de sub-rede e seus respectivos IPs públicos que gostamos de navegar:

192.168.10.101 ---> 111.11.111.11
192.168.10.102 ---> 111.11.111.12
192.168.10.201 ---> 222.22.222.11
192.168.10.202 ---> 222.22.222.12
192.168.20.10 ---> 222.22.222.10

Vi que preciso trabalhar com várias tabelas de roteamento usando IP ROUTE, mas todas as configurações que tentei falharam...

Alguém sabe como posso resolver isso?

Já tentei algumas configurações de nftables/rota ip... mas não consegui fazer funcionar... Errei tanto que nem sei tudo que tentei... Agora a configuração está assim:

$ rota ip
padrão via 111.11.111.9 dev wan1
192.168.10.0/24 dev lan1 proto kernel escopo link src 192.168.10.1
192.168.20.0/24 dev lan2 proto kernel escopo link src 192.168.20.1
111.11.111.0/28 dev wan1 proto kernel escopo link src 111.11.111.2
222.22.222.8/29 dev wan2 proto kernel escopo link src 111.11.111.10

$ ip rota mostrar tabela 100
padrão via 111.11.111.1 dev wan1 proto estático

$ ip rota mostrar tabela 200
padrão via 222.22.222.9 dev wan2 proto estático

$ ip regra mostrar
0: de todas as pesquisas locais
32764: de 222.22.222.8/29 pesquisa 200 proto estático
32765: de 111.11.111.0/28 pesquisa 100 proto estático
32766: de todas as pesquisas principais
32767: de todas as pesquisas padrão
routing

1 respostas

  1. Best Answer

    A configuração de roteamento que você mostra na sua pergunta parece uma parte substancial da solução. Para testar as coisas, eu montei uma simulação do seu ambiente usando Kathara ; você pode encontrar meu ambiente de teste completo aqui . A topologia de teste se parece com isso:

    Diagrama de topologia de rede

    O objetivo é que possamos alcançar remotehostos nós à direita ( node00através de node11), e cada nó usará o caminho de saída apropriado de router.

    O routernó neste diagrama corresponde ao sistema que você está tentando configurar. Ele tem a seguinte configuração de interface:

    161: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 111.11.111.2/28 scope global eth0
       valid_lft forever preferred_lft forever
    inet 111.11.111.11/28 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet 111.11.111.12/28 scope global secondary eth0
       valid_lft forever preferred_lft forever
169: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 222.22.222.10/29 scope global eth1
       valid_lft forever preferred_lft forever
    inet 222.22.222.11/29 scope global secondary eth1
       valid_lft forever preferred_lft forever
    inet 222.22.222.12/29 scope global secondary eth1
       valid_lft forever preferred_lft forever
170: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.10.1/24 scope global eth2
       valid_lft forever preferred_lft forever
171: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.20.1/24 scope global eth3
       valid_lft forever preferred_lft forever

    A seguinte tabela de roteamento padrão:

    root@router:/# ip route
default via 111.11.111.1 dev eth0
111.11.111.0/28 dev eth0 proto kernel scope link src 111.11.111.2
192.168.10.0/24 dev eth2 proto kernel scope link src 192.168.10.1
192.168.20.0/24 dev eth3 proto kernel scope link src 192.168.20.1
222.22.222.8/29 dev eth1 proto kernel scope link src 222.22.222.10

    As seguintes regras de roteamento de políticas:

    root@router:/# ip rule show
0:      from all lookup local
32764:  from 192.168.20.0/24 lookup 222
32765:  from 192.168.10.0/24 lookup 111
32766:  from all lookup main
32767:  from all lookup default

    Na tabela 111:

    root@router:/# ip route show table 111
default via 111.11.111.1 dev eth0

    Na tabela 222:

    root@router:/# ip route show table 222
default via 222.22.222.9 dev eth1

    Para atingir seus objetivos NAT, o roteador tem o seguinte conjunto de regras NFT:

    table ip nat {
        chain router_masquerade {
                type nat hook postrouting priority srcnat; policy accept;
                ip saddr 192.168.10.101 counter snat to 111.11.111.11
                ip saddr 192.168.10.102 counter snat to 111.11.111.12
                ip saddr 192.168.20.201 counter snat to 222.22.222.11
                ip saddr 192.168.20.202 counter snat to 222.22.222.12
                oifname "eth0" counter masquerade
                oifname "eth1" counter masquerade
        }
}

    Isso aplica as entradas NAT estáticas que você listou na sua pergunta e aplica mascaramento regular a qualquer coisa com lan1ou lan2sem uma entrada explícita.

    Com essa configuração em vigor, se eu executar um tcpdumpon remotehost, assim:

    tcpdump -nn -i eth0

    E então tentamos ping -c1 remotehostde node00, vemos:

    19:19:00.808202 IP 111.11.111.11 > 100.64.64.100: ICMP echo request, id 31, seq 1, length 64
19:19:00.808236 IP 100.64.64.100 > 111.11.111.11: ICMP echo reply, id 31, seq 1, length 64

    O caminho de node00para remotehost(a) tem o endereço de origem esperado e (b) está usando o caminho esperado. Similarmente, se tentarmos a mesma coisa de node01, veremos:

    19:19:58.209656 IP 111.11.111.12 > 100.64.64.100: ICMP echo request, id 33, seq 1, length 64
19:19:58.209717 IP 100.64.64.100 > 111.11.111.12: ICMP echo reply, id 33, seq 1, length 64

    Novamente, ele está usando o caminho esperado, e vemos que nosso endereço visível externamente é 111.11.111.12, como esperado de nossos mapeamentos NAT.

    Se tentarmos operações semelhantes a partir de nós em lan2, veremos em node10:

    19:21:08.356388 IP 222.22.222.11 > 100.64.64.100: ICMP echo request, id 35, seq 1, length 64
19:21:08.356433 IP 100.64.64.100 > 222.22.222.11: ICMP echo reply, id 35, seq 1, length 64

    E de node11:

    19:21:30.824730 IP 222.22.222.12 > 100.64.64.100: ICMP echo request, id 38, seq 1, length 64
19:21:30.824799 IP 100.64.64.100 > 222.22.222.12: ICMP echo reply, id 38, seq 1, length 64

    Até onde posso perceber, esse comportamento atende a todos os seus objetivos.

    • 0

relate perguntas