All perguntas(server)

Nosso objetivo é hospedar um site ASP.NET Core 9.0 no IIS e usar o certificado de cliente para autenticação . O aplicativo web ASP.NET Core está funcionando bem: ao executar diretamente do Kestrel, tudo funciona conforme o esperado, ou seja, o usuário é solicitado a escolher um certificado válido que será usado para autenticá-lo.

O documento diz que a configuração do IIS é limitada a 3 etapas:

1. Selecione o site nas guias de conexões
2. Clique duas vezes na opção Configurações SSL
3. clique na caixa de seleção exigir ssl e selecione o botão de opção exigir na seção de certificados do cliente

Infelizmente, não funciona. Ativamos o Failed Requests Tracing e, com essa configuração, o ASP.NET Core Module sempre encerrará a solicitação com o erro request is not supported:

Observe que o usuário final sempre verá uma página de erro 500 e nem terá a chance de escolher o certificado que será usado para autenticação.

Então, para simplificar as coisas, decidimos remover o aplicativo principal do aspnet da equação e ter um site simples, com uma única página index.html, e ver se pelo menos podemos configurá-lo para que o navegador permita que o usuário escolha um certificado.

Ativamos apenas a vinculação https no site:

E também alterei as configurações SSL padrão:

Também ativamos o Failed request tracing para obter mais informações sobre o que está acontecendo. Esta configuração inicial terminou com o tradicional erro 500:

E aqui está a saída do arquivo de rastreamento de solicitação com falha:

Depois de mais algumas escavações, também encontramos este post . Mais uma vez, atualizamos nosso web.config para que ficasse assim (tivemos que desbloquear as subseções de autenticação no nível raiz):

<security>
  <authentication>
    <anonymousAuthentication enabled="false" />
    <iisClientCertificateMappingAuthentication enabled="true" />
  </authentication>
</security>

Os resultados ainda são os mesmos. Então, fomos em frente e adicionamos um mapeamento de um certificado para um usuário existente (usamos o gerenciador do IIS para fazer as coisas direito):

<security>
    <authentication>
        <anonymousAuthentication enabled="false" />
        <windowsAuthentication enabled="false" />
        <iisClientCertificateMappingAuthentication enabled="true">
            <oneToOneMappings>
                <add userName="XXX" 
                     password="[enc:IISCngProvider:wX....]" 
                     certificate="MIIFTDCCBDSgAwIBAgITdQAAEJsn8Q3PLgZ4iwAAAAAQm..." />
            </oneToOneMappings>
        </iisClientCertificateMappingAuthentication>
    </authentication>
</security>

Mais uma vez, ainda não funciona (ou seja, o usuário nunca tem uma mudança para escolher um certificado). Depois de mais algumas pesquisas, encontramos algumas postagens que dizem que o Windows Auth deve ser habilitado para que funcione. Então, nós o ativamos:

<windowsAuthentication enabled="true" />

Mas não, ainda não está funcionando. Carregar a página nunca me dá a chance de escolher um certificado.

Então, alguém pode me indicar um documento válido que mostre como configurar o IIS para exigir que o cliente apresente um certificado ao navegar em um site?

Não estou conseguindo executar meu projeto webapp em uma instalação nova do Arch Linux. Ele usa docker e docker-compose.yaml para criar DB, servidor nginx etc. Este projeto já está sendo executado em vários PCs e ambientes de nuvem (por alguns anos), então estou pensando se talvez algum novo pacote esteja quebrando o processo de construção dos contêineres.

Meu dockerfile instala alguns pacotes usando APK, mas falha sempre que tento usar node.js. Originalmente, ele tinha um RUN npm installcomando, e para ter certeza de que node era o problema, adicionei um RUN node -vcomando logo após instalar o node. Ambos os comandos falham com a mesma mensagem exata:

=> ERROR [app  6/24] RUN node -v                                                                          0.2s
------                                                                                                          
 > [app  6/24] RUN node -v:                                                                                     
