UncleBob's questions

Temos um web-service, o(s) frontend(s) para o qual é dividido em vários aplicativos que são entregues por endpoints cloudfront. Atualmente, todos eles têm seus próprios subdomínios, como, por exemplo, service-a.mydomain.com, service-b.mydomain.com, etc.

No entanto, subdomínios quase não têm impacto em como o Google estabelece autoridade de domínio atualmente, e a autoridade de domínio se tornou o Santo Graal do SEO. Então, para fins de otimização de mecanismos de busca, queremos mover tudo para um caminho em um domínio de nível superior. Então, depois, deve ser meudominio.com/serviço-a, meudominio.com/serviço-b etc.

Obviamente, isso parece exigir um proxy, como um gateway de API ou algo assim, para rotear tudo. O problema com isso é... bem, se tudo passa pelo mesmo proxy, então as principais vantagens do cloudfront (ou qualquer outro CDN) praticamente vão por água abaixo. Claro que você pode executá-lo por trás do proxy, mas tudo o que você tem então é um cache. Adeus, edge locations. Nesse ponto, faria mais sentido ter o cache no próprio proxy, realmente.

Então, minha pergunta é: ainda há alguma maneira de usar os locais de borda do cloudfront se eu não puder dar a cada ponto final seu próprio subdomínio? Ou essa forma de design de domínio simplesmente requer abandonar as vantagens de uma CDN?

Configurei uma nova máquina com o Ubuntu 20 e descobri que não conseguia mais me conectar aos meus bancos de dados RDS.

O aplicativo spring-boot que deveria se conectar ao ambiente de desenvolvimento lança a seguinte exceção:
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

Então eu desenterrei mySql workbench e tentei com isso. Isso resultou neste erro:
ssl_choose_client_version:unsupported protocol

Procurar por isso me ensinou que o Ubuntu 20 tinha o TLSv1.2 definido como a versão mínima do TLS e que esse erro ocorre se o seu servidor MySQL não o suporta (a partir daqui: https://askubuntu.com/questions/1193629/why -mysql-workbench-8-x-errors-out-with-an-ssl-connection-error-choose-client-v ). Eu tentei o workbench com o SSL desativado e, com certeza, ele poderia estabelecer a conexão.

O problema óbvio disso é que este é o Amazon RDS ... TLS 1.2 é a única versão que não pode ser desabilitada, pois é a versão usada internamente, conforme apontado aqui: https://docs.aws.amazon.com /AmazonRDS/latest/UserGuide/SQLServer.Ciphers.html

Então, realmente, não deve haver um problema. Eu estava começando a duvidar se a versão TLS era realmente o problema. Mas como eu não tinha outras pistas, segui o livro de receitas na resposta aqui para reconfigurar meu openssl local para permitir a versão mínima do TLS 1 e fazer o downgrade do nível de segurança: https://askubuntu.com/questions/1233186/ubuntu- 20-04-how-to-set-lower-ssl-security-level

E você não sabe, Workbench agora conectado com SSL definido como obrigatório. Spring-Boot ainda não, acho que tenho que configurar isso em outro lugar para obter o memorando. Mas em vez de perder tempo com isso, prefiro resolver o problema real , que é que não consigo me conectar por meio do TLSv1.2, enquanto pelo que posso dizer, realmente deveria ser capaz. Isso seria muito preferível a rebaixar minha segurança. Tentei renovar o certificado do banco de dados caso esse possa ser o problema, mas o console de gerenciamento não encontrou nada de errado com o certificado e aparentemente não me permite substituí-lo se não for necessário. Então, estou um pouco sem ideias sobre o que tentar a seguir.

Eu tenho um aplicativo Javascript que é entregue ao navegador a partir de um endpoint do CloudFront. Todos os arquivos estáticos do aplicativo são hospedados em um bucket do S3. Isso envolve um monte de arquivos javascript e css, bem como alguns arquivos de fonte.

O html que carrega toda a aplicação é gerado e entregue por um servidor, vamos chamar esse servidor de "https://my.domain.com".

Como mencionado, este é apenas o arquivo html. Todo o conteúdo estático é então baixado do endpoint do cloudfront, que aponta para um bucket como sua origem. Vamos chamar esses xxxx.cloudfront.net e o bucket de my-bucket.

Pelo que entendi, praticamente qualquer solicitação desse html gerado para o endpoint do cloudfront é uma solicitação CORS, já que a origem do html é my.domain.com e todos os arquivos solicitados claramente não estão hospedados nesse domínio.

Então, naturalmente, fui configurar todas as coisas do CORS. Em primeiro lugar, o bucket é completamente público e possui a seguinte política CORS:

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET"
        ],
        "AllowedOrigins": [
            "*",
        ],
        "ExposeHeaders": [],
        "MaxAgeSeconds": 3000
    }
]

