Perguntas[networking](server)

Há pelo menos um ano, a impressora de rede do meu escritório tem despejado aleatoriamente páginas de rabiscos. Ou pelo menos a maior parte é rabiscos - alguns deles parecem solicitações HTTP. É formatado da mesma forma que a impressora faz quando você envia um arquivo de texto sem informações de estilo. Essas páginas são impressas a qualquer hora do dia, às vezes nas primeiras horas da manhã, às vezes tarde da noite. Estamos confusos quanto à causa, e estou preocupado que possa ser um problema de segurança de algum tipo. Incluí uma foto de algumas das páginas que ela imprimiu. O número de páginas é bastante esporádico, às vezes uma ou duas por dia, às vezes 30 ou 40. Alguma ideia?

Adendo : Trabalhei brevemente em dois outros locais em nossa organização que tinham esse problema. Um outro que não tinha. Cada local tem seu próprio conjunto de funcionários regulares.

Tenho uma conexão SSL com um servidor (owner-api.teslamotors.com) que trava com wget, curl ou openssl s_client. Estou mostrando a versão curl, pois ela fornece a maioria das mensagens de depuração:

# curl -iv https://owner-api.teslamotors.com 
*   Trying 18.203.70.200:443...
* Connected to owner-api.teslamotors.com (18.203.70.200) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs

Lá ele trava depois de ClientHello. Conexão TCP estabelecida com sucesso (também confirmada com telnet/nc). Outra conexão de rede, incluindo qualquer conexão SSL que eu tentei, funciona. Exceto owner-api.teslamotors.com:443.

Achei esta postagem falando sobre MTU e parecia absurdo. Mas reduzi o MTU do servidor e funcionou! Funciona com qualquer MTU <= 1420.

O servidor se conecta usando Ethernet (MTU 1500) a um roteador Mikrotik e de lá a conexão passa por um túnel WireGuard (MTU 1420). Estou ciente de que isso pode não ser o ideal, pois qualquer pacote IP do servidor >1420 precisará ser fragmentado. No entanto, isso é agnóstico de qualquer protocolo L4. SSL sobre TCP não deve se importar com fragmentação e MTU. No entanto, este host se importa.

Executei uma captura de pacotes na caixa Mikrotik e o tráfego não lista nada de anormal para mim:

O típico handshake TCP Num 1-3, depois ClientHello (Num 4-5) e ServerHello (Num 6-7). Nenhum tamanho de pacote chega perto do MTU e nenhuma outra mensagem ICMP que indicaria problemas com fragmentação etc.

Por comentário, aqui está a saída do tracepath:

# tracepath owner-api.teslamotors.com
 1?: [LOCALHOST]                      pmtu 1500
 1:  XX.XX.56.210                                          0.410ms 
 1:  XX.XX.56.210                                          0.198ms 
 2:  XX.XX.56.210                                          0.138ms pmtu 1420
 2:  XX.XX.56.185                                        151.394ms 
 3:  no reply
 4:  100.100.200.1                                       157.220ms 
 5:  10.75.0.193                                         154.068ms 
 6:  10.75.2.53                                          161.950ms asymm  7 
 7:  decix1.amazon.com                                   152.107ms asymm  8 
 8:  decix2.amazon.com                                   153.068ms 
 9:  no reply
 [...]

Estou realmente perdido, o que diabos está acontecendo aqui?

Por que essa conexão SSL falha?

Quando eu tenho pingum endereço IP de host na minha LAN, meu host transmite uma ARPsolicitação. Após receber uma ARPresposta do host de destino, ele inicia uma sessão de ICMP echomensagens com suas respostas.

Quando o host de destino está recebendo do ARP requestmeu host de origem, o host de destino está atualizando o ARPcache com as informações incorporadas na solicitação (já que a origem MAC addressestá presente no ARP request)?

Se sim, por que o host de destino às vezes envia outro ARP requestendereço IP para o meu host de origem e descarta todas ICMP echoas solicitações até receber um ARP replyretorno?