0.197 Error relocating /usr/bin/node: sqlite3session_attach: symbol not found
0.197 Error relocating /usr/bin/node: sqlite3changeset_apply: symbol not found
0.197 Error relocating /usr/bin/node: sqlite3session_create: symbol not found
0.197 Error relocating /usr/bin/node: sqlite3session_changeset: symbol not found
0.198 Error relocating /usr/bin/node: sqlite3session_patchset: symbol not found
0.198 Error relocating /usr/bin/node: sqlite3session_delete: symbol not found
------
failed to solve: process "/bin/sh -c node -v" did not complete successfully: exit code: 127

Node e npm são instalados no início do arquivo:

FROM php:8.2-fpm-alpine
COPY composer.lock composer.json /var/www/html/
WORKDIR /var/www/html/
RUN apk update 
RUN apk add nodejs npm
RUN node -v
(...)

Como posso depurar essa situação? Tentei docker compose up --buildvárias pesquisas no Google por essa mensagem de erro, mas não tive sorte.

Eu já estava fazendo uma pergunta semelhante que era muito específica ( nomeada para uso interno e encaminhando subdomínios específicos ). Para essa pergunta, encontrei uma solução alternativa que não está OK.

Agora estou fazendo uma pergunta mais geral. A pergunta é por que resolver outras zonas depende da configuração da zona "."?

Temos um DNS que não tem acesso à internet, porque queremos que ele resolva apenas nomes de domínio locais. Queremos que ele resolva apenas um domínio externo. Vamos chamá-lo de dmz.example.com. A configuração para essa zona em /etc/named.conf é:

zone "dmz.example.com" in
{
  type forward;
  forwarders { 10.100.1.1; 10.100.1.2; }; // DMZ DNSes
};

Como não queremos que nossos DNSs resolvam domínios externos/de internet, fizemos isso com o arquivo root.servers vazio assim:

zone "."
{
  type hint;
  file "root.servers"; // root.server is empty file
};

Quando o DNS é solicitado para um domínio de internet, ele retorna imediatamente no-answer, pois root.servers está vazio. Para domínios para os quais ele é master ou slave, ele os resolve normalmente. Com essa configuração, o DNS não resolve dmz.example.com.

Então mudamos a configuração da zona "." Definimos para ser uma zona de encaminhamento para ".", mas forwarder é um IP inexistente ou inacessível. Assim:

zone "." in
{
  type forward;
  forwarders { 10.100.100.100; }; // non-existent IP
};

Quando usamos essa configuração para a zona ".", o DNS resolve dmz.example.com, mas não responde mais imediatamente a consultas para domínios de internet. Ele espera o timeout para que o encaminhador responda.

Não gosto disso por dois motivos:

1. O DNS agora faz consultas desnecessárias a IPs inexistentes.
2. Domínios da Internet não são mais resolvidos com uma resposta negativa instantânea.

Como posso fazer com que o DNS resolva dmz.example.com e responda pelos domínios da Internet como antes (instantaneamente, sem tráfego de rede desnecessário)?

Estou encontrando um problema de reescrita de caminho ao usar o Docker Compose com proxy reverso Nginx para implantar um blog Hugo. As solicitações para IP/Hugo-Blog/X/Y/Zestão sendo redirecionadas para IP/X/Y/Zem vez de manter o /Hugo-Blog/prefixo, resultando em erros 404.
No entanto, quando tento acessar IP/Hugo-Blog/X/Y/Z/diretamente (com uma barra final), funciona corretamente.
A mesma estrutura Hugo funciona corretamente no GitHub Pages em https://ri-nai.github.io/Hugo-Blog/.

Detalhes da configuração:

1. Infraestrutura: Tencent Cloud Server (plataforma de nuvem chinesa)
2. Pilha: Docker Compose + proxy reverso Nginx + site estático Hugo

Arquivos de configuração:

1. docker-compose.yaml:

version: '3'
services:
  homepage: # Homepage Site, works fine
    ...
  blog:
    build: ./Hugo-Blog
    container_name: blog
    expose:
      - "80"
    restart: always

  reverse-proxy:
    image: nginx:stable-alpine
    container_name: reverse-proxy
    volumes:
      - ./nginx-proxy/default.conf:/etc/nginx/conf.d/default.conf:ro
    ports:
      - "80:80"
    depends_on:
      - homepage
      - blog
    restart: always

2. Hugo-Blog/Dockerfile:

FROM hugomods/hugo:exts-0.128.0 AS builder
COPY . .
RUN hugo --minify --baseURL "https://ri-nai.github.io/Hugo-Blog/"

FROM nginx:stable-alpine
COPY --from=builder /src/public /usr/share/nginx/html

3. nginx-proxy/default.conf:

server {
    listen 80;
    server_name IP;

    location /Hugo-Blog/ {
        proxy_pass http://blog:80/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    location / {
        proxy_pass http://homepage:80/;
        # ... same headers
    }
}

Tentativa de solução de problemas:

• A configuração confirmada do Hugo funciona corretamente nas páginas do GitHub

• Os contêineres Docker verificados estão em execução e acessíveis internamente

Tenta e espera

• Solicitação paraIP/Hugo-Blog/about

  1. 404 ligadoIP/Hugo-Blog/about
  2. Seguido por 404 emIP/about

• Esperado: comportamento correspondente ao padrão de redirecionamento 301 → 200 das páginas do GitHub, mantendo /Hugo-Blog/o prefixo

Tenho um servidor web com clientes SignarR. A topologia é:

Cliente -- Caddy -- IIS

Cliente - Apenas cliente JS SignalR.

Caddy - Como proxy reverso.

Arquivo exe comum ou serviço WSL 1. (Tentei as duas opções e são as mesmas na minha pergunta). Porta 8811 a 8082. IIS - Aplicativo Api baseado em .Net 8.

Notei que cada cliente cria três conexões TCP, 1 para Caddy + 2 "Espelhadas", embora eu espere duas, Cliente -- Caddy + Caddy -- IIS.

saída netstat (8811 - caddy, clientes conectam-se aqui. 8082 - ligação de site IIS):

TCP    192.168.21.42:8811     CLIENT:57803         ESTABLISHED
TCP    127.0.0.1:8082         SERVER:50121         ESTABLISHED
TCP    127.0.0.1:50121        SERVER:8082          ESTABLISHED

O que significam as linhas 2 e 3?

Por que eles estão ao mesmo tempo?

Uma configuração DHCP. Meu roteador relata um uplik diferente do que

ip = requests.get('https://api.ipify.org').text

faz.

Aqui está um exemplo:

$ curl https://api.ipify.org 46.10.148.15

mas o roteador ainda informa o IP de saída como 10.algo.

Pergunta: Como o IP informado pelo roteador se relaciona com o IP que vejo de serviços externos?

Preciso de ajuda para descobrir por que a carga do meu servidor está aumentando exatamente em :00 a cada hora desde 00:00 de 1º de janeiro de 2025Z.

Tenho um servidor VPS de 16 núcleos e 32 GB no godaddy.com executando o Ubuntu 20.04.6 LTS que atende solicitações de cerca de 10 mil dispositivos IoT. Esses dispositivos espaçam intencionalmente suas solicitações para equilibrar a carga do servidor ao longo do tempo. Cada solicitação leva cerca de 200 mS para ser concluída. A carga média do servidor é de cerca de 10, mas desde o início deste ano, no topo de cada hora, ela atinge um pico de 40+ e depois cai rapidamente.

• Gráficos de carga média e pressão da CPU ao longo do tempo mostram esse pico.
• Gráficos de uso de memória, tcpdump e iostat NÃO mostram esse pico.
• A inspeção de logs do journalctl e do apache NÃO mostra nenhum aumento na atividade do processo durante o pico.

Qualquer ideia sobre o que mais eu possa explorar seria muito apreciada.

A seção SDN do item "Datacenter" da lista do lado esquerdo da GUI desapareceu (ela fica visível muito brevemente quando a página carrega, mas desaparece em uma fração de segundo). Não consigo mais criar nenhuma zona definida por software. Ao tentar criar uma usando CLI, recebo:

