Início / server / 问题

All perguntas(server)

Martin Hope
hzahradnik
Asked: 2024-09-17 03:11:32 +0800 CST
  • 5

Nossa empresa transferiu um domínio .com para um provedor de domínio diferente. Isso funcionou muito bem por 14 dias, mas hoje nosso domínio foi suspenso, porque tivemos um problema com nosso provedor de e-mail e não recebemos o e-mail para a verificação do endereço do proprietário.

Depois de algum tempo, conseguimos consertar os problemas de e-mail e verificar o domínio. Também conseguimos fazer nosso aplicativo rodar conforme o esperado, ao usar o DNS do Google/Cloudflare/.... No entanto, muitos de nossos clientes ainda têm problemas para acessar nosso aplicativo depois de quase 12 horas.

Enquanto isso, podemos rastrear uma possível causa. Nosso suspeito é o cache de DNS de alguns provedores de internet. Veja a saída de nslookuppara solicitar a entrada SOA do subdomínio para nossa aplicação.

Usando o DNS do Google (8.8.8.8), a entrada SOA para app.EXAMPLE.com é do nosso domínio EXAMPLE.com.

> server 8.8.8.8
Default Server:  dns.google
Address:  8.8.8.8

> set type=soa
> set d2
> app.EXAMPLE.com
Server:  dns.google
Address:  8.8.8.8

------------
SendRequest(), len 34
    HEADER:
        opcode = QUERY, id = 25, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        app.EXAMPLE.com, type = SOA, class = IN

------------
------------
Got answer (99 bytes):
    HEADER:
        opcode = QUERY, id = 25, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        app.EXAMPLE.com, type = SOA, class = IN
    AUTHORITY RECORDS:
    ->  EXAMPLE.com
        type = SOA, class = IN, dlen = 53
        ttl = 1800 (30 mins)
        primary name server = ns1.DOMAINPROVIDER.de
        responsible mail addr = postmaster.DOMAINPROVIDER.de
        serial  = 2024091603
        refresh = 86400 (1 day)
        retry   = 10800 (3 hours)
        expire  = 3600000 (41 days 16 hours)
        default TTL = 3600 (1 hour)

------------
EXAMPLE.com
        type = SOA, class = IN, dlen = 53
        ttl = 1800 (30 mins)
        primary name server = ns1.DOMAINPROVIDER.de
        responsible mail addr = postmaster.DOMAINPROVIDER.de
        serial  = 2024091603
        refresh = 86400 (1 day)
        retry   = 10800 (3 hours)
        expire  = 3600000 (41 days 16 hours)
        default TTL = 3600 (1 hour)
> set type=A
> app.EXAMPLE.com
Server:  dns.google
Address:  8.8.8.8
------------
[...]
------------
Non-authoritative answer:
Name:    app.EXAMPLE.com
Address:  <IP ADDRESS OF OUR SERVER>

Ao usar o servidor DNS do nosso provedor de internet, obtemos um resultado completamente diferente para o subdomínio.

> set type=soa
> set d2
> app.EXAMPLE.com
Server:  <DNS OF INTERNET PROVIDER>
Address:  <DNS OF INTERNET PROVIDER>

------------
SendRequest(), len 34
    HEADER:
        opcode = QUERY, id = 28, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        app.EXAMPLE.com, type = SOA, class = IN

------------
------------
Got answer (107 bytes):
    HEADER:
        opcode = QUERY, id = 28, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        app.EXAMPLE.com, type = SOA, class = IN
    ANSWERS:
    ->  app.EXAMPLE.com
        type = SOA, class = IN, dlen = 61
        ttl = 2335 (38 mins 55 secs)
        primary name server = ns1.emailverification.info
        responsible mail addr = hostmaster.emailverification.info
        serial  = 2024090700
        refresh = 7200 (2 hours)
        retry   = 3600 (1 hour)
        expire  = 604800 (7 days)
        default TTL = 3600 (1 hour)

------------
Non-authoritative answer:
app.EXAMPLE.com
        type = SOA, class = IN, dlen = 61
        ttl = 2335 (38 mins 55 secs)
        primary name server = ns1.emailverification.info
        responsible mail addr = hostmaster.emailverification.info
        serial  = 2024090700
        refresh = 7200 (2 hours)
        retry   = 3600 (1 hour)
        expire  = 604800 (7 days)
        default TTL = 3600 (1 hour)