E isso parece funcionar, para tudo... exceto os arquivos de fonte! Eu provavelmente deveria mencionar a estrutura de pastas do bucket. Possui três pastas, produção, desenvolvimento e comum. O conteúdo destes deve ser bastante auto-explicativo. Common contém as fontes, bem como algumas bibliotecas javascript de terceiros. A produção e o desenvolvimento contêm o js e o css para seus respectivos ambientes.

De qualquer forma, tudo carrega, exceto os arquivos de fonte, para os quais recebo o seguinte erro:

Access to font at 'https://xxxx.cloudfront.net/common/fonts/outline/budicon-classic.ttf?jdete2' from origin 'https://my.domain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Pareceu-me extremamente estranho que apenas os arquivos de fonte tivessem esse problema. Outros arquivos na pasta comum parecem ser carregados muito bem, e se eu apenas colar https://xxxx.cloudfront.net/common/fonts/outline/budicon-classic.ttf?jdete2 no meu navegador, ele funciona .

A única diferença parece ser que esses arquivos não são carregados do html, mas do css via @font-face. Observando as solicitações geradas pelo navegador ao carregar o aplicativo, vejo claramente que, por exemplo, o cabeçalho de origem está definido, o que não era para solicitar arquivos js ou css. Set-Fetch-Mode está definido como "cors", enquanto para os outros arquivos foi definido como "no-cors".

De qualquer forma, tentei corrigir o problema no lado da nuvem. Primeiro, adicionei o cabeçalho "Access-Control-Allow-Origin: *" à configuração de origem. Então eu adicionei uma configuração de comportamento para a origem para permitir GET, HEAD, OPTIONS para o padrão de caminho *.

E agora... bem, agora eu ainda tenho o mesmo problema, e estou completamente sem ideias, embora me perguntando por que o pedido criado por @font-face é formado de forma tão diferente quando comparado aos pedidos de recursos javascript e css, mas acima de tudo, o que diabos posso fazer para carregar neles fontes sangrentas?

Eu tentei configurar um novo servidor através do nosso mestre de marionetes. Era para ser um assunto rápido, tudo lá estava funcionando de maneira bastante confiável e ainda está nos servidores mais antigos.

Só que o novo servidor é o primeiro que está rodando o Ubuntu 18, e o fantoche parece não conseguir iniciar os serviços. Aqui está um exemplo de um erro que estou recebendo ao tentar garantir que um serviço esteja em execução:

Error: /Stage[main]/Influxdb/Service[influxdb]/ensure: change from stopped to running failed: Could not find init script for 'influxdb'

Na saída de depuração, posso ver as seguintes coisas:

Executing: '/usr/sbin/service influxdb status'
Service[influxdb](provider=debian): Could not find influxdb in /etc/init.d
Service[influxdb](provider=debian): Could not find influxdb.sh in /etc/init.d

Na verdade, não há nenhum arquivo relacionado ao serviço em /etc/init.d, mas isso nunca foi necessário antes. Se eu executar sudo /usr/sbin/service influxdb statusa partir do console, o comando funciona. Então, por que o agente fantoche não consegue gerenciar o serviço exatamente?

Observe que não tenho 100% de certeza de que o problema está no Ubuntu 18. Essa é apenas a única coisa significativa que posso pensar que mudou e, aparentemente, houve algumas mudanças com o systemd no Ubuntu 18, embora ainda não esteja claro sobre o que eles são exatamente. O que eu gostaria é de uma solução que não exija que eu reescreva todos os meus arquivos de serviço e tenha uma configuração de marionete que funcione nos servidores que ainda executam o sistema operacional antigo, bem como nos servidores que executam o novo. Alguém pode me ajudar a conseguir isso?

