bao7uo's questions

Estou usando o Arch Linux (a versão de 32 bits) em um Raspberry Pi 3.

Quando tento adicionar qualquer regra -j SNATou a , não funciona - recebo uma mensagem de erro-j DNATiptables

iptables: No change/target/match by that name

Eu normalmente não tenho problemas com iptables. Por exemplo, o padrão INPUTe OUTPUTtem FORWARDmuitas regras. Além disso, POSTROUTINGcontém uma MASQUERADEregra que está funcionando bem para permitir que a LAN interna converse com a Internet.

Eu encontrei o SNATproblema ao tentar permitir que a Internet enviasse tráfego para o IP público para chegar a uma máquina na rede interna. Quando isso não funcionou, tentei regras mais simples e elas também não funcionaram. Então tentei adicionar DNATregras e tive o mesmo problema.

Posso adicionar minhas regras mais complexas ao PREROUTINGe POSTROUTINGsem especificar o -j DNATou -j SNATe então elas serão adicionadas e os contadores serão incrementados.

Abaixo estão alguns exemplos das tentativas mais simples de adicionar regras e erros -j SNAT. -j DNATNão importa o que SNATou DNATregra eu tente adicionar, o erro é sempre o mesmo mostrado abaixo.

[root@hostname ~]# iptables -F PREROUTING -t nat
[root@hostname ~]# iptables -A PREROUTING -t nat -d $public_IP -j DNAT --to-destination $internal_IP
iptables: No chain/target/match by that name.

[root@hostname ~]# iptables -F POSTROUTING -t nat
[root@hostname ~]# iptables -A POSTROUTING -t nat -o teql+ -j SNAT --to-source $public_IP
iptables: No chain/target/match by that name.

Detalhes do Linux e -t natconfiguração atual:

[root@hostname ~]# uname -a
Linux hostname.local 4.4.37-1-ARCH #1 SMP Fri Dec 9 19:03:41 MST 2016 armv7l GNU/Linux

[root@hostname ~]# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 18 packets, 1184 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
600 37155 MASQUERADE  all  --  *      teql+   0.0.0.0/0            0.0.0.0/0
[root@hostname ~]#

Aqui está uma lista de módulos Kernel carregados que podem ser relevantes caso ajude:

[root@hostname ~]# lsmod | grep ip
ipt_REJECT              1543  142
nf_reject_ipv4          3223  1 ipt_REJECT
ipt_MASQUERADE          1223  1
nf_nat_masquerade_ipv4  2893  1 ipt_MASQUERADE
iptable_nat             1812  1
nf_nat_ipv4             5573  1 iptable_nat
nf_nat                 15506  2 nf_nat_ipv4,nf_nat_masquerade_ipv4
nf_conntrack_ipv4      13768  7
nf_defrag_ipv4          1684  1 nf_conntrack_ipv4
nf_conntrack          101220  5 nf_nat,nf_nat_ipv4,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4
iptable_filter          1665  1
ip_tables              12280  2 iptable_filter,iptable_nat
x_tables               17670  5 ip_tables,ipt_MASQUERADE,xt_conntrack,iptable_filter,ipt_REJECT
ipv6                  370087  20

O Kernel do Linux antes do 3.6 usava o cache de rota para fazer o roteamento multipath IPv4, o que significava que o roteamento entre duas linhas/ISPs separados era bastante fácil. A partir da versão 3.6, o algoritmo mudou para ser por pacote, o que significa que alguns truques de marcador de tabela de rota/regra/iptables eram necessários para atingir as duas linhas/ISPs.

No entanto, se você tivesse duas linhas com o mesmo ISP que pudesse rotear um único IP para ambas as linhas por pacote de maneira balanceada/failover, a partir da versão 3.6 você poderia facilmente obter a ligação de linha (no nível do IP) por causa de o roteamento por pacote em ambas as direções.

A partir da versão 4.4, o kernel mudou novamente para balanceamento de carga baseado em fluxo baseado em um hash sobre os endereços de origem e destino.

