Quero que meu aplicativo seja executado em um cluster Kubernetes e use o certificado montado em um volume definido no meu arquivo deployment.yaml.

Não estou usando o ingress, em vez disso, configurei meu serviço como um LoadBalancer. Não consigo descobrir como fazer esse serviço lidar com a terminação tls. Então, segui o outro caminho, onde devo montar e usar o certificado dentro do pod.

Eu montei um segredo que contém as informações do certificado dentro do arquivo deployment.yaml dos aplicativos. O pod está instalado e funcionando e encontrou esse segredo com sucesso. O único problema é que o servidor web não está configurado para usar o certificado, então meu site não está disponível. Como posso configurar o servidor web para usar o certificado? Ele pode ser definido dentro do comando no arquivo docker?

O servidor web está em execução: npm run preview

Verificando o arquivo package.json, isto é: "preview": "vite preview"

Posso configurar o vite para usar certificados armazenados dentro do contêiner do kubernetes? É possível definir isso no meu dockerfile?

seção de implantação que montou o certificado

          volumeMounts:
            - name: cert-volume
              mountPath: "/etc/ssl/certs"
              readOnly: true
      volumes:
        - name: cert-volume
          secret:
            secretName: my-secret

Verifiquei online e não vejo muita maneira de fazer meu servidor web npm usar esse certificado para terminação TLS. Suspeito de algo que eu possa adicionar ao package.json ou diretamente no dockerfile para apontar para esse diretório dentro do meu contêiner kubernetes.

Alguém tem alguma configuração semelhante ou experiência fazendo isso?

Estou implantando um contêiner em uma instância COS (Container OS). Muito simples.

Quero que ele reinicie diariamente. Qual é a melhor maneira de fazer isso? Uma simples aba CRON que eu poderia configurar na VM? O problema com isso é que precisará ser refeito sempre que a VM for reimplantada.

Resumo da questão

Tenho um cluster Kubernetes 1.30 em execução em 3 servidores AWS EC2, 1 nó mestre e 2 nós de trabalho. Estou tentando implantar um registro de contêiner privado usando a registry:2.8.2imagem do projeto de distribuição CNCF. Segui as etapas listadas abaixo, mas estou recebendo o erro "certificado x509 assinado por autoridade desconhecida" enquanto tento executar um login docker no registro.

Observação: estou usando certificados autoassinados.

Passos para reproduzir

1. Crie certificados autoassinados e autenticação de usuário. Os certificados TLS usam OpenSSL:

   mkdir registry
   cd registry
   mkdir certs
   mkdir auth
   
   openssl req -x509 -newkey rsa:4096 -days 365 -nodes -sha256 -keyout certs/tls.key -out certs/tls.crt -subj "/CN=my-registry" -addext "subjectAltName = DNS:my-registry"
   

2. Use htpasswdpara adicionar autenticação de usuário para acesso ao registro. As credenciais para o registro privado são myuser/mypasswd:

   docker run --entrypoint htpasswd httpd:2 -Bbn myuser mypasswd > auth/htpasswd
   

3. Crie um segredo para montar os certificados (tipo secreto tls):

   kubectl create secret tls certs-secret --cert=/home/ubuntu/day42/registry/certs/tls.crt --key=/home/ubuntu/day42/registry/certs/tls.key
   

4. Crie um segredo para autenticação:

   kubectl create secret generic auth-secret --from-file=/home/ubuntu/day42/registry/auth/htpasswd
   

5. Crie o diretório local e aplique o PV PVC.

6. Crie o pod de registro.

apiVersion: v1
kind: Pod
metadata:
  name: docker-registry-pod
  labels:
    app: registry
spec:
  containers:
  - name: registry
    image: registry:2.8.2
    volumeMounts:
    - name: repo-vol
      mountPath: "/var/lib/registry"
    - name: certs-vol
      mountPath: "/certs"
      readOnly: true
    - name: auth-vol
      mountPath: "/auth"
      readOnly: true
    env:
    - name: REGISTRY_AUTH
      value: "htpasswd"
    - name: REGISTRY_AUTH_HTPASSWD_REALM
      value: "Registry Realm"
    - name: REGISTRY_AUTH_HTPASSWD_PATH
      value: "/auth/htpasswd"
    - name: REGISTRY_HTTP_TLS_CERTIFICATE
      value: "/certs/tls.crt"
    - name: REGISTRY_HTTP_TLS_KEY
      value: "/certs/tls.key"
  volumes:
  - name: repo-vol
    persistentVolumeClaim:
      claimName: registry-pvc
  - name: certs-vol
    secret:
      secretName: certs-secret
  - name: auth-vol
    secret:
      secretName: auth-secret