Preciso configurar uma rota da nossa rede local para a nossa VPN. Ou seja, qualquer pessoa de dentro da LAN deve poder se comunicar com máquinas na VPN, sem ser um cliente VPN em si . O problema é que eu sou meio bobo quando se trata de redes...

A rede local tem um alcance de 8 bits, 192.168.2.X O próprio servidor VPN está em outra rede, em 192.168.3.20 (8 bits) A rede VPN tem um alcance de 16 bits, 10.8.XX

A interface eth0 da máquina que executa o servidor openvpn possui um IP estático em 192.168.3.20. A interface tun0 do próprio servidor vpn escuta 10.8.0.1

O que já estamos trabalhando é que os pacotes para 10.8.xx na rede local sejam redirecionados para o servidor:

traceroute to 10.8.0.1 (10.8.0.1), 30 hops max, 60 byte packets
 1  gateway (192.168.2.1)  2.508 ms  2.364 ms  2.325 ms
 2  10.8.0.1 (10.8.0.1)  1.898 ms  1.895 ms  1.911 ms

Então eu já posso ssh nele em 10.8.0.1, tudo bem.

No entanto, quando tento acessar um cliente na VPN, o resultado é um pouco diferente:

traceroute to 10.8.0.178 (10.8.0.178), 30 hops max, 60 byte packets
 1  gateway (192.168.2.1)  2.315 ms  2.152 ms  2.036 ms
 2  192.168.3.20 (192.168.3.20)  1.764 ms  1.760 ms  1.776 ms
 3  * * *
etc...

O que me incomoda um pouco sobre isso é que uma solicitação direta ao servidor termina em 10.8.0.1, enquanto eu esperava que não funcionasse ou terminasse em 192.168.3.20. Então, obviamente, eu não entendo muito do que está acontecendo aqui...

A partir daí, pensei que poderia resolver o problema encaminhando o tráfego que chega em eth0 para tun0:

sudo iptables -A FORWARD -i eth0 -o tun0 -d 10.8.0.0/16 -j ACCEPT

Mas isso não surtiu efeito. E é praticamente onde estou preso. Eu tentei algumas variações do acima e brinquei com a rota na configuração do OpenVPN, tudo sem nenhuma alteração visível.

O que é interessante, porém, é que a atividade de rastreamento realmente aparece no