> set type=A
> app.EXAMPLE.com
Server:  <DNS OF INTERNET PROVIDER>
Address:  <DNS OF INTERNET PROVIDER>
------------
[...]
------------
Non-authoritative answer:
Name:    app.EXAMPLE.com
Address:  <WRONG IP ADDRESS>

Minha pergunta: Isso se resolve automaticamente depois de algum tempo ou precisamos fazer algo? É possível acelerar o processo?

domain-name-system
Martin Hope
ericx
Asked: 2024-09-17 02:39:25 +0800 CST
  • 6

Estou tentando adicionar DNS dividido a um túnel Wireguard (não é bem uma pergunta sobre Wireguard).

Tenho um comando PostUp: resolvectl dns %i 10.160.20.15 Que se traduz em: resolvectl dns wg0 10.160.20.15e não funciona.

Quando eu apenas executo esse comando como root, nada parece mudar. Não há servidor DNS adicionado ao resolvectl status. Se eu habilitar o nível DEBUG de registro, recebo MUITAS mensagens, journalctlmas não consigo ver nenhuma explicação para a falha.

É muito longo para postar aqui; mas o único error-messagecampo em todos os logs que não é preenchido com n/aé Link lan0 is managede tem outro campo error-namecom o valororg.freedesktop.resolve1.LinkBusy

lan0é o nome da minha Ethernet primária (renomeada em netplan) e, até onde sei, não deveria estar envolvida com esse comando?

Se eu for ingênuo e lan0estiver envolvido de alguma forma, como faço para deixá-lo desocupado (sem gerenciamento) para poder definir o DNS em uma interface diferente?

EDIT: Encontrei o seguinte em org.freedesktop.resolve1 :

org.freedesktop.resolve1.LinkBusy

A alteração de configuração solicitada não pôde ser feita porque systemd-networkd(8) já tomou posse da interface e forneceu dados de configuração para ela.

Então acho que preciso saber o que significa quando networkdtoma posse? E como tomar posse de volta?

resolvectl
Martin Hope
verm-luh
Asked: 2024-09-16 20:08:12 +0800 CST
  • 6

Estou usando nginx para acessar vários serviços em uma máquina. Por isso, adicionei arquivos de log específicos para cada serviço proxy:

location /errorcodes/ {
  include /etc/nginx/sinatra_params;
  proxy_pass http://localhost:4567/;
  access_log /var/log/nginx/errorcodes-access.log;
  error_log /var/log/nginx/errorcodes-error.log;
}

Agora parece que os arquivos de log específicos de localização são tratados de forma diferente dos arquivos de log globais, para o proprietário e grupo, e também os direitos de acesso diferem daqueles dos arquivos de log globais do nginx.

O log de acesso padrão, por exemplo, é criado como

-rw-r-----  1 www-data adm    3,0K Sep 16 09:31 access.log

enquanto o log específico do local é criado como

-rw-r--r--  1 root     root    173 Sep 16 09:44 errorcodes-access.log

Não acho que isso seja um problema tão grande, mas gostaria de entender o que está acontecendo aqui. Então por que os arquivos de log específicos de localização são tratados de forma diferente?

nginx
Martin Hope
roadrunnr
Asked: 2024-09-16 19:48:39 +0800 CST
  • 5

Tenho um aplicativo Symfony que desejo limitar a taxa. Quero um limite geral e um limite para solicitações PHP. No entanto, apenas o limite geral parece se aplicar.

Aqui está a configuração (os valores de taxa são, é claro, apenas para fins de teste):

limit_req_zone $binary_remote_addr zone=limit_zone_general:10m rate=2r/m;

limit_req_zone $binary_remote_addr zone=limit_zone_php:10m rate=1r/m;

server {
    # ...
    
    root /var/www/html/public;
    index index.php;

    limit_req zone=limit_zone_general;
    limit_req_status 429;

    location / {
        error_page 404 /meta/404;
        try_files $uri /index.php$is_args$args;
    }

    location ~ ^/index\.php(/|$) {
        limit_req zone=limit_zone_php;
        limit_req_status 429;
    }

}

Se eu agora chamar domain.local/, eu esperaria que ele fosse chamável apenas uma vez por minuto, já que não há documento estático para servir e, portanto, ele deveria chamar index.php e usar seu limite. No entanto, o limite geral se aplica e eu posso chamá-lo duas vezes por minuto.

Alguém pode me dar uma dica do que não estou entendendo direito?

Se uma pergunta semelhante já foi feita, terei prazer em dar uma olhada lá, mas até agora minha busca não trouxe nada útil.