7. Crie o pod de serviço.

8. Exporte as variáveis ​​de ambiente:

   export REGISTRY_NAME="my-registry"
   Master-->export REGISTRY_IP="10.100.175.12"
   # (Above IP is the NodePort service IP)
   

9. Adicione a entrada abaixo a /etc/hoststodos os nós:

   10.100.175.12 my-registry
   

10. Copie tls.crtpara /usr/local/share/ca-certificatestodos os nós e execute o seguinte comando:

    sudo update-ca-certificates 
    

11. Tente fazer login no registro:

    docker login my-registry:5000 -u myuser -p mypasswd
    

Detalhes do erro

Error response from daemon: Get "https://my-registry:5000/v2/": tls: failed to verify certificate: x509: certificate signed by unknown authority

Saída decrictl info

crictl info |grep -i tls
    "enableTLSStreaming": false,
      "tlsCertFile": "",
      "tlsKeyFile": ""

Seguindo os documentos disponíveis do GCP aqui: https://cloud.google.com/artifact-registry/docs/repositories/cleanup-policy

Configurei a política de limpeza no meu repositório de artefatos com a opção de execução a seco habilitada, mas não consegui gerar nenhum log de auditoria usando o comando.

gcloud logging read 'protoPayload.serviceName="artifactregistry.googleapis.com" AND protoPayload.request.parent:"projects/gift-service-app-jm/locations/australia-southeast1/repositories/gcf-artifacts" AND protoPayload.request.validateOnly=true' \
    --resource-names="projects/gift-service-app-jm" \
    --project=gift-service-app-jm

Consegui confirmar que a política foi definida e a opção de execução a seco está habilitada usando o gcloud artifacts repositories describe gcf-artifactscomando

{
  "cleanupPolicies": {
    "Delete Previous Versions": {
      "action": "DELETE",
      "condition": {
        "olderThan": "864000s",
        "tagState": "UNTAGGED"
      },
      "id": "Delete Previous Versions"
    }
  },
  "cleanupPolicyDryRun": true,
  "createTime": "2023-09-27T05:07:31.256470Z",
  "description": "This repository is created and used by Cloud Functions",
  "format": "DOCKER",
  "labels": {
    "goog-managed-by": "cloudfunctions"
  },
  "mode": "STANDARD_REPOSITORY",
  "name": "projects/gift-service-app-jm/locations/australia-southeast1/repositories/gcf-artifacts",
  "updateTime": "2024-07-10T05:39:56.088672Z"
}

Alguém já teve esse problema antes? Eu apliquei a função de proprietário ao meu principal do IAM, mas também tentei adicionar as funções de visualizador de logs e visualizador de logs privados explicitamente.