Observe que esse comportamento é ocasional e, às vezes, a ICMP echoresposta é feita antes de um ARP requestdo meu host de destino, mas esse tipo de resposta ARP requestsempre ocorre em algum lugar no meio de uma sessão de ping.

Não sei se isso se deve à atualização das tabelas ARP dos hosts de sessões de ping anteriores ou se o segundo ARP requesté apenas um protocolo e o host de destino já tem as informações do host de origem MAC addressdo primeiro ARP request.

Ou será que o host de destino nem precisa do host de origem MAC addressem primeiro lugar, já que ele é sempre encapsulado em cada ICMP echosolicitação e a resposta a cada uma dessas solicitações usa as informações recebidas sobre eles MAC addressese os alterna no quadro de resposta?

Edição 1: Após alguma pesquisa, descobri que o host de destino não preenche seu próprio ARP cachepassivo ARP requests, ou seja, de solicitações de outros hosts. Ele preenche seu ARP cachesomente das ARPrespostas que recebe de suas próprias solicitações.

Edição 2: Seguindo de Edit 1, o segundo ARP requestdo host de destino antes de qualquer ICMP echoresposta indica que a origem MAC addressnão está em seu ARP cacheou se tornou STALE, acionando assim outro ARP requestantes de responder à ICMP echosolicitação. (Às vezes, um STALEendereço é primeiro verificado por meio de uma sondagem e, se o mapeamento for inválido ou a sondagem expirar, a nova sondagem ARP requestocorre.

Assim, o segundo ARP requestocorrendo no meio da pingsessão, indica que a fonte MAC addresstinha se tornado STALEno meu host de destino ARP cachedevido a alguns ARP timeout value(configurado em 60 segundos em meus hosts), o que disparou um segundo ARP request. Além disso, essas segundas ARPsolicitações esclarecem que, embora o host de destino não precise que a fonte MAC addressseja preenchida em seu ARP cachee use as informações sobre ARP requesta fonte MAC addresspara responder a ela, ele realmente precisa saber a fonte MAC addresspara responder a uma TCMP echosolicitação.

Ainda assim, quaisquer respostas que elaborem ou corrijam quaisquer erros nas descobertas acima são muito apreciadas.

Quando estou na minha rede local (sub-rede?), gostaria de ir para sub1.myserver.come que funcionasse da mesma forma que ir para 192.168.1.99:1234- ou seja, o objetivo seria usar o mesmo nome de domínio que também uso publicamente para este servidor, obtendo, por exemplo, velocidades de download da LAN.

Minha configuração:

Tenho vários serviços em execução em portas diferentes, por exemplo: 192.168.1.99:1234e 192.168.1.99:5678no meu servidor Debian Bookworm.

Meu DNS (porkbun) tem Aregistros para meus IPs públicos -> nomes de (sub)domínios.

E eu tenho um proxy nginx fazendo proxy_passcoisas como sub1.myserver.com-> 0.0.0.0:1234e sub2.myserver.com-> 0.0.0.0:5678.

Isso funciona muito bem e posso acessar meu servidor publicamente via sub1.myserver.com.

Também posso, é claro, ir 192.168.1.99:1234diretamente e conectar-me ao mesmo aplicativo via LAN.

Como posso reutilizar o mesmo domínio para conexões LAN locais e, se não for possível/não aconselhável, qual seria a próxima melhor solução?

Este problema parece trivial a princípio, mas não é, e provavelmente não é totalmente específico do Postfix/Dovecot. Seria ótimo se alguém pudesse me dar uma dica...

A configuração é a seguinte: Tenho um servidor de nomes (BIND) e um combo Postfix/Dovecot rodando na mesma máquina. Ele tem 1 endereço IPv4 (esses são escassos...) e vários endereços IPv6. No começo, todos os servidores estavam rodando em todas as interfaces, ou seja, escutando em 0.0.0.0e [::], mas então decidi dar a eles IPv6 separados ("porque podemos..."). Na v4 eles permanecem no mesmo IP.

Durante a configuração inicial e os testes, tudo funcionou bem. No final, decidi reiniciar a máquina só para ter certeza de que não há nenhuma configuração obsoleta/temporária à espreita e que tudo funciona como esperado após uma inicialização limpa.

E então aconteceu o seguinte (registro reduzido às partes relevantes):

...
Nov 30 22:49:52 systemd[1]: Finished networking.service - Raise network interfaces.
Nov 30 22:49:52 systemd[1]: Reached target network.target - Network.
Nov 30 22:49:52 systemd[1]: Reached target network-online.target - Network is Online.
Nov 30 22:49:52 systemd[1]: Starting dovecot.service - Dovecot IMAP/POP3 email server...
Nov 30 22:49:52 systemd[1]: Starting named.service - BIND Domain Name Server...
Nov 30 22:49:52 systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
Nov 30 22:49:52 named[984]: starting BIND 9.20.2-1-Debian (Stable Release) <id:>
Nov 30 22:49:52 named[984]: running on Linux x86_64 6.11.5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.5-1 (2024-10-27)
...
Nov 30 22:49:52 named[984]: listening on IPv4 interface lo, 127.0.0.6#53
Nov 30 22:49:52 named[984]: listening on IPv4 interface enp5s0, 88.198.70.58#53
Nov 30 22:49:52 named[984]: listening on IPv6 interface enp5s0, 2a01:4f8:140:501a::b00d#53
...
Nov 30 22:49:52 dovecot[983]: Error: bind(2a01:4f8:140:501a::d19c, 587) failed: Cannot assign requested address
Nov 30 22:49:52 dovecot[983]: Error: service(submission-login): listen(2a01:4f8:140:501a::d19c, 587) failed: Cannot assign requested address
Nov 30 22:49:52 dovecot[983]: Error: bind(2a01:4f8:140:501a::d19c, 143) failed: Cannot assign requested address
Nov 30 22:49:52 dovecot[983]: Error: service(imap-login): listen(2a01:4f8:140:501a::d19c, 143) failed: Cannot assign requested address
Nov 30 22:49:52 dovecot[983]: Error: bind(2a01:4f8:140:501a::d19c, 993) failed: Cannot assign requested address
Nov 30 22:49:52 dovecot[983]: Error: service(imap-login): listen(2a01:4f8:140:501a::d19c, 993) failed: Cannot assign requested address
Nov 30 22:49:52 dovecot[983]: Fatal: Failed to start listeners
Nov 30 22:49:52 systemd[1]: dovecot.service: Main process exited, code=exited, status=89/n/a
Nov 30 22:49:52 systemd[1]: dovecot.service: Failed with result 'exit-code'.
Nov 30 22:49:52 systemd[1]: Failed to start dovecot.service - Dovecot IMAP/POP3 email server.
...
Nov 30 22:49:52 systemd[1]: Started named.service - BIND Domain Name Server.
Nov 30 22:49:52 systemd[1]: Reached target nss-lookup.target - Host and Network Name Lookups.
Nov 30 22:49:52 systemd[1]: Starting [email protected] - Postfix Mail Transport Agent (instance -)...
Nov 30 22:49:52 postmulti[1141]: postfix/postlog: starting the Postfix mail system
Nov 30 22:49:52 postfix/master[1143]: fatal: bind 2a01:4f8:140:501a::d19c port 25: Cannot assign requested address
Nov 30 22:49:54 postmulti[1145]: postfix/postlog: fatal: mail system startup failed
Nov 30 22:49:55 systemd[1]: [email protected]: Control process exited, code=exited, status=1/FAILURE
Nov 30 22:49:55 systemd[1]: [email protected]: Failed with result 'exit-code'.
Nov 30 22:49:55 systemd[1]: Failed to start [email protected] - Postfix Mail Transport Agent (instance -).

Note que o BIND inicia com sucesso em todas as interfaces. O Dovecot inicia em paralelo e gera um erro ao tentar escutar em um IPv6 separado. (O log não diz nada sobre IPv4 e localhost, então ou funciona, ou o erro IPv6 vem primeiro.) O Postfix encontra o mesmo erro ao tentar escutar no mesmo IPv6.

Agora, a questão é que, quando eu inicio esses serviços manualmente após a inicialização via systemctl start, ambos inicializam sem problemas. E eles realmente funcionam em todas as interfaces.

Então meu pensamento inicial foi que há algum tipo de condição de corrida durante o processo de inicialização, de modo que nem todas as interfaces IPv6 são realmente ativadas, antes do início do Dovecot/Postfix. O que não deveria ser possível, já que todas elas dependem de network-online.target, que de acordo com o systemd é totalmente concluído antes do BIND iniciar a inicialização.

Então eu troquei o Dovecot para rodar no mesmo IPv6 (:b00d) que o BIND, já que ele inicializa com sucesso naquele IP. O Postfix ainda está no IP original (:d19c). Ao mesmo tempo, eu também criei um "serviço" fictício que apenas exibe a configuração de rede durante o processo de inicialização, para que eu possa ver o que o Dovecot e o Postfix estão vendo durante a inicialização. Eu fiz esse serviço rodar duas vezes - uma antes do BIND/Postfix/Dovecot, e uma depois.

O resultado final é: a) O Dovecot ainda falha mesmo quando se usa o mesmo IP do BIND . b) de acordo com ifconfigtodos os IPv6s que estão realmente configurados e ativos antes do início dos serviços (como deveria ser)