root@eridanus:/etc/systemd/network# pvesh create /cluster/sdn/zones --type simple --zone promlan
No 'create' handler defined for '/cluster/sdn/zones'
root@eridanus:/etc/systemd/network#

Nada mais acontece e nenhuma zona é criada.

Suponho que algo esteja errado com a parte do Proxmox que gerencia Redes Definidas por Software. Infelizmente, não sei qual parte é essa (um serviço systemd talvez?), ou qual log posso olhar para obter alguma pista sobre o que está acontecendo.

O que posso observar na minha configuração para que a seção SDN fique visível novamente e seja capaz de gerenciar Redes Definidas por Software por GUI e shell?

Detalhes da configuração: Proxmox VE v8.2.4 Debian bookworm Cluster de 3 nós

Estou executando o metallb há mais de um ano, mas depois de uma atualização malfeita, reinstalei tudo do zero. Depois de reinstalar o metallb, ele conseguiu atribuir IPs externos aos serviços, mas esses serviços estavam inacessíveis. Em uma inspeção mais aprofundada, vi que o alto-falante não estava respondendo a solicitações ARP, e pesquisei mais e vi que o endereço IP nunca foi vinculado à interface de rede do nó. Quando vinculei o endereço IP manualmente executando ip addr add 192.168.1.29/24 dev enp10s0, o endereço imediatamente começou a funcionar e consegui acessar o serviço.

Não tenho certeza do porquê isso não está sendo vinculado automaticamente, presumo que o alto-falante deva estar fazendo isso? Meu ambiente é um cluster Talos 1.9.4 de 2 nós executando o kubernetes 1.32.2. Usando uma instalação nova do metallb 0.14.9 com helm e todos os valores padrão, adicionei o seguinte l2advertisement e ipaddresspool:

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default
spec:
  addresses:
  - 192.168.1.20-192.168.1.99
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: default
  namespace: metallb
spec:
  ipAddressPools:
  - default

Estou usando versões bem avançadas do kubernetes e do metallb, então possivelmente é um bug? Estou olhando o código do alto-falante no GitHub, mas não falo golang

Temos servidores DNS em um ambiente protegido sem acesso à internet e esses servidores resolvem apenas domínios internos que criamos. O arquivo root.servers nesses servidores DNS internos está vazio:

zone "."
{
  type hint;
  file "root.servers"; // root.server is empty file
};

Dessa forma, o DNS interno resolve apenas nomes internos.

Então temos servidores DNS na DMZ que encaminham domínios internos para a DMZ assim:

zone "internal" in
  type forward;
  forwarders { 10.10.10.1; 10.10.10.2; }; // internal DNSes
};

Esses DNSs na DMZ também encaminham endereços de internet de DNSs que resolvem domínios de internet assim:

zone "." in {
  type forward;
  forwarders { 172.20.10.1; 172.20.20.2; }; // DNSes resolving internet domains
};

Dessa forma, o DNS na DMZ resolve domínios internos e de internet. Ele funciona assim há muitos anos.

Agora, precisamos obter certificados assinados de uma CA bem conhecida para alguns servidores na DMZ. Para isso, criamos um subdomínio de internet. Vamos chamá-lo de dmz.example.com.

Criamos uma zona dmz.example.com em servidores de nomes DMZ e a DMZ resolve esses domínios. Queremos resolver esses domínios na rede interna também. Para esse propósito, abrimos o acesso DNS de interno para DMZ e adicionamos uma zona em DNSes internos como esta:

zone "dmz.example.com" in
{
  type forward;
  forwarders { 10.100.1.1; 10.100.1.2; }; // DMZ DNSes
};

Agora, DNSes internos não resolvem dmz.example.com e não acessam DNSes DMZ para obter informações sobre esse domínio. Não consigo entender por que o DNS interno não usa essa configuração de zona? Isso tem algo a ver com o arquivo root.servers vazio e a zona "."?

Na outra direção, onde os DNSs DMZ encaminham domínios internos, funciona.