Editar: O que eu tentei até agora:

  • Tentei mover o limite geral do bloco do servidor para o bloco de localização para / (porque talvez a definição do servidor "supere" a definição de localização, mas não é o caso)
  • Tentei usar teclas diferentes para as zonas, mas isso também não muda nada.
  • Removendo o limite geral completamente. Agora o limite específico do php funcionou. Então o limite em si não é falho.
nginx
Martin Hope
Alex Seleznyov
Asked: 2024-09-16 19:29:00 +0800 CST
  • 6

Problema: Arquivo de poucos gigabytes de tamanho (por exemplo, ISO de DVD do Debian) é corrompido quando baixado usando curl ou wget para um compartilhamento do Windows do Alpine Linux em execução no Hyper-V na mesma máquina Configuração:

  • Dell T20, Xeon e 32 GB de RAM
  • Windows Server 2016 com os últimos patches, etc.
  • Alpine 3.20 rodando em Hyper-V
  • Switch virtual de 10 GB, MTU 1500, exposto a WS2016 e Alpine
  • Compartilhamento do Windows montado no Alpine em /etc/fstab

Testes que executei:

  • curl/wget em Alpine, salvar para compartilhar - a execução sha256 em Alpine difere do esperado. Várias execuções obtêm sha256 diferente.
  • curl no Windows, salvar no disco local - sha256 executado no Alpine corresponde ao valor esperado

Criei uma nova VM com disco vazio, instalei o Alpine 3.20 com os patches mais recentes e obtive o mesmo comportamento.

Fiquei sem ideias de onde procurar e o que verificar, então qualquer ideia será muito bem-vinda.

hyper-v
Martin Hope
StainlessSteelRat
Asked: 2024-09-16 12:11:48 +0800 CST
  • 8

Tenho uma API que escrevi que usa TCP para transmitir dados bidirecionalmente. Ela funciona perfeitamente bem na minha configuração local. Mas quando mudo para produção, ela nunca atinge o ponto final.

O servidor de produção usa ELB para balancear carga de uma instância EC2 e tudo isso é liderado pelo Cloud Flare.

No começo, eu nem conseguia ver que ele atingiu os logs do NGINX, então fui até o CloudFlare e acertei o endereço IP do EC2 diretamente. Isso fez com que a tentativa aparecesse nos logs de acesso, mas todos eles imediatamente 499 curtiram isso.

[16/set/2024:03:13:50 +0000] "POST /api/user_sync HTTP/1.1" 499 0 "-" "MYAPP/1.0.6 CFNetwork/1494.0.7 Darwin/23.6.0"

499 parece indicar que o cliente abortou a conexão, mas posso ver no meu aplicativo que a conexão com o servidor não é encerrada até que o tempo limite do lado do cliente seja atingido. Mas o 499 aparece instantaneamente nos logs de acesso do NGINX. Então é como se ele o desligasse imediatamente.

Infelizmente, não tenho muita experiência com NGINX, balanceamento de carga ou sites em geral, então qualquer ajuda seria muito apreciada.

Eu encontrei algumas postagens onde outros usuários estavam tendo problemas semelhantes, embora para eles, o 499 acontecesse para cada chamada de API, ou após um longo período de tempo. No entanto, isso acontece TODA VEZ e apenas para este endpoint específico.

ios
Martin Hope
CornBouyed
Asked: 2024-09-16 18:03:01 +0800 CST
  • 5

Por que o rsyslog pode estar registrando mensagens duplicadas do diário do systemd?