Dec 01 19:52:16 systemd[1]: Finished networking.service - Raise network interfaces.
Dec 01 19:52:16 systemd[1]: Reached target network.target - Network.
Dec 01 19:52:16 systemd[1]: Reached target network-online.target - Network is Online.
Dec 01 19:52:16 systemd[1]: Starting named.service - BIND Domain Name Server...
Dec 01 19:52:16 systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
Dec 01 19:52:16 systemd[1]: Reached target getty.target - Login Prompts.
Dec 01 19:52:16 named[981]: starting BIND 9.20.2-1-Debian (Stable Release) <id:>
Dec 01 19:52:16 named[981]: running on Linux x86_64 6.11.5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.5-1 (2024-10-27)
...
Dec 01 19:52:16 named[981]: listening on IPv4 interface lo, 127.0.0.6#53
Dec 01 19:52:16 named[981]: listening on IPv4 interface enp5s0, 88.198.70.58#53
Dec 01 19:52:16 named[981]: listening on IPv6 interface enp5s0, 2a01:4f8:140:501a::b00d#53
...
Dec 01 19:52:16 systemd[1]: Started named.service - BIND Domain Name Server.
Dec 01 19:52:16 systemd[1]: Reached target nss-lookup.target - Host and Network Name Lookups.
Dec 01 19:52:16 systemd[1]: Starting dovecot.service - Dovecot IMAP/POP3 email server...
Dec 01 19:52:16 systemd[1]: Starting test-networking.service - ###################### Test Network Configuration ###########################...
Dec 01 19:52:16 ip[992]: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
Dec 01 19:52:16 ip[992]:     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
Dec 01 19:52:16 ip[992]:     inet 127.0.0.1/8 scope host lo
Dec 01 19:52:16 ip[992]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[992]:     inet 127.0.0.3/8 brd 127.0.0.0 scope host secondary lo
Dec 01 19:52:16 ip[992]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[992]:     inet 127.0.0.6/8 brd 127.0.0.0 scope host secondary lo
Dec 01 19:52:16 ip[992]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[992]:     inet6 ::1/128 scope host noprefixroute
Dec 01 19:52:16 ip[992]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[992]: 2: enp5s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
Dec 01 19:52:16 ip[992]:     link/ether a8:a1:59:08:49:5d brd ff:ff:ff:ff:ff:ff
Dec 01 19:52:16 ip[992]:     inet 88.198.70.58/27 brd 88.198.70.63 scope global enp5s0
Dec 01 19:52:16 ip[992]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[992]:     inet6 2a01:4f8:140:501a::d19c/64 scope global tentative
Dec 01 19:52:16 ip[992]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[992]:     inet6 2a01:4f8:140:501a::b00d/64 scope global tentative
Dec 01 19:52:16 ip[992]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[992]:     inet6 2a01:4f8:140:501a::2/64 scope global tentative
Dec 01 19:52:16 ip[992]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 systemd[1]: test-networking.service: Deactivated successfully.
Dec 01 19:52:16 systemd[1]: Finished test-networking.service - ###################### Test Network Configuration ###########################.
Dec 01 19:52:16 dovecot[991]: Error: bind(2a01:4f8:140:501a::d19c, 587) failed: Cannot assign requested address
Dec 01 19:52:16 dovecot[991]: Error: service(submission-login): listen(2a01:4f8:140:501a::d19c, 587) failed: Cannot assign requested address
Dec 01 19:52:16 dovecot[991]: Error: bind(2a01:4f8:140:501a::d19c, 143) failed: Cannot assign requested address
Dec 01 19:52:16 dovecot[991]: Error: service(imap-login): listen(2a01:4f8:140:501a::d19c, 143) failed: Cannot assign requested address
Dec 01 19:52:16 dovecot[991]: Error: bind(2a01:4f8:140:501a::d19c, 993) failed: Cannot assign requested address
Dec 01 19:52:16 dovecot[991]: Error: service(imap-login): listen(2a01:4f8:140:501a::d19c, 993) failed: Cannot assign requested address
Dec 01 19:52:16 dovecot[991]: Fatal: Failed to start listeners
Dec 01 19:52:16 systemd[1]: dovecot.service: Main process exited, code=exited, status=89/n/a
Dec 01 19:52:16 systemd[1]: dovecot.service: Failed with result 'exit-code'.
Dec 01 19:52:16 systemd[1]: Failed to start dovecot.service - Dovecot IMAP/POP3 email server.
Dec 01 19:52:16 systemd[1]: Reached target multi-user.target - Multi-User System.
Dec 01 19:52:16 systemd[1]: Reached target graphical.target - Graphical Interface.
Dec 01 19:52:16 systemd[1]: Starting [email protected] - Postfix Mail Transport Agent (instance -)...
Dec 01 19:52:16 systemd[1]: Starting test-networking2.service - ********************** Second Test Network Configuration ****************************...
Dec 01 19:52:16 ip[998]: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
Dec 01 19:52:16 ip[998]:     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
Dec 01 19:52:16 ip[998]:     inet 127.0.0.1/8 scope host lo
Dec 01 19:52:16 ip[998]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[998]:     inet 127.0.0.3/8 brd 127.0.0.0 scope host secondary lo
Dec 01 19:52:16 ip[998]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[998]:     inet 127.0.0.6/8 brd 127.0.0.0 scope host secondary lo
Dec 01 19:52:16 ip[998]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[998]:     inet6 ::1/128 scope host noprefixroute
Dec 01 19:52:16 ip[998]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[998]: 2: enp5s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
Dec 01 19:52:16 ip[998]:     link/ether a8:a1:59:08:49:5d brd ff:ff:ff:ff:ff:ff
Dec 01 19:52:16 ip[998]:     inet 88.198.70.58/27 brd 88.198.70.63 scope global enp5s0
Dec 01 19:52:16 ip[998]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[998]:     inet6 2a01:4f8:140:501a::d19c/64 scope global tentative
Dec 01 19:52:16 ip[998]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[998]:     inet6 2a01:4f8:140:501a::b00d/64 scope global tentative
Dec 01 19:52:16 ip[998]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 ip[998]:     inet6 2a01:4f8:140:501a::2/64 scope global tentative
Dec 01 19:52:16 ip[998]:        valid_lft forever preferred_lft forever
Dec 01 19:52:16 systemd[1]: test-networking2.service: Deactivated successfully.
Dec 01 19:52:16 systemd[1]: Finished test-networking2.service - ********************** Second Test Network Configuration ****************************.
Dec 01 19:52:17 postmulti[1143]: postfix/postlog: starting the Postfix mail system
Dec 01 19:52:17 postfix/master[1145]: fatal: bind 2a01:4f8:140:501a::d19c port 25: Cannot assign requested address
Dec 01 19:52:19 kernel: r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control rx/tx
Dec 01 19:52:19 postmulti[1146]: postfix/postlog: fatal: mail system startup failed
Dec 01 19:52:20 systemd[1]: [email protected]: Control process exited, code=exited, status=1/FAILURE
Dec 01 19:52:20 systemd[1]: [email protected]: Failed with result 'exit-code'.
Dec 01 19:52:20 systemd[1]: Failed to start [email protected] - Postfix Mail Transport Agent (instance -).
Dec 01 19:52:20 systemd[1]: Startup finished in 3.180s (kernel) + 6.272s (userspace) = 9.453s.
...
Dec 01 19:54:04 systemd[1]: Starting dovecot.service - Dovecot IMAP/POP3 email server...
Dec 01 19:54:04 systemd[1]: Started dovecot.service - Dovecot IMAP/POP3 email server.
Dec 01 19:54:10 systemd[1]: Starting [email protected] - Postfix Mail Transport Agent (instance -)...
Dec 01 19:54:10 postmulti[1341]: postfix/postlog: warning: symlink leaves directory: /etc/postfix/./postfix-files
Dec 01 19:54:10 postmulti[1375]: postfix/postlog: starting the Postfix mail system
Dec 01 19:54:10 systemd[1]: Started [email protected] - Postfix Mail Transport Agent (instance -).
Dec 01 19:54:10 systemd[1]: Starting postfix.service - Postfix Mail Transport Agent...
Dec 01 19:54:10 systemd[1]: Finished postfix.service - Postfix Mail Transport Agent.

