Início / server / 问题

All perguntas(server)

Martin Hope
Frawstcrabs
Asked: 2024-08-10 03:02:44 +0800 CST
  • 7

Eu tenho um Wireguard conectado a um servidor em nuvem que não controlo e recebi apenas um endereço IP para usar ao me conectar a esse servidor. No entanto, gostaria de permitir que vários clientes se conectassem a esse servidor em nuvem e quero fazer isso configurando meu próprio servidor Wireguard local, conectando clientes a ele e, em seguida, encaminhando o tráfego desse Wireguard local para a nuvem Wireguard.

Aqui está um diagrama da configuração que pretendo implementar: Imagem

A conexão no wg1 funciona para um dispositivo, e posso configurar o wg0 e ter vários clientes conectados a ele, mas estou perplexo ao fazer a ponte do wg0 para o wg1 funcionar. Tenho certeza razoável de que será necessário algum tipo de configuração NAT via iptables, mas não consigo descobrir o que precisa ser configurado para que isso funcione.

Já instalei e net.ipv4.ip_forward=1configurei /etc/sysctl.confmeu firewall ufw para permitir o tráfego no wg0. Também quero ter certeza de que as configurações do Wireguard em meu servidor local não forçam todo o tráfego que sai desse servidor a passar pelo servidor Wireguard externo, por isso configurei todas as tabelas para 1234.

Também pode ser possível adicionar o wireguard externo como um par do meu wireguard local, mas isso também está além da minha capacidade de trabalhar.

Configuração do cliente local:

[Interface]
Address = 10.8.0.1/32  # or 10.8.0.2, 10.8.0.3
PrivateKey = ...

[Peer]
AllowedIPs = 0.0.0.0/0
Endpoint = 1.2.3.4:51820
PublicKey = ...

Configuração do servidor local (wg0):

[Interface]
Address = 10.8.0.254/24
PrivateKey = ...
Table = 1234
PostUp = iptables -A FORWARD -i wg0 -o wg1 -j ACCEPT
PostUp = iptables -A FORWARD -i wg1 -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PostUp = iptables -t nat -I POSTROUTING -o wg1 -j MASQUERADE
PostUp = iptables -t nat -I POSTROUTING -o mv0 -j MASQUERADE
PreDown = iptables -D FORWARD -i wg0 -o wg1 -j ACCEPT
PreDown = iptables -D FORWARD -i wg1 -o wg0 -m state --state ESTABLISHED,RELATED -j ACCEPT
PreDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE
PreDown = iptables -t nat -D POSTROUTING -o wg1 -j MASQUERADE

[Peer]
AllowedIPs = 10.8.0.1/32
PublicKey = ...

[Peer]
AllowedIPs = 10.8.0.2/32
PublicKey = ...

[Peer]
AllowedIPs = 10.8.0.3/32
PublicKey = ...

Configuração de peer do servidor em nuvem (wg1):

[Interface]
Address = 10.9.0.1/32
PrivateKey = ...
Table = 1234

[Peer]
AllowedIPs = 0.0.0.0/0
Endpoint = 5.6.7.8:51820
PublicKey = ...

Qualquer ajuda seria muito apreciada.

linux
Martin Hope
gcb
Asked: 2024-08-10 00:13:41 +0800 CST
  • 8

Conectei um antigo RAID ARRAY a um novo sistema e recebo esse erro em tudo que tento fazer com ele mdadm.

# mdadm --detail --scan 
ARRAY /dev/md/arch1:2021 metadata=1.2 UUID=c4c7cbde:5f6913a9:eb1c82ff:8fe6cd45

# mdadm --detail 
mdadm: Value "arch1:2021" cannot be set as devname. Reason: Not POSIX compatible. Value ignored.
mdadm: No devices given.

Tudo ainda funciona bem. Eu posso montar e usar o Array. E o nome "não compatível" aparece como um arquivo de dispositivo perfeitamente

 # ls -la /dev/md/
total 0
drwxr-xr-x  2 root root   60 2024-08-09 03:16 .
drwxr-xr-x 20 root root 4580 2024-08-09 03:16 ..
lrwxrwxrwx  1 root root    8 2024-08-09 03:16 arch1:2021 -> ../md127