*VPN log, but I don't understand much of what's going on here either:
Fri Oct 19 11:57:53 2018 us=219532 GET INST BY VIRT: 10.8.0.158 -> y18022c/185.184.117.20:1194 via 10.8.0.158
Fri Oct 19 11:57:53 2018 us=219539 y18022c/185.184.117.20:1194 TUN READ [60]
Fri Oct 19 11:57:53 2018 us=219544 y18022c/185.184.117.20:1194 TLS: tls_pre_encrypt: key_id=0
Fri Oct 19 11:57:53 2018 us=219555 y18022c/185.184.117.20:1194 ENCRYPT IV: 14c0471a 9fe7860f
Fri Oct 19 11:57:53 2018 us=219580 y18022c/185.184.117.20:1194 ENCRYPT FROM: 000000ae fa450000 3cac0400 000b1135 5ec0a803 010a0800 9e98b682 bf00282[more...]
Fri Oct 19 11:57:53 2018 us=219612 y18022c/185.184.117.20:1194 ENCRYPT TO: 14c0471a 9fe7860f 00bbfc72 b50c8915 8390d362 82f0a84c c22803b1 2a7ceca[more...]
Fri Oct 19 11:57:53 2018 us=219622 PO_CTL rwflags=0x0002 ev=4 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219629 PO_CTL rwflags=0x0000 ev=5 arg=0x5654a4302068
Fri Oct 19 11:57:53 2018 us=219637 I/O WAIT Tr|Tw|Sr|SW [0/63574]
Fri Oct 19 11:57:53 2018 us=219646 PO_WAIT[0,0] fd=4 rev=0x00000004 rwflags=0x0002 arg=0x5654a4302150 
Fri Oct 19 11:57:53 2018 us=219652  event_wait returned 1
Fri Oct 19 11:57:53 2018 us=219658 I/O WAIT status=0x0002
Fri Oct 19 11:57:53 2018 us=219696 y18022c/185.184.117.20:1194 UDPv4 WRITE [101] to [AF_INET]185.184.117.20:1194: P_DATA_V1 kid=0 DATA c15dc78e ddd12705 8c3a860c 9cd9fe1e da29c4b2 14c0471a 9fe7860f 00bbfc7[more...]
Fri Oct 19 11:57:53 2018 us=219707 y18022c/185.184.117.20:1194 UDPv4 write returned 101
Fri Oct 19 11:57:53 2018 us=219715 PO_CTL rwflags=0x0001 ev=4 arg=0x5654a4302150
Fri Oct 19 11:57:53 2018 us=219722 PO_CTL rwflags=0x0001 ev=5 arg=0x5654a4302068
Fri Oct 19 11:57:53 2018 us=219730 I/O WAIT TR|Tw|SR|Sw [0/63574]
Fri Oct 19 11:57:53 2018 us=231770 PO_WAIT[0,0] fd=4 rev=0x00000001 rwflags=0x0001 arg=0x5654a4302150 
Fri Oct 19 11:57:53 2018 us=231782  event_wait returned 1
Fri Oct 19 11:57:53 2018 us=231789 I/O WAIT status=0x0001
Fri Oct 19 11:57:53 2018 us=231799 UDPv4 read returned 53
Fri Oct 19 11:57:53 2018 us=231809 GET INST BY REAL: 185.184.117.20:1194 [succeeded]
Fri Oct 19 11:57:53 2018 us=231837 y18022c/185.184.117.20:1194 UDPv4 READ [53] from [AF_INET]185.184.117.20:1194: P_DATA_V1 kid=0 DATA 1196c495 845bb7fd e61cc8d8 ed4d427a b901d6c8 e81fe5a9 3ab1acce b5687f0[more...]
Fri Oct 19 11:57:53 2018 us=231846 y18022c/185.184.117.20:1194 TLS: tls_pre_decrypt, key_id=0, IP=[AF_INET]185.184.117.20:1194
Fri Oct 19 11:57:53 2018 us=231859 y18022c/185.184.117.20:1194 DECRYPT IV: e81fe5a9 3ab1acce
Fri Oct 19 11:57:53 2018 us=231876 y18022c/185.184.117.20:1194 DECRYPT TO: 00000036 fa2a187b f3641eb4 cb07ed2d 0a981fc7 48
Fri Oct 19 11:57:53 2018 us=231897 y18022c/185.184.117.20:1194 PID_TEST [0] [SSL-0] [>EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE] 0:53 0:54 t=1539943073[0] r=[0,64,15,0,1] sl=[11,53,64,528]
Fri Oct 19 11:57:53 2018 us=231905 y18022c/185.184.117.20:1194 RECEIVED PING PACKET*

Meu maior problema é realmente que eu não tenho idéia do que exatamente está acontecendo aqui... Por que uma solicitação para 10.8.0.1 não é roteada através de 192.168.3.20? Quero dizer, seria lógico que ele tivesse que passar pelo servidor real antes de terminar na VPN...? E quando os pedidos estão chegando em eth0 (como é evidente por 192.168.3.20 aparecendo no rastreamento), por que eles não são encaminhados para tun0? O próprio openVPN está bloqueando algo aqui?

Temos uma infraestrutura de IoT com dispositivos se comunicando por MQTT. No entanto, agora também temos a exigência de que esses dispositivos enviem os dados do sensor para uma fila de processamento em nuvem que os avalia e armazena.

Como o MQTT não oferece suporte a um modelo puxado, atualmente estou procurando possíveis serviços de enfileiramento para usar. ActiveMQ Artemis chamou minha atenção por causa dos vários protocolos que suporta, entre outras coisas, MQTT e uma interface REST.

O que não consigo ver claramente na documentação, no entanto, é se o Artemis pode servir apenas como um único intermediário para várias filas de mensagens ou se pode realmente ser usado para converter entre eles. O plano até agora era ter um cliente MQTT inscrito no tópico "processamento" que coletaria todas as mensagens publicadas nele e as colocaria em uma fila de votação, onde os trabalhadores viriam para coletá-las. Parece que existe a possibilidade de Artemis fazer isso sem serviços adicionais em execução, mas não tenho certeza se estou interpretando a documentação corretamente.

Então, para fazer uma pergunta direta: posso configurar o Artemis para que eu possa publicar mensagens MQTT nele e depois pesquisá-las em uma fila, usando, por exemplo, a interface REST?