Novamente, após a inicialização, posso iniciar ambos os serviços manualmente - sem erros.

Alguém tem alguma ideia do que está acontecendo? Encontrei alguns relatos semelhantes na internet, mas todos eles têm causas que podem ser descartadas no meu caso.

Obrigado por qualquer feedback!

EDIT : Substitua o segundo log onde ip addré usado em vez de ifconfigpara mostrar a configuração de rede atual durante o tempo de inicialização. Também incluí as linhas que mostram o início manual do Dovecot/Postfix 2 minutos após a inicialização - sem erros.

EDIT2: Os IPs adicionais são configurados por meio de um arquivo sob /etc/network/interfaces.d/o qual no Debian é originado por /etc/network/interfaces. Ambos os arquivos são processados ​​em uma etapa durante a inicialização quando networking.serviceé iniciado. Este é o snippet:

iface enp5s0 inet6 static
  address 2a01:4f8:140:501a::b00d/64

iface enp5s0 inet6 static
  address 2a01:4f8:140:501a::d19c/64

Tradicionalmente, essas seriam interfaces com alias (enp5s0:1, :2, etc.), mas elas parecem estar obsoletas agora, então a maneira acima é aparentemente a preferida para configurar IPs adicionais atualmente.

Em uma VM Debian 12, tenho 2 interfaces de rede configuradas, a saber, eth0e eth1. Ambas as interfaces têm acesso à Internet e configuradas para autoconfiguração SLAAC.