arquivo de dispositivo que eu posso usar

 # mdadm --detail /dev/md/arch1\:2021 
/dev/md/arch1:2021:
           Version : 1.2
     Creation Time : Wed Jul  7 06:29:08 2021
        Raid Level : raid1

Qual é a melhor maneira de atualizar o nome da forma mais segura possível?

raid
Martin Hope
czezz
Asked: 2024-08-09 18:37:20 +0800 CST
  • 5

Criei PV, PVC e adicionei esse PVC ao POD.

Problema/Pergunta: Ao adicionar PVC (no meu entendimento) é como anexar armazenamento externo/adicional. No entanto, quando me conecto ao POD, não vejo nenhum sistema de arquivos adicional. Por que?

kubectl exec -it pod1 -- bash
root@pod1:/# df -Th
Filesystem                        Type     Size  Used Avail Use% Mounted on
overlay                           overlay   31G  5.9G   23G  21% /
tmpfs                             tmpfs     64M     0   64M   0% /dev
shm                               tmpfs     64M     0   64M   0% /dev/shm
tmpfs                             tmpfs    197M  2.0M  195M   2% /etc/hostname
/dev/mapper/ubuntu--vg-ubuntu--lv ext4      31G  5.9G   23G  21% /etc/hosts
tmpfs                             tmpfs    1.9G   12K  1.9G   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                             tmpfs    983M     0  983M   0% /proc/acpi
tmpfs                             tmpfs    983M     0  983M   0% /proc/scsi
tmpfs                             tmpfs    983M     0  983M   0% /sys/firmware

Passos para reproduzir:

$ kubectl apply -f pv1.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  claimRef:
    namespace: default
    name: pvc1-volume
  hostPath:
    path: "/opt/storage"

kubectl get pv -o wide
NAME    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                  STORAGECLASS   REASON   AGE   VOLUMEMODE
pv1     1Gi        RWO            Retain           Available   default/pvc1-volume    manual                  4s    Filesystem

$ kubectl apply -f  pvc1.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1-volume
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Mi

$ kubectl apply -f pvc1.yaml
persistentvolumeclaim/pvc1-volume created

$ kubectl get pvc -o wide
NAME           STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE   VOLUMEMODE
pvc1-volume    Bound    pv1      1Gi        RWO            manual         8s    Filesystem

kubectl apply -f pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: pvc1-volume
  containers:
    - name: nginx
      image: nginx:1.16
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

kubectl get po
NAME          READY   STATUS    RESTARTS   AGE
pod1          1/1     Running   0          28s
kubernetes
Martin Hope
Webtux
Asked: 2024-08-09 15:17:00 +0800 CST
  • 5

Olá especialistas em Kerberos :)

Instalei um servidor Kerberos no Debian Bookworm:

krb5-kdc/stable-security,now 1.20.1-2+deb12u2
krb5-kdc-ldap/stable-security,now 1.20.1-2+deb12u2
krb5-pkinit/stable-security,now 1.20.1-2+deb12u2
krb5-user/stable-security,now 1.20.1-2+deb12u2

A autenticação SSH para qualquer host da minha rede está funcionando perfeitamente usando GSSAPI e Kerberos. Sem problemas até agora. No entanto, ao tentar fazer login via SSH no próprio servidor Kerberos, não consigo fazer isso funcionar e não tenho certeza de qual é o problema aqui.

Isto é o que ssh -vvv ns01diz na tentativa de login no próprio servidor Kerberos de outro host (neste caso 192.168.10.7):

debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
KDC returned error string: NO PREAUTH

E krb5kdc Debug log no servidor ao tentar fazer login:

Aug 09 09:08:51 ns01.example.com krb5kdc[4557](info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 192.168.10.7: NO PREAUTH: authtime 0, etypes {rep=UNSUPPORTED:(0)} [email protected] for host/[email protected], Generic error (see e-text)

Ao fazer um login remoto em outro servidor na rede, é isso que o krb5kdc registra neste caso (com sucesso):

Aug 09 09:10:39 ns01.example.com krb5kdc[4557](info): TGS_REQ (1 etypes {aes256-cts-hmac-sha1-96(18)}) 192.168.10.7: ISSUE: authtime 1723186107, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, [email protected] for krbtgt/[email protected]

O keytab no próprio servidor é como qualquer outro host SSH remoto:

Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   4 09.08.2024 08:16:50 host/[email protected] (aes256-cts-hmac-sha1-96) 
   4 09.08.2024 08:16:50 host/[email protected] (aes128-cts-hmac-sha1-96)

Alguma idéia de como depurar isso ainda mais?

Obrigado

kerberos
Martin Hope
gcb
Asked: 2024-08-09 06:28:24 +0800 CST
  • 5

O kernel do Linux me permitiria adicionar rotas com gateways que eram meramente acessíveis, já que não há problema com eles na prática. Mas hoje em dia recebo "Erro: Nexthop tem gateway inválido", o que é bom para seguir as especificações e tornar os testes ad hoc uma dor de cabeça.

Existe alguma maneira de ignorar essa verificação e forçar minha rota?

E sim, eu quero disparar meus pacotes roteados de LAN privada através de uma interface pública, os motivos são válidos, de baixo volume e inofensivos :)

linux
Martin Hope
Manda Ravalison
Asked: 2024-08-08 21:13:03 +0800 CST
  • 5

Instalei recentemente o docker no meu VPS (Debian). O docker atualmente tem 2 contêineres em execução: aplicativo Node.Js e MySQL.

Hoje recebi uma mensagem de erro do meu aplicativo dizendo que não há espaço livre em/var.

Correr ls -lSh /var/logdá:

-rw-r-----  1 root adm              23G Aug  8 13:01 syslog.1
-rw-r-----  1 root adm              23G Aug  8 13:01 daemon.log.1

E correr tail -f /var/log/syslog.1dá mensagens repetidas:

Aug  8 12:41:30 vmi1856487 dockerd[542]: time="2024-08-08T12:41:30.156088825+02:00" level=info msg="Waiting for containerd to be ready to restart event processing" module=libcontainerd namespace=moby
Aug  8 12:41:30 vmi1856487 dockerd[542]: time="2024-08-08T12:41:30.156332291+02:00" level=error msg="Failed to get event" error="rpc error: code = Internal desc = stream terminated by RST_STREAM with error code: PROTOCOL_ERROR" module=libcontainerd namespace=moby

Tentei fazer algumas pesquisas sobre como corrigir esse erro, mas sem sorte. Alguém pode me ajudar como corrigir esse erro ou devo reinstalar o docker?

linux
Martin Hope
user1119739
Asked: 2024-08-08 21:01:20 +0800 CST
  • 8

Somos uma escola com uma pequena configuração local com servidores AD 2019, servidores DFS e um servidor de impressão. O DFS tem funcionado relativamente bem nos últimos anos (não gosta do longo tempo de replicação quando ocorrem alterações ocasionais de permissão) até recentemente, quando percebemos que leva vários minutos para que os arquivos apareçam no Windows Explorer. Indo do servidor DFS A para o servidor DFS B, os arquivos aparecem imediatamente. Mas passar do servidor DFS B para o servidor DFS A leva de 3 a 4 minutos. O interessante é que ao olhar nos próprios servidores da pasta de compartilhamento, os arquivos são replicados na hora. Demora muito para aparecer nas áreas de trabalho da equipe no Windows Explorer e, como resultado, alguns arquivos foram substituídos.

Eu tenho um único namespace com dois servidores de namespace. Tentei alterar a duração do cache de 300 segundos para 30 segundos sem efeito. Aumentei a cota porque temos alguns arquivos grandes, mas não esperaria que isso afetasse nada. Mantive o resto da configuração com os valores padrão (pelo que me lembro).

Este é meu primeiro post, então se estiver faltando algum detalhe ou precisar incluir mais alguma coisa, por favor me avise. Qualquer ajuda é apreciada.

windows
Martin Hope
Paul Alexander
Asked: 2024-08-08 20:14:07 +0800 CST
  • 4

