All perguntas(server)

Tenho um servidor Ubuntu 22.04, um switch MikroTik CRS328-24P-4S+RM e câmeras conectadas à Ethernet. Eu queria aumentar o MTU em todos os sistemas para que os quadros jumbo fossem transferidos, para reduzir a carga da CPU no servidor ao receber fluxos HD de muitas câmeras, no entanto, notei que mesmo com as configurações de MTU padrão (1500 bytes), as câmeras já enviam quadros jumbo.

Em mais detalhes:

• no servidor ip lmostra para a interface de rede: 2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000; ou seja, MTU 1500.
• na interface web de gerenciamento do switch, verifiquei o MTU para a interface em direção ao servidor e para as interfaces em direção às câmeras. Eles estão definidos como MTU = 1500 e L2 MTU = 1592.
• as câmeras não sei como verificar o MTU (elas são uma caixa-preta para mim).

Verifiquei o tamanho dos pacotes transferidos:

• no servidor, olhei os pacotes com tcpdump. tcpdump -i eno2 -s 100 -e | lessmostra pacotes como este: 16:25:06.315612 <MAC redacted> (oui Unknown) > <MAC redacted> (oui Unknown), ethertype IPv4 (0x0800), length 9014: camera1.3957 > server.46179: UDP, length 8972. Os pacotes ethernet têm um tamanho de 9014 bytes.

• Desativei o "offloading" no servidor, conforme ethtool --offload eno2 rx off tx offdescrito em https://wiki.wireshark.org/CaptureSetup/Offloading .

• no switch, posso ver que a interface para uma câmera tem uma taxa RX de ~500 Mbps e uma taxa de pacote RX de ~7000 p/s. Isso resulta em ((500/8)*1024*1024)/7000= ~9362 bytes/pacote.

Questões:

• cometi algum erro na minha análise acima?

• É possível que dispositivos de rede enviem pacotes UDP maiores que a MTU configurada de dispositivos intermediários?

Apêndice:

Resultados de ethtool --show-offload eno2:

Features for eno2:
rx-checksumming: off
tx-checksumming: off
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: off
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
        tx-tcp-segmentation: off [requested on]
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: off [requested on]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: on
receive-hashing: on
highdma: off [fixed]
rx-vlan-filter: on
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: on
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: on
tx-gso-list: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: on
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]

Estou executando um pacote nginx padrão no Debian Bookworm. Normalmente, estou apenas usando as conexões HTTPS para esse serviço e está tudo bem. O padrão para a porta HTTP 80 é um redirecionamento para o protocolo HTTPS.

server {
  listen 80 default_server;
  listen [::]:80 default_server;
  server_tokens off;

  return 301 https://$host$request_uri;

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log error;
}

// vhosts with listen 443 configs omited here, they work

Tenho um cliente IoT que não fala HTTPS. Então, configurei-o para usar HTTP para enviar dados do sensor para uma url de hook no servidor Nginx. Adicionei um VHost para esse domínio local xyz, que não encaminha a solicitação para HTTPS, mas a processa com HTTP simples.

server {
  listen 80;
  listen [::]:80;
  server_name xyz;
  server_tokens off;

  location / {
    root /var/www/html/;
  }

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log error;
}

// vhosts with listen 443 configs omited here, they work

Mas essa solicitação nunca é processada pelo Nginx.

Usando curl, estou recebendo esta resposta