Como ambas as redes têm um roteador, minha tabela de roteamento nesta VM acaba ficando assim:

2a01:xxxx:xxxx:xxxx::/64 dev eth1 proto kernel metric 256 expires 86388sec pref medium
fd45:xxxx:xxxx:xxxx::/64 dev eth0 proto kernel metric 256 expires 2591988sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
default via fe80::xxxx:xxxx:xxxx:xxxx dev eth1 proto ra metric 1024 expires 1788sec hoplimit 64 pref medium
default via fe80::be24:xxxx:xxxx:xxxx dev eth0 proto ra metric 1024 expires 1788sec pref medium

Nos primeiros dias, tudo estava bem, e eu conseguia acessar o conteúdo interno por fd45::meio de eth0. No entanto, ele quebrou de repente agora, com todo o tráfego de saída roteado por meio de eth1, conforme descrito por traceroute.

Quero forçar conexões de saída a usar eth0. Posso remover temporariamente a rota padrão em eth1usando , ip -6 route del default dev eth1mas ela voltaria em alguns minutos. Existe alguma maneira de conseguir isso?

O meu /etc/network/interfacesé assim:

auto lo
iface lo inet loopback

auto eth0
auto eth1
iface eth1 inet6 auto

iface eth0 inet dhcp

iface eth0 inet6 auto