Configurei um servidor FTP do Windows usando IIS. As regras de porta do firewall foram configuradas e habilitadas automaticamente durante a instalação do FTP, permitindo o tráfego FTP nas portas 21, 1024-65535 e 990. Regras de firewall FTP

Quando tento conectar-me a partir do servidor em que o servidor FTP está sendo executado, consigo conectar-me com êxito e sem problemas. No entanto, quando tento conectar-me ao servidor FTP a partir de um computador na rede, a conexão atinge o tempo limite. Se eu desabilitar o firewall, poderei conectar-me com sucesso.

Estou testando a conexão FTP usando o PowerShell.

Qualquer ajuda será apreciada. Obrigado.

iis
Martin Hope
The Fabio
Asked: 2024-08-08 08:50:11 +0800 CST
  • 6

Ao usar signtool.exe com uma "Conta de Assinatura Confiável do Azure" em scripts devops do Azure, o processo trava em:

Enviando resumo para assinatura...

Este é o bloco de script do PowerShell que usamos no Azure DevOps, que é baseado na documentação da Conta de Assinatura Confiável do Azure :

    - task: PowerShell@2
      displayName: Preparing Windows EXE signing tools
      inputs:
        targetType: 'inline'
        workingDirectory: $(Pipeline.Workspace)/windows-signing-tool
        script: |
          Set-PSDebug -Trace 1
          Invoke-WebRequest -Uri https://dist.nuget.org/win-x86-commandline/latest/nuget.exe -OutFile .\nuget.exe
          .\nuget.exe install Microsoft.Windows.SDK.BuildTools -Version 10.0.22621.3233 -x
          .\nuget.exe install Microsoft.Trusted.Signing.Client -Version 1.0.53 -x
          ./"Microsoft.Windows.SDK.BuildTools\bin\10.0.22621.0\x86\signtool.exe" sign /v /debug /fd SHA256 /tr "http://timestamp.acs.microsoft.com" /td SHA256 /dlib "Microsoft.Trusted.Signing.Client\bin\x86\Azure.CodeSigning.Dlib.dll" /dmdf ".\signing-metadata.json" "<obscurecFolder>/MyProject.exe"

A saída do log:

========================== Starting Command Output ===========================
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'D:\a\_temp\c16ea5da-1997-4e32-9ef5-9e9268766943.ps1'"
DEBUG:    5+  >>>> Invoke-WebRequest -Uri https://dist.nuget.org/win-x86-commandline/latest/nuget.exe -OutFile 
.\nuget.exe
DEBUG:    6+  >>>> .\nuget.exe install Microsoft.Windows.SDK.BuildTools -Version 10.0.22621.3233 -x
Feeds used:
  https://api.nuget.org/v3/index.json
  C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\



Attempting to gather dependency information for package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' with respect to project '<obscurecFolder>\windows-signing-tool', targeting 'Any,Version=v0.0'
Gathering dependency information took 751 ms
Attempting to resolve dependencies for package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233'
Resolved actions to install package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233'
Retrieving package 'Microsoft.Windows.SDK.BuildTools 10.0.22621.3233' from 'nuget.org'.
  GET https://api.nuget.org/v3-flatcontainer/microsoft.windows.sdk.buildtools/10.0.22621.3233/microsoft.windows.sdk.buildtools.10.0.22621.3233.nupkg
  OK https://api.nuget.org/v3-flatcontainer/microsoft.windows.sdk.buildtools/10.0.22621.3233/microsoft.windows.sdk.buildtools.10.0.22621.3233.nupkg 7ms