Estou ciente dos problemas conhecidos envolvendo a corrupção do diário do systemd (veja, por exemplo, o aviso na seção "Propósito" aqui: https://www.rsyslog.com/doc/configuration/modules/imjournal.html ), mas não acho que seja esse o problema que estou encontrando. Estou executando o Ubuntu 24.04, rsyslog 8.2312.0-3ubuntu9 e systemd 255.4-1ubuntu8.4.

Tenho vários hosts executando um aplicativo chamado "foobar" como um serviço systemd e registrando no diário systemd. Também executo o rsyslog como um serviço systemd e ele é configurado para encaminhar os logs foobar no formato JSON do diário systemd para um servidor de registro central. A configuração do rsyslog em cada host se parece com:

module(load="imjournal" StateFile="journalState" IgnorePreviousMessages="on")
module(load="mmjsonparse")
    
template(name="foobarJSON" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag% @cee: %$!all-json%\n" )

if $syslogfacility-text == "user" and $programname == "foobar" then {
    user.* action(type="omfwd" target="central-logs.server" port="514" protocol="tcp" template="foobarJSON")
}

Também estou executando o rsyslog como um serviço systemd no servidor de log central e gravando os logs foobar de cada servidor em arquivos locais dentro de um subdiretório separado para cada host. A configuração do rsyslog neste host se parece com:

module(load="imtcp")
input(type="imtcp" address="123.456.789.0" port="514")

template(name="foobarHostLogs" type="string" string="/var/logs/%PROGRAMNAME%/%HOSTNAME%/%$year%/%$month%/%$day%.log")

module(load="builtin:omfile" DirCreateMode="0755")

if $fromhost-ip != '127.0.0.1' then {
    action(type="omfile" dynaFile="foobarHostLogs")

    & stop
}

Executando journalctl -u foobar em qualquer um dos hosts foobar, não vejo nenhuma mensagem duplicada. No entanto, ao olhar os arquivos de log no servidor de log central, vejo que todas as mensagens estão duplicadas: há pelo menos uma mensagem contendo apenas o campo "msg" do diário systemd (embora às vezes eu veja duas linhas idênticas contendo apenas "msg"), seguidas imediatamente por uma linha com exatamente o mesmo timestamp e valor "msg" mais todos os outros campos de metadados do diário systemd.

Por exemplo (removi vários campos extras da segunda linha abaixo, mas espero que você tenha entendido a ideia):

2024-09-15T00:00:00+00:00 host-a foobar[123456]: @cee: { "msg": "Hello, world!" }
2024-09-15T00:00:00+00:00 host-a foobar[123456]: @cee: { "_TRANSPORT": "journal", "_PID": "123456", "_UID": "1000", "_GID": "1000", "_COMM": "foobar", "_EXE": "\/usr\/local\/bin\/foobar", "_CMDLINE": ".\/foobar", "_CAP_EFFECTIVE": "0", "_SELINUX_CONTEXT": "unconfined\n", "MESSAGE": "Hello, world!", "msg": "Hello, world!" }
rsyslog
Martin Hope
user1913559
Asked: 2024-09-15 19:01:04 +0800 CST
  • 5

Tenho um servidor Proxmox com alguns zpools. Um dos zpools rust01é um zpool de 4 discos, onde os metadados e o cache de gravação eram alguns drives nvme m.2 na placa-mãe (um para cada - eu sei, estúpido, mas foi o que foi feito).

Parece que o rust01teve uma falha catastrófica. Quando clico em rust01na Server View, recebo o seguinte erro: could not activate storage 'rust01', zfs error: cannot import 'rust01': I/O error (500)

  • Quando vou para { Servidor } > Discos > ZFS, não vejo o rust01zpool.

  • Quando vou para {Servidor} > Discos, nem vejo os 4 discos ou o arquivo de metadados especial ou as unidades de cache de leitura/gravação.

  • Quando eu corro zpool status -xeu ganhoall pools are healthy

  • Quando executo zpool import rust01recebo a seguinte mensagem:

    cannot import 'rust01': I/O error
Destroy and re-create the pool from
a backup source.

Quando executo , zpool status rust01recebo cannot open 'rust01': no such pool. Quando reinicio o servidor, abaixo está o erro que me foi enviado por e-mail:

ZFS has detected that a device was removed.
impact: Fault tolerance of the pool may be compromised.
eid: 10
class: statechange
state: UNAVAIL
host: pve01
time: 2024-09-14 21:20:32-0500
vpath: /dev/nvme2n1p1
vphys: pci-0000:41:00.0-nvme-1
vguid: 0x297D516B1F1D6494
devid: nvme-Samsung_SSD_970_EVO_Plus_2TB_S6S2NS0T815592K-part1
pool: rust01 (0xE4AAC2680D8B6A7E)

Quando executo, zpool destroy rust01recebo o seguinte erro cannot open 'rust01': no such pool. Idealmente, eu gostaria de voltar a ficar rust01online. Tenho quase certeza de que o problema é o disco de metadados especial mencionado no e-mail acima. Dito isso, ficaria feliz em destruir e recriar rust01. Todas as VMs naquele disco são copiadas, então posso restaurar facilmente se necessário. Meu problema, no entanto, é que não consigo encontrar uma maneira de fazer o Proxmox/ZFS liberar os discos associados ao rust01zpool corrompido. Abaixo está a saída de lsblk:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    1 465.8G  0 disk 
|-sda1        8:1    1  1007K  0 part 
|-sda2        8:2    1     1G  0 part 
`-sda3        8:3    1   464G  0 part 
sdb           8:16   1 465.8G  0 disk 
|-sdb1        8:17   1  1007K  0 part 
|-sdb2        8:18   1     1G  0 part 
`-sdb3        8:19   1   464G  0 part 
sdc           8:32   1   3.6T  0 disk 
|-sdc1        8:33   1   3.6T  0 part 
`-sdc9        8:41   1     8M  0 part 
sdd           8:48   1   3.6T  0 disk 
|-sdd1        8:49   1   3.6T  0 part 
`-sdd9        8:57   1     8M  0 part 
sde           8:64   1   3.6T  0 disk 
|-sde1        8:65   1   3.6T  0 part 
`-sde9        8:73   1     8M  0 part 
sdf           8:80   1   3.6T  0 disk 
|-sdf1        8:81   1   3.6T  0 part 
`-sdf9        8:89   1     8M  0 part 
sdg           8:96   1     0B  0 disk 
sdh           8:112  1     0B  0 disk 
sdi           8:128  1     0B  0 disk 
sdj           8:144  1     0B  0 disk 
sdk           8:160  1     0B  0 disk 
sdl           8:176  1     0B  0 disk 
sdm           8:192  1     0B  0 disk 
sdn           8:208  1     0B  0 disk 
sr0          11:0    1  1024M  0 rom  
sr1          11:1    1  1024M  0 rom  
sr2          11:2    1  1024M  0 rom  
sr3          11:3    1  1024M  0 rom  
zd0         230:0    0     4M  0 disk 
zd16        230:16   0    80G  0 disk 
`-zd16p1    230:17   0    80G  0 part 
zd32        230:32   0    64G  0 disk 
|-zd32p1    230:33   0     1M  0 part 
|-zd32p2    230:34   0     2G  0 part 
`-zd32p3    230:35   0    62G  0 part 
zd48        230:48   0    40G  0 disk 
|-zd48p1    230:49   0   600M  0 part 
|-zd48p2    230:50   0     1G  0 part 
`-zd48p3    230:51   0  38.4G  0 part 
zd64        230:64   0    32G  0 disk 
|-zd64p1    230:65   0    31G  0 part 
|-zd64p2    230:66   0     1K  0 part 
`-zd64p5    230:69   0   975M  0 part 
zd80        230:80   0    90G  0 disk 
|-zd80p1    230:81   0   100M  0 part 
|-zd80p2    230:82   0    16M  0 part 
|-zd80p3    230:83   0  89.4G  0 part 
`-zd80p4    230:84   0   523M  0 part 
zd96        230:96   0    90G  0 disk 
|-zd96p1    230:97   0   499M  0 part 
|-zd96p2    230:98   0   128M  0 part 
|-zd96p3    230:99   0  88.5G  0 part 
`-zd96p4    230:100  0   920M  0 part 
zd112       230:112  0   100G  0 disk 
|-zd112p1   230:113  0   499M  0 part 
|-zd112p2   230:114  0    99M  0 part 
|-zd112p3   230:115  0    16M  0 part 
`-zd112p4   230:116  0  99.4G  0 part 
zd128       230:128  0    64G  0 disk 
|-zd128p1   230:129  0     1M  0 part 
|-zd128p2   230:130  0     2G  0 part 
`-zd128p3   230:131  0    62G  0 part 
zd144       230:144  0    90G  0 disk 
|-zd144p1   230:145  0   500M  0 part 
`-zd144p2   230:146  0  89.5G  0 part 
zd160       230:160  0    60G  0 disk 
|-zd160p1   230:161  0   100M  0 part 
|-zd160p2   230:162  0    16M  0 part 
|-zd160p3   230:163  0  59.4G  0 part 
`-zd160p4   230:164  0   450M  0 part 
zd176       230:176  0    32G  0 disk 
|-zd176p1   230:177  0     1M  0 part 
|-zd176p2   230:178  0     2G  0 part 
`-zd176p3   230:179  0    30G  0 part 
zd192       230:192  0   100G  0 disk 
|-zd192p1   230:193  0   450M  0 part 
|-zd192p2   230:194  0    99M  0 part 
|-zd192p3   230:195  0  15.8M  0 part 
|-zd192p4   230:196  0  89.4G  0 part 
`-zd192p5   230:197  0   256K  0 part 
zd208       230:208  0    32G  0 disk 
|-zd208p1   230:209  0   600M  0 part 
|-zd208p2   230:210  0     1G  0 part 
`-zd208p3   230:211  0  30.4G  0 part 
zd224       230:224  0     1M  0 disk 
nvme1n1     259:0    0   1.8T  0 disk 
|-nvme1n1p1 259:1    0   1.8T  0 part 
`-nvme1n1p9 259:2    0     8M  0 part 
nvme3n1     259:3    0   1.8T  0 disk 
|-nvme3n1p1 259:4    0   1.8T  0 part 
`-nvme3n1p9 259:5    0     8M  0 part 
nvme0n1     259:6    0   1.8T  0 disk 
|-nvme0n1p1 259:7    0   1.8T  0 part 
`-nvme0n1p9 259:8    0     8M  0 part 
nvme2n1     259:9    0   1.8T  0 disk 
|-nvme2n1p1 259:10   0   1.8T  0 part 
`-nvme2n1p9 259:11   0     8M  0 part

Há outras VMs neste host rodando em outros zpools, que parecem bem. Como tal, reinstalar tudo não é uma opção que eu queira considerar.

ATUALIZAÇÃO: Após executar as etapas descritas em Corrigir seu SSD morto com o método de ciclo de energia, os discos rígidos de 4 TB estão aparecendo no Proxmox, embora o zpool não esteja acessível. Algum progresso, mas ainda sem acesso aos dados.

Alguma ideia de como proceder além de limpar os discos no zpool afetado?

zfs
Martin Hope
Mykyta Orlov
Asked: 2024-09-15 05:40:22 +0800 CST
  • 8

Início do problema

Tenho um servidor dedicado no provedor de hospedagem e recentemente meu node exporter detectou alta saturação de io de disco no meu array RAID 1 /dev/md3. Eu verifiquei smartctl para meus discos rígidos e ambos os drives no meu array estavam mostrando alto número de erros de leitura:

[root@ovh-ds03 ~]# smartctl /dev/sda -a | grep Err
Error logging capability:        (0x01) Error logging supported.
     SCT Error Recovery Control supported.
  1 Raw_Read_Error_Rate     0x000b   099   099   016    Pre-fail  Always       -       65538
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0



[root@ovh-ds03 ~]# smartctl /dev/sdb -a | grep Err
Error logging capability:        (0x01) Error logging supported.
     SCT Error Recovery Control supported.
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       65536
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

Eu pedi por meio de um ticket de suporte para substituir 2 discos, mas em vez de substituir, mais 2 discos foram adicionados e o array foi reconstruído nesses 2 novos discos. Tudo estava bem, mas agora o array está em estado degradado e eu tive um alerta por causa disso chamado ️NodeRAIDDegraded, verificando no servidor sim, ele está em estado degradado:

[root@ovh-ds03 ~]# mdadm --detail /dev/md3
/dev/md3:
           Version : 1.2
     Creation Time : Sat Mar 30 18:18:26 2024
        Raid Level : raid1
        Array Size : 1951283200 (1860.89 GiB 1998.11 GB)
     Used Dev Size : 1951283200 (1860.89 GiB 1998.11 GB)
      Raid Devices : 4
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sat Sep 14 19:30:44 2024
             State : active, degraded
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : md3
              UUID : 939ad077:07c22e9e:ae62fbf9:4df58cf9
            Events : 55337

    Number   Major   Minor   RaidDevice State
       -       0        0        0      removed
       -       0        0        1      removed
       2       8       35        2      active sync   /dev/sdc3
       3       8       51        3      active sync   /dev/sdd3

Como faço para consertar isso?

Eu tentei testar várias soluções para reconstruir a matriz do zero e assim por diante

mdadm --assemble --scan
raid
Martin Hope
tai
Asked: 2024-09-14 01:41:06 +0800 CST
  • 5

Problema

Quero usar o Wireguard como VPN para poder acessar meus dispositivos LAN remotamente e, ao mesmo tempo, rotear o tráfego pelo meu Pi-hole local para bloquear anúncios e ficar seguro em redes não confiáveis.

Assim, configurei o Wireguard com Pi-hole usando o tutorial do Pi-hole sobre o Wireguard . Segui todos os passos bem pedantes e depois de configurar tudo, consegui acessar o servidor via 10.100.0.1meu cliente, mas nada mais - nem site nem dispositivos locais.

O que eu fiz até agora:

  • crie uma configuração Wireguard conforme indicado aqui
  • crie uma configuração de cliente exatamente como declarado aqui
  • fazer com que meu cliente consiga canalizar todo o tráfego da Internet através do Wireguard, conforme descrito aqui
  • altere o 99-sysctl.confarquivo para habilitar o encaminhamento de IP e habilite o NAT no servidor conforme indicado aqui

Não tenho ideia do que está faltando.

Aqui está o conteúdo dos meus arquivos conf:

wg0.conf

Address = 10.100.0.1/24, fd08:4711::1/64
ListenPort = 47111
PrivateKey = redacted

PostUp = nft add table ip wireguard; nft add chain ip wireguard wireguard_chain {type nat hook postrouting priority srcnat\; policy accept\;}; nft add rule ip wireguard wireguard_chain counter packets 0 bytes 0 masquerade; nft add table ip6 wireguard; nft add chain ip6 wireguard wireguard_chain {type nat hook postrouting priority srcnat\; policy accept\;}; nft add rule ip6 wireguard wireguard_chain counter packets 0 bytes 0 masquerade
PostDown = nft delete table ip wireguard; nft delete table ip6 wireguard

[Peer]
PublicKey = redacted
PresharedKey = redacted
AllowedIPs = 10.100.0.2/32, fd08:4711::2/128

cliente.conf

[Interface]
Address = 10.100.0.2/32, fd08:4711::2/128
DNS = 10.100.0.1
PrivateKey = redacted

[Peer]
#AllowedIPs = 10.100.0.1/32, fd08:4711::1/128
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = mydoma.in:47111
PersistentKeepalive = 25
PublicKey = redacted
PresharedKey = redacted

saída deip route

default via 192.24.0.1 dev enp6s0 proto dhcp src 192.24.0.3 metric 100 
10.0.0.0/24 dev br-2747fb0d94d8 proto kernel scope link src 10.0.0.1 
10.100.0.0/24 dev wg0 proto kernel scope link src 10.100.0.1 
10.178.40.0/24 dev tun0 proto kernel scope link src 10.178.40.1 
192.17.0.0/16 dev docker0 proto kernel scope link src 192.17.0.1 linkdown 
192.18.0.0/16 dev br-cb5d7cb9fc9b proto kernel scope link src 192.18.0.1 
192.19.0.0/16 dev br-6fa7708a9945 proto kernel scope link src 192.19.0.1 
192.20.0.0/16 dev br-0003ef5216eb proto kernel scope link src 192.20.0.1 
192.21.0.0/16 dev br-5779db6c38ec proto kernel scope link src 192.21.0.1 
192.22.0.0/16 dev br-0b6ecf5437f9 proto kernel scope link src 192.22.0.1 linkdown 
192.23.0.0/16 dev br-9813798ea15d proto kernel scope link src 192.23.0.1 
192.24.0.0/24 dev enp6s0 proto kernel scope link src 192.24.0.3 metric 100 
192.25.0.0/16 dev br-bd655dfed23b proto kernel scope link src 192.25.0.1 linkdown

saída de log do cliente wireguard

--------- beginning of main
09-17 15:55:49.839 27728 27791 I WireGuard/GoBackend: Bringing tunnel wireguard_vpn UP
09-17 15:55:49.840 27728 27791 D WireGuard/GoBackend: Requesting to start VpnService
09-17 15:55:49.935 27728 27791 D WireGuard/GoBackend: Go backend 2163620
09-17 15:55:49.937 27728 27791 D WireGuard/GoBackend/wireguard_vpn: Attaching to interface tun0
09-17 15:55:49.941 27728 27791 D WireGuard/GoBackend/wireguard_vpn: UAPI: Updating private key
09-17 15:55:49.942 27728 27791 D WireGuard/GoBackend/wireguard_vpn: UAPI: Removing all peers
09-17 15:55:49.942 27728 31398 D WireGuard/GoBackend/wireguard_vpn: Routine: handshake worker 3 - started
09-17 15:55:49.942 27728 27803 D WireGuard/GoBackend/wireguard_vpn: Routine: handshake worker 6 - started
09-17 15:55:49.942 27728 27797 D WireGuard/GoBackend/wireguard_vpn: Routine: decryption worker 1 - started
09-17 15:55:49.942 27728 27956 D WireGuard/GoBackend/wireguard_vpn: Routine: decryption worker 3 - started
09-17 15:55:49.942 27728 27956 D WireGuard/GoBackend/wireguard_vpn: Routine: encryption worker 3 - started
09-17 15:55:49.942 27728 27803 D WireGuard/GoBackend/wireguard_vpn: Routine: handshake worker 4 - started
09-17 15:55:49.942 27728 27956 D WireGuard/GoBackend/wireguard_vpn: Routine: decryption worker 2 - started
09-17 15:55:49.942 27728 27956 D WireGuard/GoBackend/wireguard_vpn: Routine: handshake worker 1 - started
09-17 15:55:49.942 27728 27956 D WireGuard/GoBackend/wireguard_vpn: Routine: handshake worker 5 - started
09-17 15:55:49.942 27728 27803 D WireGuard/GoBackend/wireguard_vpn: Routine: encryption worker 5 - started
09-17 15:55:49.942 27728 31398 D WireGuard/GoBackend/wireguard_vpn: Routine: encryption worker 4 - started
09-17 15:55:49.942 27728 31398 D WireGuard/GoBackend/wireguard_vpn: Routine: decryption worker 6 - started
09-17 15:55:49.942 27728 31398 D WireGuard/GoBackend/wireguard_vpn: Routine: encryption worker 8 - started
09-17 15:55:49.942 27728 27956 D WireGuard/GoBackend/wireguard_vpn: Routine: decryption worker 5 - started
09-17 15:55:49.942 27728 27803 D WireGuard/GoBackend/wireguard_vpn: Routine: encryption worker 6 - started
09-17 15:55:49.942 27728 27959 D WireGuard/GoBackend/wireguard_vpn: Routine: encryption worker 1 - started
09-17 15:55:49.942 27728 27956 D WireGuard/GoBackend/wireguard_vpn: Routine: decryption worker 7 - started
09-17 15:55:49.942 27728 27803 D WireGuard/GoBackend/wireguard_vpn: Routine: handshake worker 8 - started
09-17 15:55:49.942 27728 27956 D WireGuard/GoBackend/wireguard_vpn: Routine: handshake worker 7 - started
09-17 15:55:49.942 27728 27797 D WireGuard/GoBackend/wireguard_vpn: Routine: encryption worker 2 - started
09-17 15:55:49.942 27728 27803 D WireGuard/GoBackend/wireguard_vpn: Routine: decryption worker 8 - started
09-17 15:55:49.942 27728 27959 D WireGuard/GoBackend/wireguard_vpn: Routine: TUN reader - started
09-17 15:55:49.942 27728 31398 D WireGuard/GoBackend/wireguard_vpn: Routine: encryption worker 7 - started
09-17 15:55:49.942 27728 27956 D WireGuard/GoBackend/wireguard_vpn: Routine: event worker - started
09-17 15:55:49.943 27728 27957 D WireGuard/GoBackend/wireguard_vpn: Routine: handshake worker 2 - started
09-17 15:55:49.943 27728 27791 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - UAPI: Created
09-17 15:55:49.943 27728 27791 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - UAPI: Adding allowedip
09-17 15:55:49.943 27728 27955 D WireGuard/GoBackend/wireguard_vpn: Routine: decryption worker 4 - started
09-17 15:55:49.944 27728 27791 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - UAPI: Adding allowedip
09-17 15:55:49.944 27728 27791 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - UAPI: Updating endpoint
09-17 15:55:49.944 27728 27791 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - UAPI: Updating persistent keepalive interval
09-17 15:55:49.944 27728 27791 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - UAPI: Updating preshared key
09-17 15:55:49.947 27728 27791 D WireGuard/GoBackend/wireguard_vpn: UDP bind has been updated
09-17 15:55:49.947 27728 27791 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - Starting
09-17 15:55:49.947 27728 27955 D WireGuard/GoBackend/wireguard_vpn: Routine: receive incoming v6 - started
09-17 15:55:49.947 27728 27791 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - Sending keepalive packet
09-17 15:55:49.947 27728 27791 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - Sending handshake initiation
09-17 15:55:49.947 27728 31398 D WireGuard/GoBackend/wireguard_vpn: Routine: receive incoming v4 - started
09-17 15:55:49.947 27728 27803 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - Routine: sequential sender - started
09-17 15:55:49.947 27728 27957 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - Routine: sequential receiver - started
09-17 15:55:49.948 27728 27791 D WireGuard/GoBackend/wireguard_vpn: Interface state was Down, requested Up, now Up
09-17 15:55:49.948 27728 27791 D WireGuard/GoBackend/wireguard_vpn: Device started
09-17 15:55:49.968 27728 27957 D WireGuard/GoBackend/wireguard_vpn: peer(5jcX…pTiU) - Received handshake response

Informações do sistema

Servidor

Roteador

  • FRITZ!Box com encaminhamento de porta para 47111/UDP habilitado

Cliente

  • GrapheneOS / Android 14
  • Wireguard F-Droid
  • configuração analisada via código QR

Se alguém puder me dar dicas de qualquer tipo, eu ficaria muito grato.

Muito obrigado antecipadamente.

ubuntu
Prev
Próximo