Eu tinha um AKS com complemento AGIC ativado e preciso mudar para AGIC como um gráfico de leme ( https://learn.microsoft.com/en-us/azure/application-gateway/ingress-controller-install-existente ) em um tento conectar dois clusters AKS a um único gateway de aplicativo, mas como posso alterar a forma como o AGIC foi configurado? Eu pensei que executar disable addon resolveria o problema, mas quando tentei aplicar o arquivo helm-config, recebi esta mensagem de erro:

Error: INSTALLATION FAILED: Unable to continue with install: IngressClass "azure-application-gateway" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "ingress-azure-1710484411"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "ingress-nginx"

Além disso, por algum motivo, tenho que alternar manualmente a tabela de rotas de sub-rede do Gateway quando o conecto a um dos serviços de cada AKS, o que anula o propósito de poder conectar 2 AKS ao gateway, queria saber se existe uma solução para isso também ou uma maneira de contornar isso. Obrigado!

Atualmente estou me conectando ao meu servidor via ssh. Eu também tenho um proxy squid em execução no mesmo servidor e gostaria de poder me conectar ao ssh por meio do proxy, provavelmente com o ssh ocorrendo no servidor localhost?

Tentar fazer isso atualmente me dá uma resposta 403.

O que preciso alterar na minha configuração para que funcione?

Além disso, isso é considerado uma boa prática, pois permitirá eliminar a porta dedicada ssh no lado do servidor?

Copio e colo a parte do meu main.tfarquivo:

resource "aws_security_group" "servers" {
  name        = "allowservers"
  description = "Allow TCP:8080 inbound traffic to servers"
  vpc_id      = module.vpc.vpc_id

  ingress {
    from_port   = 8080
    to_port     = 8080
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_launch_configuration" "ubuntu" {
  image_id        = "ami-053b0d53c279acc90"
  instance_type   = "t2.micro"
  associate_public_ip_address = true
  security_groups = [aws_security_group.servers.id]

  user_data = <<-EOF
              #!/bin/bash
              echo "Hello, World" > index.html
              nohup busybox httpd -f -p ${var.server_port} &
              EOF
   # Required when using a launch configuration with an ASG.
  lifecycle {
    create_before_destroy = true
  }
}

data "aws_vpc" "my-vpc" {
}

data "aws_subnets" "my-vpc-subnets" {
    filter {
      name = "vpc-id"
      values = [data.aws_vpc.my-vpc.id]
    }
}

resource "aws_autoscaling_group" "ubuntu_scaling" {
  launch_configuration = aws_launch_configuration.ubuntu.name
  vpc_zone_identifier = data.aws_subnets.my-vpc-subnets.ids

  target_group_arns = [aws_lb_target_group.asg.arn]
  health_check_type = "ELB"

  min_size = 2
  max_size = 10

  tag {
    key                 = "Name"
    value               = "terraform-asg-ubuntu"
    propagate_at_launch = true
  }
}

resource "aws_lb" "ubuntu-lb" {
    name = "terraform-asg-ubuntu"
    load_balancer_type = "application"
    subnets = data.aws_subnets.my-vpc-subnets.ids
    security_groups = [aws_security_group.alb.id]
}

resource "aws_lb_listener" "ubuntu-lb-listener" {
    load_balancer_arn = aws_lb.ubuntu-lb.arn
    port = 80
    protocol = "HTTP"

    #By default, return a simple 404 page
    default_action {
      type = "fixed-response"

      fixed_response {
        content_type = "text/plain"
        message_body = "404:ups"
        status_code = 404
      }
    }
}

resource "aws_security_group" "alb" {
  name = "terraform-asg-ubuntu"
  vpc_id   = data.aws_vpc.my-vpc.id
  # Allow inbound HTTP requests
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow all outbound requests
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_lb_target_group" "asg" {
  name     = "terraform-asg-example"
  port     = var.server_port
  protocol = "HTTP"
  vpc_id   = data.aws_vpc.my-vpc.id

  health_check {
    path                = "/"
    protocol            = "HTTP"
    matcher             = "200"
    interval            = 15
    timeout             = 3
    healthy_threshold   = 2
    unhealthy_threshold = 2
  }
}

resource "aws_lb_listener_rule" "asg" {
    listener_arn = aws_lb_listener.ubuntu-lb-listener.arn
    priority = 100

    condition {
      path_pattern {
        values = ["*"]
      }
    }
    action {
      type = "forward"
      target_group_arn = aws_lb_target_group.asg.arn
    }
}

Ele gera - quando executo terraform apply- o erro abaixo:

│ Error: creating ELBv2 application Load Balancer (terraform-asg-ubuntu): InvalidConfigurationRequest: A load balancer cannot be attached to multiple subnets in the same Availability Zone
│       status code: 400, request id: 44b2abdb-a321-4f1e-bd6f-4b87aa943477
│
│   with aws_lb.ubuntu-lb,
│   on main.tf line 172, in resource "aws_lb" "ubuntu-lb":
│  172: resource "aws_lb" "ubuntu-lb" {

Estou usando também vpco módulo no modules.tfarquivo:

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"
  name = "my-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1f"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]

  enable_nat_gateway = true
  enable_vpn_gateway = true

  tags = {
    Terraform = "true"
    Environment = "dev"
  }
}

Com muita depuração ainda não sei como resolver esse problema.

Eu tenho essas regras no iptables:

/sbin/iptables -N LOGGING
/sbin/iptables -A INPUT -j LOGGING
/sbin/iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables Packet Dropped: " --log-level 7
/sbin/iptables -A LOGGING -j DROP

Posso adicionar essas regras também ou devo mudar? Não tenho certeza, se eu duplicar os logs usando "A INPUT -j LOGGING" e "A INPUT -j LOG".

/sbin/iptables -A INPUT -j LOG
/sbin/iptables -A FORWARD -j LOG

quando um usuário tenta se conectar a qualquer computador remoto usando a conexão de área de trabalho remota, a caixa a seguir é exibida. Quando o usuário tenta abrir o arquivo .rdp no computador, não há problemas. Muito confuso

Caixa de erro

É de alguma forma possível acessar o Azure Key Vault e escolher um segredo dentro do cofre para usá-lo em outro serviço. O objetivo é armazenar valores secretos para uso de aplicativos de terceiros. Pelo menos, estou tentando testar isso com o Postman, mas estou tentando descobrir a melhor maneira de acessar o cofre de chaves via GET.

Muito obrigado por quaisquer sugestões!

Tenho a tarefa de converter algumas máquinas virtuais VMWare (sobre as quais conheço um pouco) para Hyper-V. Eu sei que tenho que converter o .vmdkarquivo do VMWare para o .vhdxformato.

O problema é que não consigo encontrar o .vmdkarquivo real da máquina virtual. Há um .vmdkarquivo com o tamanho de 150 GB, mas na verdade é 1 KB e contém:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=975e71e0
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 314572800 VMFS "CRM Module Server-flat.vmdk"

# The Disk Data Base 
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "19581"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "a06670da1183767e899ee15c975e71e0"
ddb.uuid = "60 00 C2 9a 81 64 05 42-5c 9f d9 9f e7 61 ed fe"
ddb.virtualHWVersion = "14"

Percebi CRM Module Server-flat.vmdke procurei, mas não encontrei em lugar nenhum.

O que estou perdendo?

Minha API MinIO está escutando no IP do servidor e na porta 9000. Funciona bem.

No entanto, se eu tentar alterar a porta para 80 e reiniciar o serviço, ele falha ao iniciar:

● minio.service - MinIO
     Loaded: loaded (/etc/systemd/system/minio.service; disabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2021-10-25 12:37:04 CEST; 1s ago
       Docs: https://docs.min.io
    Process: 27026 ExecStartPre=/bin/bash -c if [ -z "${MINIO_VOLUMES}" ]; then echo "Variable MINIO_VOLUMES not set in>
    Process: 27027 ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES (code=exited, status=1/FAILURE)
   Main PID: 27027 (code=exited, status=1/FAILURE)

Oct 25 12:37:03 hel-sto-01 systemd[1]: minio.service: Main process exited, code=exited, status=1/FAILURE
Oct 25 12:37:03 hel-sto-01 systemd[1]: minio.service: Failed with result 'exit-code'.
Oct 25 12:37:04 hel-sto-01 systemd[1]: minio.service: Scheduled restart job, restart counter is at 5.
Oct 25 12:37:04 hel-sto-01 systemd[1]: Stopped MinIO.
Oct 25 12:37:04 hel-sto-01 systemd[1]: minio.service: Start request repeated too quickly.
Oct 25 12:37:04 hel-sto-01 systemd[1]: minio.service: Failed with result 'exit-code'.
Oct 25 12:37:04 hel-sto-01 systemd[1]: Failed to start MinIO.

É um novo servidor Ubuntu 20.04 e não tenho nada ouvindo na porta 80.

Assim que volto para a porta 9000, o MinIO funciona normalmente.

Por favor, ajude.

Eu tenho um cluster OCFS com 4 nós no momento. Gostaria de adicionar mais 6.

O que eu fiz:

• Editei o arquivo /etc/ocfs2/cluster.conf e adicionei todos os nós desejáveis. Então eu copiei para todos os nós.
• Quando tentei montar a partição do Node06, pude ver no dmesg do Node01 que um nó desconhecido estava tentando acessá-lo.
• Em seguida, copiei os diretórios de /sys/kernel/config/cluster/ocfs2/node/Node05-Node10 para os nós existentes Node01-Node04.
• Depois disso, os novos nós puderam se conectar, mas eu estava excedendo o limite de slots, que é de 4 slots.
• Tentei aumentá-lo executando tunefs.ocfs2 -N 10 /dev/sdxX mas ele retorna o erro "tunefs.ocfs2: Trylock falhou ao abrir o dispositivo "/dev/sdxX""

Como aumentar o limite de slots sem derrubar o cluster?

Eu tenho uma conexão de rede Gigabit Intel 82579LM integrada no meu PC HPz420 que executa o Win 10 Pro x64bit. Nas configurações do adaptador de rede não existe a opção "Active Magic Packets", para poder ativar o Wake on Lan. Mesmo que eu pudesse ativar o WOL no BIOS, se o próprio adaptador de rede não tivesse a opção de ativar o wol, ele não funcionaria. Alguém sabe se este adaptador de rede suporta wol ou não?

Estou tentando obter determinados detalhes de discos anexados a uma VM no Azure usando o SDK do Azure python. Eu vim a saber que:

Uma VM terá dois discos anexados a ela quando criada:

1. Disco do sistema operacional (os discos do sistema operacional são anexados com uma letra de unidade C: por padrão)
2. Disco temporário (discos temporários são anexados com uma letra de unidade D: por padrão)

Além disso, podemos adicionar discos de dados extras a uma VM, se precisarmos. O problema é que quando adicionamos um disco de dados, não sabemos qual letra está anexada a esse disco.

Recebo os detalhes de utilização de disco para um disco junto com sua letra de unidade da análise de log do Azure, mas não recebo o nome do disco nesses logs. portanto, não consigo identificar quais são os logs de utilização do disco.

Usando o SDK do Python do Azure, consigo obter o nome e o tamanho do disco, mas não consigo obter a letra do disco.

Quero saber a letra de um disco para conhecer os detalhes de utilização de um determinado disco. Alguém por favor pode me ajudar com isso?

Eu tenho um servidor Supermicro 5019TR-GF recentemente.

No começo eu consigo me conectar ao IPMI via IPMIViewou ipmitoolpara controlar o servidor, mas hoje não consigo mais me conectar ao servidor. O ipmitoolespetáculo:

user@ubuntu-vm:~$ ipmitool -I lanplus -H xx.xx.xx.xx -U ADMIN -P ADMIN sensor list all
Get Device ID command failed: 0xd4 Insufficient privilege level
Get Device ID command failed: 0xd4 Insufficient privilege level
Unable to open SDR for reading

É estranho que eu possa fazer login no Portal da Web, mas não posso usar o IPMI. Qual é o problema e como resolvê-lo?

Atualização 1

Eu tento usar, ipmiutilmas sem sorte.

user@ubuntu-vm:~$ ipmiutil sensor list -N xx.xx.xx.xx -U ADMIN -P ADMIN
ipmiutil sensor version 3.15
Invalid data field in request
ipmilan_open_session error, rv = 0xcc
ipmilan Invalid data field in request
ipmi_open error = 204 Invalid data field in request
ipmiutil sensor, Invalid data field in request

Atualização 2 Finalmente, redefino o IPMI para as configurações padrão de fábrica na interface da web. Agora posso usar o ipmitool novamente. No entanto, não consigo encontrar o motivo que causa esse problema ...

Estou tentando usar macvlanpara criar um container que seja um cidadão de primeira classe na minha lan .

Estou usando um IP estático (embora eu entenda que usando alguns 'truques' é possível usar DHCP também).

Eu entendo que é possível fazer isso com a hostrede , mas estou planejando executar 2 contêineres DNS separados e quero que cada um deles tenha um IP diferente, então hostnão é a solução que estou procurando.

Minha configuração

Detalhes sobre minha configuração de rede e host:

• Roteador Unifi UGS, IP interno:192.168.1.254
• Máscara de rede:192.168.1.0/24
• SO do host: Ubuntu 20.04 LTS (Focal Fossa)
• Versão do Docker 20.10.2, compilação 20.10.2-0ubuntu1~20.04.2
• versão do docker-compose 1.28.5, compilação c4eb3a1f
• O IP do host é recebido por uma interface de ponte (chamada br-lan) que está conectada à minha porta ethernet.

Estou usando [adguard-home][2]como imagem do contêiner de teste, abaixo está a saída de configuração do docker-compose:

version: '3.7'
networks:
  br-lan:
    driver: macvlan
    driver_opts:
      parent: br-lan
    ipam:
      config:
      - gateway: 192.168.1.254
        subnet: 192.168.1.0/24
      driver: default

services:
  adguard:
    dns: # adguards default upstream DNS servers
    - 9.9.9.10
    - 149.112.112.10
    - 2620:fe::10
    - 2620:fe::fe:10
    image: adguard/adguardhome
    mac_address: '00:01:02:03:04:05:06:07' # Some randomized MAC address
    mem_limit: 500mb
    networks:
      br-lan:
        ipv4_address: 192.168.1.53
    restart: unless-stopped
    volumes:
    - /etc/localtime:/etc/localtime:ro
    - /srv/adguard/data/conf:/opt/adguardhome/conf:rw
    - /srv/adguard/data/work:/opt/adguardhome/work:rw

O que funciona

Isso realmente funciona para TCP, posso acessar a WebUI (portas 3000 e 80) e, desde que as consultas DNS sejam feitas sobre TCP, funciona (porta tcp 53).

O próprio contêiner pode acessar a web e, por sua vez, o contêiner pode ser acessado pelo host, bem como pelas máquinas na LAN.

O que não funciona

As consultas DNS UDP falham.

Como estou testando?

Em uma máquina Windows 10 na rede, estou executando o seguinte comando do PowerShell:

# Default (UDP) DNS Query - Fails
❯ Resolve-DnsName -DnsOnly -Server 192.168.1.53 -Name stackoverflow.com # Test regular UDP DNS Query
<# The Error output is
Resolve-DnsName : stackoverflow.com : DNS name does not exist
At line:1 char:1
+ Resolve-DnsName -DnsOnly -Server 192.168.1.53 -Name stackoverflow.c ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (stackoverflow.com:String) [Resolve-DnsName], Win32Exception
    + FullyQualifiedErrorId : DNS_ERROR_RCODE_NAME_ERROR,Microsoft.DnsClient.Commands.ResolveDnsName
#>

# TCP DNS Query - works
❯ Resolve-DnsName -DnsOnly -Server 192.168.1.53 -Name stackoverflow.com -TcpOnly

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
stackoverflow.com                              A      2507  Answer     151.101.65.69
stackoverflow.com                              A      2507  Answer     151.101.129.69
stackoverflow.com                              A      2507  Answer     151.101.193.69
stackoverflow.com                              A      2507  Answer     151.101.1.69

Qual é a minha dúvida e porque estou postando aqui?

Não consigo descobrir por que o UDP falha enquanto o TCP funciona. Minhas pesquisas sobre UDP macvlannão foram frutíferas, e eu esperava que alguém aqui pudesse me orientar sobre como solucionar isso para que eu possa identificar a falha no meu design ou explicar o que posso fazer para corrigir isso.

Estou tentando executar o haproxy em um docker, mas não funciona.

Aqui está o que eu fiz:

1. Criado Dockerfile que contém o seguinte texto:

FROM haproxy:2.3
COPY haproxy.cfg /usr/local/etc/haproxy/haproxy.cfg

2. Este é o meu haproxy.cfg:

global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        timeout connect 10s
        timeout client  60s
        timeout server  60s
#        errorfile 400 /etc/haproxy/errors/400.http
#        errorfile 403 /etc/haproxy/errors/403.http
#        errorfile 408 /etc/haproxy/errors/408.http
#        errorfile 500 /etc/haproxy/errors/500.http
#        errorfile 502 /etc/haproxy/errors/502.http
#        errorfile 503 /etc/haproxy/errors/503.http
#        errorfile 504 /etc/haproxy/errors/504.http

frontend https_in
        mode tcp
        option tcplog
        bind *:443
        acl tls req.ssl_hello_type 1
        tcp-request inspect-delay 5s
        tcp-request content accept if tls
        
        acl host_server1 req.ssl_sni -i my1stdomain.com
        acl host_server2 req.ssl_sni -i my2nddomain.com

        use_backend https_Server if host_server1
        use_backend https_NUC if host_server2

backend https_Server
        mode tcp
#        option tcplog
        option ssl-hello-chk
        server Server 10.0.0.10:443

backend https_NUC
        mode tcp
#        option tcplog
        option ssl-hello-chk
        server NUC 10.0.0.40:443

3. O objetivo é apontar a porta SSL 443 my1stdomain.compara o IP da LAN 10.0.0.10e my2nddomain.compara o IP10.0.0.40

4. O docker deve ficar em 10.0.0.44, então estes são os comandos que executei:

docker build -t my-haproxy .

Resultado:

Sending build context to Docker daemon  4.096kB
Step 1/2 : FROM haproxy:2.3
 ---> 397cf3d55fac
Step 2/2 : COPY haproxy.cfg /usr/local/etc/haproxy/haproxy.cfg
 ---> Using cache
 ---> a5cc1ff3c0c6
Successfully built a5cc1ff3c0c6
Successfully tagged my-haproxy:latest

Então, testei a configuração:

docker run -it --rm --name haproxy-syntax-check my-haproxy haproxy -c -f /usr/local/etc/haproxy/haproxy.cfg
Configuration file is valid

Então, eu tento executá-lo:

docker run -d --name haproxy --restart=always -p 10.0.0.44:443:443/tcp my-haproxy
a253dbce7341e454353e9a2b4278e22ae8172ed106aeec7

Mas, quando executo docker ps, vejo que não está realmente em execução:

docker ps
CONTAINER ID   IMAGE                                     COMMAND                  CREATED              STATUS                          PORTS                                                                    NAMES
a253dbce7341   my-haproxy                                "docker-entrypoint.s…"   About a minute ago   Restarting (1) 12 seconds ago                                                                            haproxy

Alguma sugestão?

Eu usei minha ferramenta de crimpagem RJ45 para Cat5e antes sem problemas, agora eu queria crimpar um plugue Cat6a e tive alguns problemas.

Pesquisei um pouco antes e todas as fontes que encontrei diziam que eu poderia usar a ferramenta de crimpagem para qualquer plugue RJ45. Eu tinha quase certeza de que isso está errado e a ferramenta de crimpagem destruiria o plugue, e quando eu realmente quis crimpá-lo, sem surpresa, ele o destruiu.

O plugue Cat6a não possui "cunha" de plástico que é empurrada para baixo pelo "nariz" do alicate de crimpagem, como o Cat5e, então definitivamente há uma diferença entre os plugues.

Então, qual é o padrão real aqui? Remover o nariz dos plugues Cat6?

PS: Suponho que posso desaparafusar o "nariz" da ferramenta, mas por que essa diferença não é mencionada em nenhum lugar e todo mundo está reiterando essa bobagem de "funciona para tudo"?

Considere a seguinte configuração de rede

                         ┌───────────────┐                                
┌────────────┐           │               │               ┌───────────────┐
│            │           │  2 Port RJ45  │               │               │
│ ISP / DHCP │──────────▶│  Socket Roof  │──────────────▶│ Unifi AP Roof │
│            │           │               │        B      │               │
└────────────┘     A     └───────────────┘               └───────────────┘
                                │  ▲                                      
                                │  │ B                                    
                                │  │                                      
                                │  │                                      
                             CAT6 Split                                   
                                into                                      
                              2x100MBit                                   
                                │  │                                      
                                │  │                                      
                              A │  │                                      
                                │  │                                      
                                ▼  │                                      
                         ┌───────────────┐                                
                         │  2 Port RJ45  │                                
                         │ Socket Ground │     B                          
                      ┌──│     Floor     │◀───────────────────────┐       
                      │  │               │                        │       
                      │  └───────────────┘                        │       
                      │                                           │       
                      │                                           │       
                   A  │                                           │       
                      │                                           │       
                      │      ┌────────┐               ┌────────┐  │       
                      │      │ Unifi  │        B      │ Unifi  │  │       
                      └─────▶│  USG   │──────────────▶│  PoE   │──┘       
                       WAN/1 │        │ LAN/1         │ Switch │          
                             └────────┘               └────────┘                  

Agora, o problema é que há apenas um cabo que vai do telhado até o rack de rede no térreo. Para obter 2 conexões, dividi o cabo CAT6 em 2x100 MBit usando 4 fios cada.

Então a rede é a seguinte:

• O ISP entra no telhado através de um RJ45 padrão (relé de rádio)
• O cabo é então conectado a um soquete de 2 portas (porta A) que liguei para dividir o cabo em 2x100 MBit
• No piso térreo, o cabo Aestá conectado à porta WAN/1 do USG.
• Da porta USG LAN/1 vai para um switch PoE que conecta o resto da lan local
• Uma porta PoE desse switch volta para o soquete de 2 portas na portaB
• A porta Bdo soquete no telhado é então conectada ao AP

Agora eu não posso dizer que eu realmente gosto muito dessa configuração. As razões pelas quais isso é configurado dessa maneira é

1. Eu sou um noob de rede e provavelmente não sei melhor
2. Eu queria alimentar o AP do telhado via POE sem um injetor adicional (não tão importante)
3. Eu queria isolar o DHCP dos ISPs dividindo-o em 2 conexões físicas e usando o DHCP dos USGs (importante)

Então a pergunta é:

Posso atingir esses objetivos sem dividir o cabo em 2x100 MBit, por exemplo, usando um USW Flex Miniswitch?