A AWS fornece listas de intervalos de IP para seus serviços e documentação, se disponível, para " Obter todos os endereços IPv4 para um serviço específico em uma região específica ". No entanto, os serviços da lista dificilmente são específicos.

Existe uma maneira de recuperar intervalos de IP usados ​​especificamente para o AWS Lambda?

Primeiramente gostaria de explicar que estou dando meus primeiros passos em networking em geral e no GCP em particular. Por isso peço desculpas se a pergunta não fizer sentido.

Estou enfrentando um desafio ao rotear tráfego de uma sub-rede na Europa por meio de um túnel VPN baseado nos Estados Unidos.

Aqui estão os detalhes:

• Detalhes da sub-rede: localizada em europe-west1, contendo 2 instâncias
• Túnel VPN: configurado nos EUA, com o gateway Cloud VPN no oeste dos EUA
• Problema: Não é possível adicionar a sub-rede europe-west1 ao túnel devido a diferenças regionais

Limitações atuais:

• Não é possível modificar o outro lado do túnel
• Não é possível realocar o Gateway para europe-west1, pois isso resultaria na perda do IP configurado no outro lado do túnel
• Não é possível selecionar um intervalo diferente de IPs locais para o túnel.
• Não é possível mover as instâncias de europe-west1 para outra região