# curl -v http://localhost/
*   Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.88.1
> Accept: */*
> 
* Received HTTP/0.9 when not allowed
* Closing connection 0
curl: (1) Received HTTP/0.9 when not allowed

(Info: Nginx está escutando em todos os dispositivos, nenhum firewall está ativo, quando paro o serviço, a porta é fechada no Linux...).

Não há nenhuma mensagem de log de erro nem no journald, nem nos logs de acesso ou de erro do nginx.

Então tentei fazer o hardcore telnetna porta 80 e obtive um resultado mais estranho:

# telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Connection closed by foreign host.

Para esclarecer, eu digitei GET / HTTP/1.1\nsem uma segunda linha vazia, apenas um "enter". Quando eu digito algo que não é compatível com HTTP, como uma string aleatória, o servidor responde com ??.

Então, logo após a primeira linha, o Nginx está fechando a conexão (a resposta HTTP/0.9 vem do próprio curl).

Como não consegui definir o Host:cabeçalho na solicitação telnet, essa solicitação nunca verifica nenhuma configuração de host virtual e presumo que o cliente curl tenha o mesmo problema. Ele tenta enviar todos os cabeçalhos para o soquete, mas a resposta Nginx já está lá.

Não tenho ideia do que está errado. O servidor deve pelo menos esperar pelo Host-header antes de fechar a conexão. O /etc/nginx/nginx.confnão é alterado.

De acordo com nginx -ta configuração está ok, o servidor responde normalmente em curl -v https://localhost/. A configuração SSL etc. é omitida aqui. Está funcionando.

Tenho um dispositivo (Blackmagic 2110 IP Converter 3x3G) conectado ao meu PC que está me enviando um fluxo de vídeo ST-2110 por 239.255.2.164.

Preciso receber esses dados.

Minha NIC não tem nenhum endereço IP atribuído a ela. Qual endereço IP devo dar a ela? Você pode fornecer o comando (Linux) para atribuir o endereço IP (junto com a máscara de rede)

Estou escrevendo um aplicativo C++ que usará socket para receber esse fluxo. Provavelmente usarei código semelhante a este: https://stackoverflow.com/questions/9243292/subscribing-to-multiple-multicast-groups-on-one-socket-linux-c

isto é baseado em respostas para O systemd pode executar um comando *antes* de uma reinicialização?

a maneira atual de "iniciar ou reiniciar" um serviço é:

systemctl is-active nginx && systemctl reload nginx || systemctl start nginx

Estou pensando se há uma maneira melhor de usar alvos e coisas assim. Estou com a sensação de que ainda estou tentando usar ferramentas systemd como outras ferramentas init.

O caso em que eu usaria isso é após ajustes manuais na conf, que podem funcionar, mas travar durante o teste de estresse, e então eu preciso iniciar ou reiniciar após novos ajustes no arquivo de configuração. Obviamente, a "solução" aqui pode ser algo que não é aceitável em produção, pois isso é feito em uma caixa vm/dev.

Tenho uma máquina virtual na minha rede local (1G), que uso como ambiente de desenvolvimento Linux. Eu conecto a essa máquina do meu PC Windows 11 usando VCXsrv e encaminhamento x11.

Ultimamente, todos os aplicativos começaram a abrir extremamente lentamente, novas janelas dentro do aplicativo em execução estão abrindo com atraso, e até mesmo o cursor no MC está se movendo com atraso.

Mas isso só acontece quando me conecto com ssh -Y e somente quando me conecto pelo Windows ou Ubuntu LTS.

• Se eu conectar do Windows (VCXsrv) - lag
• Se eu conectar do Ubuntu (24.04.1 wayland kernel 6.8.0-48-generic) - lag
• Se eu conectar sem o encaminhamento X11 - o cursor mc age normalmente, provavelmente sem atraso
• Se eu conectar do OpenSuse Tumbleweed (241025 KDE 6.2.2 wayland kernel 6.11.5-1-default) - tudo funciona como esperado, mesmo com o encaminhamento x11, sem atrasos

A máquina host é manjaro, totalmente atualizada. Clientes Linux instalados em VMs na máquina Windows.

Quando comecei a sentir atrasos, instalei o JDK na máquina host, mas não sei se isso pode ter esse efeito.

Versões SSH:

• máquina host - OpenSSH_9.8p1, OpenSSL 3.3.2 3 de setembro de 2024
• Windows - OpenSSH_para_Windows_9.5p1, LibreSSL 3.8.2
• Ubuntu - OpenSSH_9.6p1 Ubuntu-3ubuntu13.5, OpenSSL 3.0.13 30 de janeiro de 2024
• OpenSuse - OpenSSH_9.9p1, OpenSSL 3.1.4 24 de outubro de 2023

Tenho um servidor proxy Nginx com módulo headers-more-nginx que passa solicitações para o Exchange Server 2019. Atualmente, o Outlook 2019 fica preso em um loop solicitando credenciais toda vez que tento conectar ao meu servidor - ele solicita uma senha, aceita e pergunta novamente. Esse problema se repete em outros dispositivos.

O Outlook mais recente da Microsoft Store funciona bem.

Além disso, se for Netscaler em vez de Nginx, tudo funcionará normalmente, então presumo que o Nginx esteja configurado incorretamente, mas não consigo acessar a configuração do Netscaler agora.

Como devo alterar a configuração do Nginx para que ele funcione corretamente?

Configuração atual do nginx:

http {
    server {
            listen 80;
            listen 443 ssl;
            server_name mail.mydomain.com;

            ssl_certificate /etc/ssl/certs/mydomain.crt;
            ssl_certificate_key /etc/ssl/certs/mydomain.key;
            ssl_trusted_certificate /etc/ssl/certs/mydomain.crt;
            ssl_session_timeout 5m;

            add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload;" always;

            location / {
                    proxy_pass_request_headers on;
                    keepalive_timeout 3h;
                    tcp_nodelay on;
                    client_max_body_size 3G;
                    #proxy_buffering off; # tried both on and off
                    #proxy_request_buffering off;
                    proxy_read_timeout 3600;

                    proxy_pass_header Date;
                    proxy_pass_header Server;
                    proxy_set_header Authorization $http_authorization;
                    proxy_pass_header Authorization;
                    proxy_set_header Connection "Keep-Alive";
                    proxy_http_version 1.1;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_set_header X-Forwarded-Proto $scheme;
                    proxy_set_header X-Forwarded-Server $host;
                    proxy_set_header X-Forwarded-Host $host:$server_port;
                    proxy_set_header Host $host;
                    proxy_set_header X-Real-IP $remote_addr;

                    more_set_input_headers 'Authorization: $http_authorization';
                    # I tried to use Nginx's domain as well as domain of Exchange server, no luck
                    more_set_headers -s 401 'WWW-Authenticate: Basic realm="mail.mydomain.com"';

                    proxy_pass https://exchange$request_uri;
             }
     }
}
upstream exchange {
    ip_hash;
    server exchangeip1:443;
    server exchangeip2:443;
}

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

Em um script bash, quero obter o endereço IPv6 global da minha máquina para um determinado adaptador de rede (no meu caso, 'ens18'). Para começar, emiti o seguinte comando:

ip -6 addr

Isso me dá a seguinte saída, que contém o endereço que estou procurando:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fd00::3170:4ff:eff4:a4ab/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 6736sec preferred_lft 3136sec
    inet6 2a02:8070:2982:4300:3170:4ff:eff4:a4ab/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 6736sec preferred_lft 3136sec
    inet6 af60::3170:4ff:eff4:a4ab/64 scope link 
       valid_lft forever preferred_lft forever
3: br-7ac197bd041e: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP 
    inet6 af60::42:80ff:fe52:3481/64 scope link 
       valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP 
    inet6 af60::42:6eff:fecf:5e6/64 scope link 
       valid_lft forever preferred_lft forever
6: veth074f8b0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP 
    inet6 af60::7073:40ff:fe59:aad0/64 scope link 
       valid_lft forever preferred_lft forever
8: vethe85ed67@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP 
    inet6 af60::5c09:65ff:fe34:34f4/64 scope link 
       valid_lft forever preferred_lft forever

Então o endereço IPv6 global é "2a02:8070:2982:4300:3170:4ff:eff4:a4ab".

Como posso recuperar esse valor de forma confiável do meu script bash?

Encontrei alguma documentação que me permite criar segredos e enviá-los para o infisical, como visto aqui: https://registry.terraform.io/providers/Infisical/infisical/latest/docs/resources/secret, mas não consigo encontrar nada sobre a leitura de segredos do infisical.

A ideia seria ter os dados confidenciais armazenados no infisical e fazer com que o Terraform se conectasse a eles por meio do ID do cliente/segredo do cliente para recuperar valores como senhas e então usá-los (o infisical também é usado por muitos outros programas que eu uso, então é conveniente ter tudo no mesmo lugar).

Tenho um punhado de máquinas conectadas a um switch. A maioria delas consegue fazer ping no servidor que está conectado ao mesmo switch, mas algumas não conseguem.

A interface de rede da máquina em questão está ativa e parece estar configurada corretamente (executada ethtool eth0), mas quando faço ping no servidor, recebo destination host unreachable100% de perda de pacotes.

Tudo está configurado com IPs estáticos. Verifiquei o óbvio - troquei os cabos e descartei conflitos de IP/mac. As portas no switch estão habilitadas.

Cada máquina tem uma configuração de rota para a sub-rede para o adaptador correto (192.XXX.XXX.0 -> eth0)

As outras 3 interfaces estão em ponte. Tentei desligar a ponte como uma verificação de integridade, mas isso não afetou nada (como esperado).

O Traceroute mostra apenas 1 salto:machineName (IP) 3061.260 ms H! 3069.321 ms H! 3071.245 ms H!

Sei que é uma pergunta muito ampla, mas como posso diagnosticar isso?