Ice Drake's questions

Recentemente, fiz algum gerenciamento de cabos (incluindo ethernet). Depois que terminei, descobri que nenhuma das minhas unidades Synology NAS conseguiu se reconectar ao Active Directory no meu servidor de domínio. Para ser exato, elas se reconectavam intermitentemente, mas desconectavam quase todas as outras vezes que eu verificava. Mexer na configuração de domínio no NAS não fez diferença.

Voltando, a única coisa diferente é que instalei as atualizações recentes do servidor antes de desligá-lo para gerenciamento de cabos:

1. Atualização cumulativa de 2024-11 para Windows Server 2016 para sistemas baseados em x64 (KB5046612)
2. Atualização de segurança para SQL Server 2017 RTM GDR (KB5046857)
3. Atualização da pilha de manutenção 2024-09 para Windows Server 2016 para sistemas baseados em x64 (KB5043124)

Tentei reverter desinstalando as atualizações, mas não faz diferença. Após solucionar problemas nos últimos dias, notei algo que não tinha notado antes. A porta Ethernet no Controlador de Domínio tem o NetBIOS sobre TCP/IP desabilitado. A pesquisa diz que o NetBIOS é necessário para que o SMB funcione, o que faz sentido por que as unidades Synology NAS não conseguem se reconectar corretamente se não conseguem fazer o SMB funcionar de forma confiável. (Observe que desabilitei o SMB 1.0 há muito tempo por motivos de segurança e desempenho, e ele funcionou sem problemas quando o SMB 1.0 foi desabilitado.)

No entanto, não consigo descobrir como habilitar o NetBIOS sobre TCP/IP. Não é possível para porta ethernet, vEthernet (Virtual Switch) ?

O que eu tentei:

1. Alterando a configuração na guia WINS da configuração IPv4 de Padrão para Habilitar NetBIOS sobre TCP/IP com IPv6 desabilitado.
2. Edite o registro em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters para todas as interfaces que vi para o valor da chave NetbiosOptions de 0 a 1 .

Pensando que poderia ser um bug do Windows, instalei a atualização mais recente, mas ela ainda está desabilitada: Atualização cumulativa 2024-12 para Windows Server 2016 para sistemas baseados em x64 (KB5048671)

Estou tentando direcionar todo o tráfego HTTPS para o servidor Nginx, onde ele lidará com todas as solicitações como solicitações HTTP para todos os servidores internos. Até agora, consigo fazer com que o modelo abaixo funcione para a maioria dos meus servidores.

server {
    listen 443 default ssl;
    ssl_certificate /etc/letencrypt/live/somesite.com/fullchain.pem;
    ssl_certificate_key /etc/letencrypt/live/somesite.com/privkey.pem;
    server_name somesite.com;

    location ^~ /Service {
      proxy_pass http://192.168.1.2;
    }

    location / {
      proxy_pass http://192.168.1.3;
    }
}

No entanto, estou restrito a sempre ter que combinar https://somesite.com/Service com http://192.168.1.2/Service para que o acima funcione.

Não posso ter https://somesite.com/Service para trabalhar com http://192.168.1.2/Hello .

Ou que não posso direcionar isso para outra porta como https://somesite.com/Service com http://192.168.1.2:3000 .

Por exemplo, quando alterei o acima para isso:

location /Service/ {
    proxy_pass http://192.168.1.2:80/;
}

location / {
    proxy_pass http://192.168.1.3;
}

Usando a seguinte configuração de registro:

log_format upstreamlog '[$time_local] $remote_addr - $remote_user - $server_name to: $upstream_addr: $request upstream_response_time $upstream_response_time msec $msec request_time $request_time';
access_log /var/log/nginx/access.log upstreamlog;

Este é o log que obtive:

[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.2:80: GET /Service/ HTTP/1.1 upstream_response_time 0.004 msec 1611309388.445 request_time 0.004
[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.2:80: GET /Service/js/default.cache.a331c8c3.js HTTP/1.1 upstream_response_time 0.000 msec 1611309388.547 request_time 0.002
[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.2:80: GET /Service/favicon.ico HTTP/1.1 upstream_response_time 0.012 msec 1611309388.757 request_time 0.012
[22/Jan/2021:09:56:28 +0000] 172.56.38.95 - - - somesite.com to: 192.168.1.3:80: GET /api/v1/oauth.json?_=1611309389573 HTTP/1.1 upstream_response_time 0.016 msec 1611309388.771 request_time 0.017

Pode-se ver no log que as três primeiras buscas estão corretas. A quarta está errada. Nenhum outro pedido foi feito depois. Depois de rastrear um pouco mais, percebo que o 192.168.1.2 já tem um servidor Nginx rodando e processando páginas PHP usando FastCGI. Não sei se isso faz diferença ou não.

Então, tentei usar a reescrita em combinação com o que tenho acima, mas encontrei uma página não encontrada. Presumo que não parece funcionar para HTTPS, talvez? Assim, isso me levou a fazer a pergunta de como configurar o Nginx para reverter o proxy com reescrita de URL e HTTPS externamente.