Soluções tentadas:

• Tabelas de roteamento verificadas
• Tentei criar um Cloud NAT entre as duas sub-redes, mas essa abordagem não funciona, pois ambas as sub-redes devem estar na mesma região
• Tentativa de peering de VPC, que produziu o mesmo resultado

Pergunta principal: Existe um método para rotear tráfego de instâncias em uma região (europe-west1) por meio de um túnel VPN configurado em uma região diferente (us-west)?

A única coisa que consigo pensar é criar outra instância em uma sub-rede nos EUA que atue como um proxy entre as instâncias na Europa e o túnel, mas parece uma solução muito ineficiente e gostaria de saber se há alguma alternativa que me escape.

Tenho um servidor com dois endereços IP anexados a uma única interface:

2: enp27s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 30:9c:23:83:64:f6 brd ff:ff:ff:ff:ff:ff
    inet [IP_1]/32 scope global noprefixroute enp27s0
       valid_lft forever preferred_lft forever
    inet [IP_2]/32 scope global enp27s0
       valid_lft forever preferred_lft forever
    inet6 [IP6_1]/64 scope link
       valid_lft forever preferred_lft forever

E eu tenho algumas máquinas virtuais rodando nele e sempre que elas se comunicam com o mundo externo, seus pacotes são obtidos IP_1como o IP de origem. Eu também tenho uma VM específica que eu gostaria de "rotear" através IP_2dela. Eu não quero anexá-la inteiramente a esse endereço IP, eu ainda preferiria que ela ficasse dentro da rede virtual, mas eu quero que todos os pacotes que saem dela tenham IP_2como seu IP de origem.

Tentei aplicar uma tradução SNAT para conseguir isso, mas não funcionou:

iptables -t nat -A POSTROUTING -s [VM_IP] -o enp27s0 -j SNAT --to-source [IP_2]

Eu assumo que é porque quando os pacotes terminam o roteamento eles já têm IP_1como IP de origem e a -s [VM_IP]parte da regra não corresponde. Alterar isso para -s [IP_1]ou apenas definir IP_2como IP primário pode funcionar provavelmente, mas eu meio que preciso que outras VMs tenham seu tráfego de saída roteado por IP_1.