Atualmente, estou executando o Kernel 4.4.36 e estou usando o roteamento de caminhos múltiplos em conexões PPPoE. Meu tráfego downstream do ISP é roteado pelas duas linhas separadas por pacote (um IP roteado para ambas as linhas). Isso me dá uma velocidade de download mais rápida do que a velocidade de uma linha individual. Quase a velocidade de ambas as linhas somadas. Funciona muito bem, vídeo do Skype, VoIP (UDP), YouTube etc.

Por ter uma experiência downstream tão boa, quero tentar upstream, mas meu tráfego upstream é roteado de acordo com o novo algoritmo baseado em fluxo em ambos os dispositivos ppp (que têm o mesmo endereço IP). Isso significa que não consigo atingir uma velocidade de upload mais rápida que a velocidade de uma única linha.

Existe uma maneira de configurar o Kernel atual para usar o algoritmo por pacote? Ou algum outro método para obter o roteamento multipath por pacote? Eu precisaria reverter para um Kernel mais antigo (o que não quero fazer por vários outros motivos)?

Meu ISP não suporta multi-link ppp.

Caso seja relevante, atualmente estou executando o Arch Linux ARMv7 em um Raspberry Pi 3.

Eu gostaria que o Apache escutasse no endereço ipv6 do link local em uma interface específica. Eu tenho a seguinte linha no meu httpd.conf:

Listen [fe80::a00:16ff:fe89:420f]:80

Que é baseado na documentação do Apache aqui: https://httpd.apache.org/docs/2.4/bind.html "endereços IPv6 devem ser colocados entre colchetes"

Os detalhes do meu sistema operacional/versão do Apache são os seguintes:

$ httpd -v
Server version: Apache/2.4.18 (Unix)
Server built:   Dec 14 2015 08:05:54
$ uname -rv
4.3.3-3-ARCH #1 SMP PREEMPT Wed Jan 20 08:12:23 CET 2016

O resultado mostrado usando journalctl -eé:

(22) Argumento inválido: AH00072: make_sock: não foi possível vincular ao endereço [fe80.....

O IPv6 está funcionando porque tenho escuta sshd e dnsmasq. Tentei anexar dois sufixos de ID de escopo diferentes ao endereço. Você pode usar o id da interface 3ou o nome net1como um scopeid em ambos ping6e sshd.

$ ip addr | grep -Po "^\d: \S+"
1: lo:
2: net0:
3: net1:

$ for scopeid in 3 net1; do ping6 -c 1 fe80::a00:16ff:fe89:420f%$scopeid; done | grep loss
1 packets transmitted, 1 received, 0% packet loss, time 0ms
1 packets transmitted, 1 received, 0% packet loss, time 0ms

sshd_config funciona com:ListenAddress fe80::a00:16ff:fe89:420f%3

ou:ListenAddress fe80::a00:16ff:fe89:420f%net1

Então, com tudo isso em mente, tentei o seguinte em httpd.conf

Ouça [fe80::a00:16ff:fe89:420f%3]:80

eListen [fe80::a00:16ff:fe89:420f%net1]:80

A adição de um dos scopeid fez com que o Apache falhasse no início do processo de inicialização. journalctl -emostra um erro de sintaxe ao analisar httpd.conf da seguinte forma:

AH00526: Erro de sintaxe na linha 52 de /etc/httpd/conf/httpd.conf:
Scope id não é suportado

O Apache escuta no localhost ipv6 se eu fizer issoListen [::1]:80

Eu esperaria Listen 80que o Apache se ligasse tanto ao ipv4 quanto ao ipv6, mas isso não acontece. Ele se liga apenas a endereços ipv6 - o netstat mostra:

tcp6  0  0    :::80    :::*     LISTEN

Nesse caso, o Apache aceita solicitações no endereço link-local em net1. Eu tenho que especificar 0.0.0.0:80ou um endereço ipv4 específico para que ele escute no ipv4.

Então, como faço o Apache ligar-se a um endereço local de link específico (não todos eles - quero evitar ouvir em outras interfaces) ou simplesmente não é possível para o Apache ouvir em um endereço ipv6 de link local?