Recentemente, coloquei em contêiner meu servidor web pessoal. No entanto, percebi agora que não é mais acessível por IPv6. O mapeamento de portas ( -p 80:80 -p 443:443
) só funciona para IPv4:https://github.com/containers/podman/issues/4323.
Até agora, consegui obter do pod seu próprio endereço ULA IPv6 adicionando
[
{
"subnet": "fc01::/48",
"gateway": "fc01::1"
}
]
para /etc/cni/net.d/87-podman-bridge.conflist. Então agora posso curl 'http://[fc01::1]'
a partir do próprio host. Mas não consigo descobrir a ip6tables
mágica para encaminhar solicitações do IP público para o contêiner. Baseado emhttps://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html, Eu tentei
# ip6tables -t nat -A POSTROUTING -o eth0 -s fc01::1/48 -j MASQUERADE
# ip6tables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination '[fc01::1]:80'
# ip6tables -A FORWARD -i eth0 -o cni-podman0 -p tcp --dport 80 -j ACCEPT
e vários subconjuntos desses comandos, mas recebo tempos limite ou "Sem rota para o host".
Meus endereços são assim:
$ 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
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether f2:3c:91:c8:5b:d9 brd ff:ff:ff:ff:ff:ff
inet <PUBLIC IPv4>/24 brd <BROADCAST> scope global eth0
valid_lft forever preferred_lft forever
inet6 <PUBLIC IPv6>/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 2591999sec preferred_lft 604799sec
inet6 fe80::f03c:91ff:fec8:5bd9/64 scope link
valid_lft forever preferred_lft forever
3: cni-podman0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b6:58:df:4b:b9:71 brd ff:ff:ff:ff:ff:ff
inet 10.88.0.1/16 brd 10.88.255.255 scope global cni-podman0
valid_lft forever preferred_lft forever
inet6 fc01::1/48 scope global
valid_lft forever preferred_lft forever
inet6 fe80::b458:dfff:fe4b:b971/64 scope link
valid_lft forever preferred_lft forever
4: vethb4059020@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cni-podman0 state UP group default
link/ether d6:5d:37:f2:0c:48 brd ff:ff:ff:ff:ff:ff link-netns cni-26c430c8-c816-8962-b2f2-b3bbb5274f93
inet6 fe80::d45d:37ff:fef2:c48/64 scope link
valid_lft forever preferred_lft forever
Responder1
Não, você não precisa de encaminhamento de porta. O contêiner obtém um endereço IP exclusivo; o destino énãoo host.
Digamos por exemplo:
- Seurede ULA gerada aleatoriamente era
fdab:9bac:936f::/48
- Dado
fdab:9bac:936f:0ca2::/64
a um host para contêineres - Suas tabelas de rotas encaminham a sub-rede do contêiner para o host adequado.
- Atribuído
fdab:9bac:936f:0ca2::443
a este contêiner de servidor web (IP personalizado via endereçamento estático) - Acontece que o host tem um IP de
fdab:9bac:936f:1292::359
(sub-rede diferente)
Em seguida, acesse o contêiner do servidor web em fdab:9bac:936f:0ca2::443
. Se a única coisa em execução no contêiner for um servidor web, essas serão as únicas portas abertas (80 e 443).
Apenas recentemente a rede de contêineres habilitou configurações IPv6 sensatas que ignoram o NAT. Minha leitura do problemapodman e IPv6é aquelePlug-ins CNItem os recursos para definir atribuição de endereço IP e rotas push. Se você optar por fazer redes de contêineres dessa forma.
ULA não é ideal. Não será roteado pela Internet. As políticas de seleção de endereços têm prioridade mais baixa que o IPv4.
Internet roteável é melhor. Infelizmente, você ofuscou seu endereço IP.