Há alguma maneira de conseguir isso? Tenho certeza de que uma pergunta como essa já foi feita aqui antes, mas infelizmente minha inexperiência me impede de pensar em palavras-chave para colocar na barra de pesquisa para encontrá-la :(

Atualização: aqui estão minhas regras de tabela POSTROUTING (excluindo aquela regra SNAT):

# iptables -t nat -S POSTROUTING
-P POSTROUTING ACCEPT
-A POSTROUTING -j LIBVIRT_PRT

# iptables -t nat -S LIBVIRT_PRT
-N LIBVIRT_PRT
-A LIBVIRT_PRT -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A LIBVIRT_PRT -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE

Estou procurando conselhos sobre quais configurações ajustar/testar e/ou o que fazer para diagnosticar melhor esse problema, pois não sou especialista em redes e há centenas de configurações nos roteadores, etc.

Tenho um túnel VPN IPsec Lan-to-Lan da DrayTek configurado entre dois sites, principalmente para gerenciar a segurança no site remoto (CFTV/alarme/portão etc.).

Tudo funciona bem, na maioria das vezes. Do site local (192.168.1.X), consigo ver todos os dispositivos no site remoto (172.19.0.X), consigo conectar-me às interfaces web dos dispositivos, consigo transmitir feeds de câmeras, controlar dispositivos, etc.

No entanto, uma coisa que não funciona são as atualizações remotas de firmware de dispositivos. Por exemplo, uma atualização de firmware de câmera que envolve um upload de 75 MB sempre falha.

Se eu abrir uma porta no roteador, posso atualizar uma câmera remotamente pela internet usando o mesmo arquivo de firmware, então sei que esse lado está tudo bem. Só não funciona no túnel IPsec e eu gostaria de consertar isso.

Desde então, confirmei que esse é um problema geral de "upload" ao testar grandes uploads de FTP do mesmo site local para um site remoto. Eles falham (travam) na VPN.

SITE LOCAL:

WAN: Fibre Internet 
DrayTek Vigor2926
DrayTek Lan to Lan accepts Dial-In:
IPsec Tunnel (IKEv1/IKEv2)
Pre-Shared Key / Medium (AH) AES

SITE REMOTO:

WAN: 3G/4G LTE Modem
DrayTek Vigor2865
DrayTek Lan to Lan Dial-Out:
IPsec Tunnel IKEv2
Pre-Shared Key / Poposal Encryption Auto
IKE Phase 2 Settings: ESP (High) AES256 
Proposal Authentication: All

EDIT 1 - Configurações de MTU nos roteadores:

O Local Site WAN em Internet Access -> Static or Dynamic IPestá definido como 1500. O Remote Site WAN em Internet Access -> 3G/4G/5G Modem(DHCP mode)está definido como 1500(o padrão de acordo com o texto ali).

EDIT 2 - Valor de MTU do teste de ping:

Encontrei um script de teste de ping aqui que usei para encontrar o tamanho máximo de MTU da seguinte maneira:

• Do site local para o site remoto via VPN:1500
• Do site local para o site remoto via WAN:1500
• Da minha casa para o site local via WAN:1492
• Da minha casa para o site remoto via WAN:1492

EDIT 3 - Isso PARECE ser um problema de MTU, mas ainda não entendi completamente:

O adaptador de rede no site local tem a MTU definida como 1500se eu alterasse temporariamente para um valor menor, por exemplo:

sudo ifconfig enp6s0 mtu 1360

Então um upload de teste ftp funciona na VPN. Mas eu consideraria isso uma solução alternativa, não uma solução.

Olhei mais de perto as configurações do roteador e descobri que VPN and Remote Access -> IPsec General Setuphá uma configuração VPN TCP maximum segment size (MSS)para IPsec (IKEv1/IKEv2)que pode ser entre 512 and 1381e o padrão é 1360. Pensei que talvez essa fosse a resposta, e alterar a configuração para um valor muito baixo ( 512) afeta o teste de ping (ele retorna um valor máximo de MTU de 1044), mas isso ainda não afeta o funcionamento dos uploads pela VPN.

Não entendo por que o teste de ping diz que a MTU máxima é 1500, mas preciso alterar a configuração de MTU do adaptador de rede para que os uploads funcionem e, aparentemente, nenhuma alteração nas configurações do roteador DrayTek permite que os uploads funcionem em sua própria VPN IPSec.