O problema de DNS mais estranho que eu já vi.
Situação:
No meu servidor de produção, todos os meus domínios funcionam corretamente quando possuem certificados SSL autoassinados. Na minha máquina local, todos os meus domínios no servidor de produção são exibidos corretamente em meus navegadores da Web em:
https://example.com (depois de aceitar o aviso do navegador sobre certificados SSL autoassinados)
Problema:
Imediatamente após obter com sucesso um Let's Encrypt SSL para qualquer um dos meus domínios no servidor de produção, todos os meus navegadores locais não conseguem carregar arquivos https://example.com. No entanto, (a parte estranha) https://www.example.comfunciona perfeitamente corretamente.
Testes:
1.) Eu inicializei na minha partição do Windows 10 e confirmei que https://example.comambos https://www.example.comcarregam corretamente em qualquer navegador da web.
2.) Um amigo em sua rede doméstica, confirmou isso https://example.come https://www.example.comambos carregam em seus navegadores locais sem problemas.
Somente no Ubuntu 20.04 na minha máquina local se https://example.comrecusará a carregar em qualquer navegador da web após o LE SSL ter sido alcançado.
Aspecto Único:
A única coisa que é única na minha configuração do Ubuntu 20.04 é que eu executo um servidor de teste vbox e uso dnsmasq para resolução de DNS local (que pode ser informação irrelevante). Menos todas as coisas extras, minhas /etc/dnsmasq.confconfigurações são:
port=53
bogus-priv
listen-address=127.0.0.1,192.168.58.1
bind-interfaces
expand-hosts
domain=example-site.test
Eu também executo um servidor wireguard do servidor remoto / cliente wireguard na máquina local (no entanto, esse problema persiste independentemente de eu estar conectado ao wireguard ou não)
se eu usá $nslookup prod-server-domain.com -lo corretamente me mostra:
nslookup prod-server-domain.org
Server: 192.xxx.xx.xx <--- wireguard server ip
Address: 192.xxx.xx.xx#53 <--- wireguard server ip
Name: prod-server-domain.org
Address: xxx.xx.xxx.xxx <--- public prod server ip
Simplificado ainda mais:
Após a obtenção bem-sucedida de certificados LE SSL para os nomes de domínio do meu servidor remoto, em todos os navegadores da Web do mundo - exceto - meus navegadores locais do ubuntu os URLs https://example.come https://www.example.comambos funcionam corretamente como esperado, levando exatamente ao mesmo site.
Apenas na minha instalação do Ubuntu https://example.comFALHA
Considerando que https://www.example.comTRABALHOS.
Quando abro https://example.come https://www.example.comem navegadores da web na minha partição do Windows na mesma rede doméstica, com o mesmo endereço IP, ambos https://example.come https://www.example.com ambos funcionam corretamente .
Informação adicional:
Todos os domínios apontam para o endereço IP correto
Eu tenho o mesmo problema se eu desativar completamente o UFW e o Wireguard
O SSL está sendo obtido via Virtualmin, que confirma os envios de URL corretos para atribuição de LE SSL:
(todos dizem example.org)
Firefox e todos os outros navegadores mostram este erro para https://example.org
Considerando que isso funciona perfeitamente em todos os navegadores:
user@machine:~$ curl example.org
curl: (7) Failed to connect to example.org port 80: No route to host
user@machine:~$ curl https://example.org
curl: (7) Failed to connect to example.org port 443: No route to host
user@machine:~$ curl https://www.example.org
<!DOCTYPE html>
<html>
<head>
<title>Virtualmin</title>
<meta charset="utf-8">
Por pedido:
$ ip route list
default via 192.168.0.1 dev eth0 proto dhcp metric 100
default via 192.168.0.1 dev wlp0s20f3 proto dhcp metric 600
169.254.0.0/16 dev eth0 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.13 metric 100
192.168.0.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.0.18 metric 600
compare os resultados de
$nslookup prod-server-domain.come$www.nslookup prod-server-domain.com. Eles estão realmente apontando para o mesmo ip?Eu finalmente percebi isso.
Eu uso dnsmasq e meu servidor DNS externo parou de funcionar.
Escolhi novos servidores DNS externos e agora está tudo bem.
Presumo que seus certificados autoassinados locais funcionem aceitando a notificação de risco em seus navegadores, você os adicionou ao servidor de gerenciamento de certificados local ou ao chaveiro da máquina local.
Primeiro, entenda que Https://www.test.org é, por padrão www, não um subdomínio como Https://toast.test.org, mas um redirecionador imediato para Https://test.org. Mesmo quando valores separados são inseridos em um DNS local, esse serviço deve reclamar que você está tentando redirecionar o mesmo índice para dois destinos diferentes.
O segundo que vi é que seu certificado SSL usa um curinga. Embora os curingas sejam úteis, pois apenas um certificado SSL é necessário para ser mantido, os certificados curinga dificultam a segurança da rede. Eu recomendo que você fique longe deles e realmente configure um gerenciamento de certificados local adequado.
Embora eu não tenha 100% de certeza, é provável que suas configurações e entradas locais interrompam um redirecionamento adequado quando um certificado real estiver em vigor no servidor. Normalmente, configurar um certificado em um servidor invalidará quaisquer certificados autoassinados locais anteriormente apontando para ele. Normalmente, isso é recebido com um oopsidaisy, este servidor mudou seu certificado, você realmente tem certeza de que deseja ir lá m8 warning.
O único lugar para onde sua entrada DNS deve apontar é Https://test.org -> xxxx Para seu serviço principal. Como dito anteriormente, a WWW não deve fazer diferença, pois é um redirecionamento para o acima.
Tente liberar os navegadores de seus clientes e as chaves do sistema operacional de todos esses certificados autoassinados inválidos e o Webservice deve funcionar conforme o esperado. Lembre-se de que, se o seu servidor não for um host exposto, é necessário garantir que as solicitações externas sejam roteadas do seu ponto de entrada da Web para o servidor.