Installed Microsoft.Windows.SDK.BuildTools 10.0.22621.3233 from https://api.nuget.org/v3/index.json to C:\Users\VssAdministrator\.nuget\packages\microsoft.windows.sdk.buildtools\10.0.22621.3233 with content hash v67zwCb9JOpfPxdSroZukIKHruU6FUB+KwcmSPcVvUFyYtcyvcUign5y8jPQNi54CVzWvaTg646e62LbanUkxg==.
Adding package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' to folder '<obscurecFolder>\windows-signing-tool'
Added package 'Microsoft.Windows.SDK.BuildTools.10.0.22621.3233' to folder '<obscurecFolder>\windows-signing-tool'
Successfully installed 'Microsoft.Windows.SDK.BuildTools 10.0.22621.3233' to <obscurecFolder>\windows-signing-tool
Executing nuget actions took 5.09 sec
DEBUG:    7+  >>>> .\nuget.exe install Microsoft.Trusted.Signing.Client -Version 1.0.53 -x
Feeds used:
  C:\Users\VssAdministrator\.nuget\packages\
  https://api.nuget.org/v3/index.json
  C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\



Attempting to gather dependency information for package 'Microsoft.Trusted.Signing.Client.1.0.53' with respect to project '<obscurecFolder>\windows-signing-tool', targeting 'Any,Version=v0.0'
Gathering dependency information took 1.09 sec
Attempting to resolve dependencies for package 'Microsoft.Trusted.Signing.Client.1.0.53' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'Microsoft.Trusted.Signing.Client.1.0.53'
Resolved actions to install package 'Microsoft.Trusted.Signing.Client.1.0.53'
Retrieving package 'Microsoft.Trusted.Signing.Client 1.0.53' from 'nuget.org'.
  GET https://api.nuget.org/v3-flatcontainer/microsoft.trusted.signing.client/1.0.53/microsoft.trusted.signing.client.1.0.53.nupkg
  OK https://api.nuget.org/v3-flatcontainer/microsoft.trusted.signing.client/1.0.53/microsoft.trusted.signing.client.1.0.53.nupkg 9ms
Installed Microsoft.Trusted.Signing.Client 1.0.53 from https://api.nuget.org/v3/index.json to C:\Users\VssAdministrator\.nuget\packages\microsoft.trusted.signing.client\1.0.53 with content hash lou6NowgbY3S/Yn0+WSeI+Dl8SCmvmqkeAzt2Pgs51QL5/kHh+w8FJgutYGM+j2TB11a9zNc0EBWjOGWdwWtoQ==.
Adding package 'Microsoft.Trusted.Signing.Client.1.0.53' to folder '<obscurecFolder>\windows-signing-tool'
Added package 'Microsoft.Trusted.Signing.Client.1.0.53' to folder '<obscurecFolder>\windows-signing-tool'
Successfully installed 'Microsoft.Trusted.Signing.Client 1.0.53' to <obscurecFolder>\windows-signing-tool
Executing nuget actions took 1.45 sec

Isso significa que os três primeiros comandos funcionaram bem...

depois disso temos:

./"Microsoft.Windows.SDK.BuildTools\bin\10.0.22621.0\x86\signtool.exe" sign /v /debug /fd SHA256 /tr "http://timestamp.acs.microsoft.com" /td SHA256 /dlib "Microsoft.Trusted.Signing.Client\bin\x86\Azure.CodeSigning.Dlib.dll" /dmdf ".\signing-metadata.json" "<obscurecFolder>/MyProject.exe"

Trusted Signing

Version: 1.0.53

"Metadata": {
  "Endpoint": "https://eus.codesigning.azure.net",
  "CodeSigningAccountName": "ObscuredTrustedSignAccName",
  "CertificateProfileName": "ObscuredTrustedSignAccCertificateProfileName",
  "ExcludeCredentials": []
}

Submitting digest for signing...

Quando executado localmente, a saída do mesmo último comando é:

Trusted Signing

Version: 1.0.60

"Metadata": {
  "Endpoint": "https://eus.codesigning.azure.net",
  "CodeSigningAccountName": "ObscuredTrustedSignAccName",
  "CertificateProfileName": "ObscuredTrustedSignAccCertificateProfileName",
  "ExcludeCredentials": []
}

Submitting digest for signing...

OperationId 12121212-acbc-acbc-acbc-49603042d34c: InProgress

Signing completed with status 'Succeeded' in 20.5563194s

Successfully signed: <obscurecFolder>/MyProject.exe

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

Por que o signtool.exe não continua quando executado pelo DevOps, mas funciona bem no meu ambiente local?

azure
Prev
Próximo