x-yuri's questions

O que estou tentando fazer é iniciar um servidor OpenVPN em ponte no GCP (em uma VM GCE). O que me parece uma parte crucial está no título. Se eu tiver sucesso, o resto será supostamente fácil. Eu tentei duas abordagens:

• O jeito do Arch Linux... o iproute2jeito, na verdade. Eu perguntei sobre isso no fórum do Arch Linux. Os detalhes estão em uma essência .
• O jeito OpenVPN... o bridge-utilsjeito, na verdade. Baseado no script do tutorial oficial . Os detalhes estão em uma essência .

Parece que não é possível fazer isso no GCP ou estou faltando alguma coisa? Qual é? Ou o que posso fazer para investigar melhor o problema?

Estou tentando fazer haproxysolicitações de proxy para várias réplicas:

docker-compose.yml:

services:
  haproxy:
    image: haproxy:2.3-alpine
    volumes:
      - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg
    ports:
      - 8888:80
  app:
    build: .
    command: perl app.pl
    init: true
    deploy:
      replicas: 10

haproxy.cfg:

global
    maxconn  1024
listen in
    bind :80
    server-template srv 10 app:8080 check
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

Mas parece ver apenas algumas das réplicas:

$ docker compose up
...
app-3      | MyWebServer: You can connect to your server at http://localhost:8080/
haproxy-1  | [NOTICE] 094/155107 (1) : New worker #1 (8) forked
app-4      | MyWebServer: You can connect to your server at http://localhost:8080/
app-2      | MyWebServer: You can connect to your server at http://localhost:8080/
app-5      | MyWebServer: You can connect to your server at http://localhost:8080/
app-9      | MyWebServer: You can connect to your server at http://localhost:8080/
app-7      | MyWebServer: You can connect to your server at http://localhost:8080/
app-6      | MyWebServer: You can connect to your server at http://localhost:8080/
app-1      | MyWebServer: You can connect to your server at http://localhost:8080/
app-10     | MyWebServer: You can connect to your server at http://localhost:8080/
app-8      | MyWebServer: You can connect to your server at http://localhost:8080/
app-3      | d3757cd065b4
app-3      | d3757cd065b4
app-3      | d3757cd065b4
app-4      | 226419df4354
app-4      | 226419df4354
app-4      | 226419df4354
...

Mais detalhes aqui .

o que estou perdendo?

Tenho um domínio (exemplo.com) configurado para enviar e receber e-mails usando o Google Workspace. Preciso iniciar adicionalmente um servidor de e-mail separado (próprio). Mudar completamente para o novo servidor é indesejável. A ideia é ter algumas contas de e-mail no Google Workspace e outras no novo servidor.

A solução natural é provavelmente usar subdomínios (1). Nada muda em example.com. Eu simplesmente inicio um servidor de e-mail e o vinculo a, digamos, email.example.com.

Mas há outra ideia que me impressionou (2). Deixe os registros MX apontando para o Google Workspace, mas altere o SPF para permitir que o novo servidor envie e-mails usando o mesmo domínio (exemplo.com). Bem, então me ocorreu que não há como compartilhar a chave privada do DKIM, não é?

Se não consigo configurar o DKIM... não gosto de onde isso me leva. O que você acha? É uma solução que vale a pena tentar ou um beco sem saída?

Quais são os contras? O primeiro é o DKIM. Além disso, não tenho certeza do que acontece se eu enviar um e-mail pelo novo servidor (usando a conta do novo servidor) e o usuário responder. Ele volta para o novo servidor ou para o Google Workspace (considerando que não quero usar um subdomínio)? Eu acho que o último. Estas são duas desvantagens em que consigo pensar.

Quanto aos prós... Não há necessidade de introduzir um subdomínio :) Ok, não parece muito atraente, eu sei. Mas isso é tudo que tenho.

Também me pergunto se alguém tentou? Não creio que seja o primeiro a ter a ideia. E eu esperaria que as pessoas fizessem isso numa época em que o spam não era generalizado. (Presumo que já existiu.) Mas hoje em dia... provavelmente não. Se fossem dois servidores próprios (sem Google Workspace), acho que é possível compartilhar a chave privada do DKIM e então parece uma opção. Caso contrário... provavelmente não é.

O que você acha?

Eu configurei um servidor de e-mail algumas vezes antes e acredito que naquela época pensei que a resposta era “sim”.

Mas estou prestes a configurar outro e parece que me enganei. Digamos que o domínio apex ( example.com) e o (único) registro MX apontem para o mesmo servidor ( mail.example.com). Então posso fazer:

• example.comaponte para o IP do servidor ( aa.aaa.aa.aaa) e aponte de volta (PTR) paraexample.com
• um servidor de e-mail ( postfix, exim, ...) responde com example.com( HELO, MAILFROM)

Então os nomes dos registros SPF, DKIM e DMARC são: @, mail._domainkey(se o seletor for mail) e _dmarc. Ou, para resumir:

@  A  aa.aaa.aa.aaa
@  MX  10  mail
mail  A  aa.aaa.aa.aaa
aa.aaa.aa.aaa  PTR  @

@  TXT  (SPF)
mail._domainkey  TXT  (DKIM)
_dmarc  TXT  (DMARC)

Mas e se eu tiver 2 registros MX ( mail1e mail2)? Então não posso example.comapontar para 2 IPs diferentes e apontá-los de volta example.com, posso? Mas mesmo que eu consiga, posso ver que o Gmail não usa gmail.comfor HELO, MAILFROM. E parece mais sensato cada servidor responder com seu próprio nome, não é? Mas e aí, devo ter 2 registros SPF? Afinal:

a versão atual do SPF – chamada SPFv1 ou SPF Classic – protege o endereço do remetente do envelope

http://www.open-spf.org/Introduction/

@  A  (whatever)

@  MX  10  mail1
mail1  A  aa.aaa.aa.aaa
aa.aaa.aa.aaa  PTR  mail1

@  MX  20  mail2
mail2  A  bb.bbb.bb.bbb
bb.bbb.bb.bbb  PTR  mail2

mail1  TXT  (SPF)
mail2  TXT  (SPF)
mail._domainkey  TXT  (DKIM)
_dmarc  TXT  (DMARC)

Para ser franco, estou confuso depois de ler diversos artigos e respostas sobre como configurar um servidor de e-mail. Qual é a configuração correta ou melhor?

Pelo que posso ver, a conexão via SSL/TLS está sempre disponível com o Cloud SQL. Se eu aplicá-lo, torna-se obrigatório. Mas o nível máximo de proteção que consegui alcançar é verify-cada perspectiva do cliente e do servidor. Aquilo é:

• o servidor não garantirá que ( auth-options) o nome comum no certificado do cliente corresponda ao usuário com o qual estou tentando me conectar (qualquer nome comum pode ser usado)
• o cliente não garantirá que o nome comum no certificado do servidor corresponda ao nome do host ao qual estou me conectando (qualquer nome de host pode ser usado)

De acordo com os documentos com os quais posso me conectarsslmode=verify-full , mas não sei o nome da instância que eles significam ou as informações nos documentos estão desatualizadas. (1) Como posso me conectar com verify-full?

Os documentos também dizem:

Um modo SSL verify-fullnão é necessário; verify-caé suficiente porque a CA é específica da instância.

Nos documentospg posso ver :

A diferença entre verify-cae verify-fulldepende da política da CA raiz. Se uma CA pública for usada, verify-capermite conexões a um servidor que outra pessoa possa ter registrado na CA. Neste caso, verify-fulldeve ser sempre utilizado. Se uma CA local for usada, ou mesmo um certificado autoassinado, o uso verify-cageralmente fornece proteção suficiente.

(2) O que isso significa? Se a CA for local, apenas pessoas autorizadas poderão criar um certificado e uma chave privada e assinar o certificado com o certificado raiz da CA? E embora provavelmente seja possível obter o certificado do servidor (se o servidor for público), mas não é possível obter a chave privada? Como tal, nenhuma pessoa não autorizada pode ter um certificado válido? Assim, se um certificado é válido, foi criado por uma pessoa autorizada, e não importa qual seja o CN? Por que? Parece que estou perto, mas ainda falta algo.

(3) Se a CA for local, verify-ca== verify-full(sem escuta, sem MITM)?

Mais detalhes sobre o que exatamente eu fiz podem ser encontrados aqui .

Parece que é necessário, porque me pede a senha. Mas se sim, então qual é o sentido de ter 2 credenciais (um arquivo de credenciais + senha)?

Se não, então o que estou perdendo?

Os documentos não são muito reveladores sobre isso:

Se solicitado, digite a senha.

Para testá-lo na máquina local eu fiz:

docker-compose.yml:

services:
  app:
    build: .
    command: sleep infinity
    init: true
    volumes:
      - .:/app
    depends_on:
      - proxy

  proxy:
    image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.6.0
    command:
      --address 0.0.0.0
      --credentials-file /credentials.json
      --debug
      myprj:europe-central2:db
    volumes:
      - ./credentials.json:/credentials.json

Dockerfile:

FROM google/cloud-sdk:435.0.1-alpine
RUN apk add terraform postgresql15-client
WORKDIR /app

main.tf:

provider "google" {
  project = "myprj"
}

resource "google_sql_database_instance" "test-auth" {
  deletion_protection = false
  name = "db"
  region = "europe-central2"
  database_version = "POSTGRES_11"
  settings {
    tier = "db-f1-micro"
  }
}

resource "google_sql_user" "test-auth" {
  name = "postgres"
  instance = google_sql_database_instance.test-auth.name
  password = 123456
}

resource "google_service_account" "test-auth" {
  account_id = "dbaccount"
}

resource "google_project_iam_member" "test-auth" {
  project = "myprj"
  role    = "roles/cloudsql.client"
  member  = "serviceAccount:${google_service_account.test-auth.email}"
}

$ gcloud auth application-default login
$ terraform init
$ terraform apply
// create the service account key, copy to ./credentials.json, restart the container
$ psql -h proxy -U postgres

Recentemente, tive um problema em uma instância do EC2. O site em execução ficou indisponível por 2 horas:

Utilização da CPU na última semana:

O resto é na época em que aconteceu:

O systemdjornal em torno desse período.

O que eu posso ver lá? Por volta das 20:31, parece que as coisas ficam lentas:

A execução do trabalho por minuto agendado para as 20h30 atrasou para o minuto subsequente às 20h31. Ignorando a execução do job.

Os trabalhos ( cronyd) não são iniciados.

Jan 12 21:31:29 ip-172-xx-x-xx.xx-yy-z.compute.internal chronyd[24287]: Forward time jump detected!
Jan 12 21:33:21 ip-172-xx-x-xx.xx-yy-z.compute.internal chronyd[24287]: Can't synchronise: no selectable sources

As dhclientfalas, geralmente elas vêm juntas, mas naquela época era assim:

Jan 12 20:46:21 ip-172-xx-x-xx.xx-yy-z.compute.internal dhclient[3066]: DHCPREQUEST on eth0 to 172.xx.x.xx port 67 (xid=0x7cb0e02d)
Jan 12 20:46:22 ip-172-xx-x-xx.xx-yy-z.compute.internal dhclient[3066]: DHCPACK from 172.xx.x.xx (xid=0x7cb0e02d)
Jan 12 21:06:23 ip-172-xx-x-xx.xx-yy-z.compute.internal dhclient[3066]: bound to 172.yy.y.yy -- renewal in 354 seconds.

Também:

Jan 12 21:47:22 ip-172-xx-x-xx.xx-yy-z.compute.internal dhclient[3066]: bound to 172.yy.y.yy -- renewal in -554 seconds.

E parece que às 21:47 as coisas voltam ao normal.

Os dockercontêineres em execução foram reiniciados. Lembro-me que seus logs começaram perto das 22h, provavelmente às 21h47.

O sysstatregistro ( /var/log/sa/sar12):

07:00:01 PM     all      3.77      0.00      0.53      0.00      0.53      0.00      0.11      0.00      0.00     95.05
07:00:01 PM       0      4.22      0.00      0.54      0.01      0.45      0.00      0.11      0.00      0.00     94.68
07:00:01 PM       1      3.33      0.00      0.53      0.00      0.61      0.00      0.10      0.00      0.00     95.43
07:10:01 PM     all      3.47      0.00      0.52      0.00      0.54      0.00      0.13      0.00      0.00     95.34
07:10:01 PM       0      4.01      0.00      0.53      0.00      0.48      0.00      0.10      0.00      0.00     94.88
07:10:01 PM       1      2.93      0.00      0.52      0.01      0.60      0.00      0.15      0.00      0.00     95.80
07:20:01 PM     all      1.89      0.00      0.47      0.00      0.46      0.00      0.10      0.00      0.00     97.08
07:20:01 PM       0      1.54      0.00      0.46      0.00      0.39      0.00      0.10      0.00      0.00     97.50
07:20:01 PM       1      2.24      0.00      0.48      0.00      0.53      0.00      0.10      0.00      0.00     96.65
07:30:01 PM     all      1.37      0.00      0.47      0.00      0.42      0.00      0.09      0.00      0.00     97.65
07:30:01 PM       0      1.55      0.00      0.46      0.00      0.36      0.00      0.08      0.00      0.00     97.54
07:30:01 PM       1      1.18      0.00      0.48      0.00      0.47      0.00      0.10      0.00      0.00     97.77
07:40:01 PM     all      1.32      0.00      0.47      0.00      0.41      0.00      0.10      0.00      0.00     97.71
07:40:01 PM       0      1.46      0.00      0.46      0.00      0.33      0.00      0.09      0.00      0.00     97.66
07:40:01 PM       1      1.18      0.00      0.47      0.00      0.48      0.00      0.10      0.00      0.00     97.77
07:50:01 PM     all      1.36      0.00      0.48      0.00      0.41      0.00      0.10      0.00      0.00     97.65
07:50:01 PM       0      1.14      0.00      0.45      0.00      0.33      0.00      0.11      0.00      0.00     97.96
07:50:01 PM       1      1.58      0.00      0.50      0.00      0.50      0.00      0.09      0.00      0.00     97.33
08:00:01 PM     all      2.17      0.00      0.52      0.01      0.52      0.00      0.12      0.00      0.00     96.66
08:00:01 PM       0      2.26      0.00      0.49      0.01      0.45      0.00      0.13      0.00      0.00     96.67
08:00:01 PM       1      2.08      0.00      0.55      0.01      0.60      0.00      0.12      0.00      0.00     96.65
08:10:01 PM     all      3.47      1.35      2.41      0.08      0.58      0.00      0.15      0.00      0.00     91.96
08:10:01 PM       0      3.28      1.11      2.38      0.07      0.50      0.00      0.15      0.00      0.00     92.51
08:10:01 PM       1      3.66      1.58      2.45      0.09      0.66      0.00      0.15      0.00      0.00     91.40

08:10:01 PM     CPU      %usr     %nice      %sys   %iowait    %steal      %irq     %soft    %guest    %gnice     %idle
08:20:01 PM     all      1.73      0.00      0.54      0.07      0.48      0.00      0.10      0.00      0.00     97.07
08:20:01 PM       0      1.94      0.00      0.58      0.07      0.40      0.00      0.10      0.00      0.00     96.90
08:20:01 PM       1      1.52      0.00      0.51      0.08      0.55      0.00      0.11      0.00      0.00     97.23
09:50:02 PM     all      2.11      0.11     50.63     43.63      0.09      0.00      0.02      0.00      0.00      3.41
09:50:02 PM       0      3.34      0.09     15.85     77.19      0.07      0.00      0.02      0.00      0.00      3.45
09:50:02 PM       1      0.93      0.12     83.90     11.54      0.11      0.00      0.02      0.00      0.00      3.37
10:00:01 PM     all      2.11      0.00      0.43      2.61      0.35      0.00      0.07      0.00      0.00     94.42
10:00:01 PM       0      1.87      0.00      0.45      2.73      0.25      0.00      0.07      0.00      0.00     94.63
10:00:01 PM       1      2.36      0.00      0.42      2.50      0.45      0.00      0.07      0.00      0.00     94.20
10:10:01 PM     all      0.80      0.00      0.33      0.00      0.29      0.00      0.06      0.00      0.00     98.52
10:10:01 PM       0      0.82      0.00      0.31      0.00      0.20      0.00      0.07      0.00      0.00     98.59
10:10:01 PM       1      0.77      0.00      0.35      0.00      0.37      0.00      0.06      0.00      0.00     98.45
10:20:01 PM     all      0.85      0.00      0.35      0.00      0.29      0.00      0.07      0.00      0.00     98.44
10:20:01 PM       0      0.85      0.00      0.34      0.00      0.21      0.00      0.07      0.00      0.00     98.53
10:20:01 PM       1      0.86      0.00      0.36      0.00      0.37      0.00      0.06      0.00      0.00     98.35
10:30:01 PM     all      1.41      0.00      0.38      0.00      0.33      0.00      0.08      0.00      0.00     97.79
10:30:01 PM       0      1.13      0.00      0.36      0.00      0.25      0.00      0.07      0.00      0.00     98.18
10:30:01 PM       1      1.69      0.00      0.40      0.00      0.42      0.00      0.09      0.00      0.00     97.40
10:40:01 PM     all      0.98      0.00      0.35      0.00      0.29      0.00      0.06      0.00      0.00     98.32
10:40:01 PM       0      0.70      0.00      0.33      0.00      0.22      0.00      0.06      0.00      0.00     98.69
10:40:01 PM       1      1.25      0.00      0.36      0.00      0.35      0.00      0.07      0.00      0.00     97.96
10:50:01 PM     all      0.65      0.00      0.34      0.00      0.28      0.00      0.06      0.00      0.00     98.68
10:50:01 PM       0      0.80      0.00      0.34      0.00      0.20      0.00      0.05      0.00      0.00     98.61
10:50:01 PM       1      0.50      0.00      0.34      0.00      0.35      0.00      0.06      0.00      0.00     98.75

Há um intervalo entre 8h20 e 9h50, e somente às 9h50 vemos a carga (3% ocioso).

O que pode ser relevante aqui, em 04 de janeiro habilitei a sincronização de tempo ( timedatectl set-ntp true) porque houve deslocamento de 15 minutos:

Relógio do sistema errado em -910,996745 segundos

É uma t3a.mediuminstância. E acredito que a especificação de crédito era ilimitada até então. Pelo menos foi o que vi no dia seguinte. De qualquer forma, o saldo de crédito não atingiu o chão.

Você pode explicar isso? O que posso verificar?

Para ser justo, não posso ter certeza de que não pode ser causado pelo site ou por um de seus componentes, mas não encontrei esses problemas.

UPD O problema pode ter sido causado por vazamento de memória em um dos contêineres. Pelo menos depois de fazê-lo executar nokogiritarefas em processos separados, a memória parou de crescer e não houve incidentes semelhantes até agora.

Eu tenho um servidor rodando Debian 8. Sim, um bem antigo. Mas há algo realmente estranho nisso. Não consigo me conectar a ele por HTTPS:

$ curl -sSLv https://example.com
*   Trying xx.yyy.xx.yyy:443...
* Connected to example.com (xx.yyy.xx.yyy) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:443 
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to example.com:443 

$ sslscan example.com
Version: 2.0.11
OpenSSL 1.1.1m  14 Dec 2021

Connected to xx.yyy.xx.yyy

Testing SSL server example.com on port 443 using SNI name example.com

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   disabled
TLSv1.3   disabled

  TLS Fallback SCSV:
Connection failed - unable to determine TLS Fallback SCSV support

  TLS renegotiation:
Session renegotiation not supported

  TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support

  Heartbleed:

  Supported Server Cipher(s):
Certificate information cannot be retrieved.

$ dpkg -l | grep openssl
ii  openssl                             1.0.1t-1+deb8u12             amd64        Secure Sockets Layer toolkit - cryptographic utility

$ cat /etc/nginx/nginx.conf | grep ssl
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

$ dpkg -l | grep nginx
ii  nginx                               1.6.2-5                      all          small, powerful, scalable web/proxy server
ii  nginx-common                        1.6.2-5                      all          small, powerful, scalable web/proxy server - common files
ii  nginx-full                          1.6.2-5                      amd64        nginx web/proxy server (standard version)

Para compará-lo com outro servidor Debian 8:

$ sslscan example2.com
Version: 2.0.11
OpenSSL 1.1.1m  14 Dec 2021

Connected to xx.xxx.xx.xxx

Testing SSL server example2.com on port 443 using SNI name example2.com

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   enabled
TLSv1.1   enabled
TLSv1.2   enabled
TLSv1.3   disabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Secure session renegotiation supported

  TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support

  Heartbleed:
TLSv1.2 not vulnerable to heartbleed
TLSv1.1 not vulnerable to heartbleed
TLSv1.0 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 1024 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA256         DHE 1024 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA            DHE 1024 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-CAMELLIA256-SHA       DHE 1024 bits
Accepted  TLSv1.2  256 bits  AES256-GCM-SHA384            
Accepted  TLSv1.2  256 bits  AES256-SHA256                
Accepted  TLSv1.2  256 bits  AES256-SHA                   
Accepted  TLSv1.2  256 bits  CAMELLIA256-SHA              
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA256       Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-GCM-SHA256     DHE 1024 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA256         DHE 1024 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA            DHE 1024 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-CAMELLIA128-SHA       DHE 1024 bits
Accepted  TLSv1.2  128 bits  AES128-GCM-SHA256            
Accepted  TLSv1.2  128 bits  AES128-SHA256                
Accepted  TLSv1.2  128 bits  AES128-SHA                   
Accepted  TLSv1.2  128 bits  CAMELLIA128-SHA              
Preferred TLSv1.1  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.1  256 bits  DHE-RSA-AES256-SHA            DHE 1024 bits
Accepted  TLSv1.1  256 bits  DHE-RSA-CAMELLIA256-SHA       DHE 1024 bits
Accepted  TLSv1.1  256 bits  AES256-SHA                   
Accepted  TLSv1.1  256 bits  CAMELLIA256-SHA              
Accepted  TLSv1.1  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.1  128 bits  DHE-RSA-AES128-SHA            DHE 1024 bits
Accepted  TLSv1.1  128 bits  DHE-RSA-CAMELLIA128-SHA       DHE 1024 bits
Accepted  TLSv1.1  128 bits  AES128-SHA                   
Accepted  TLSv1.1  128 bits  CAMELLIA128-SHA              
Preferred TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.0  256 bits  DHE-RSA-AES256-SHA            DHE 1024 bits
Accepted  TLSv1.0  256 bits  DHE-RSA-CAMELLIA256-SHA       DHE 1024 bits
Accepted  TLSv1.0  256 bits  AES256-SHA                   
Accepted  TLSv1.0  256 bits  CAMELLIA256-SHA              
Accepted  TLSv1.0  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.0  128 bits  DHE-RSA-AES128-SHA            DHE 1024 bits
Accepted  TLSv1.0  128 bits  DHE-RSA-CAMELLIA128-SHA       DHE 1024 bits
Accepted  TLSv1.0  128 bits  AES128-SHA                   
Accepted  TLSv1.0  128 bits  CAMELLIA128-SHA              

  Server Key Exchange Group(s):
TLSv1.2  128 bits  secp256r1 (NIST P-256)

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength:    4096

Subject:  example2.com
Altnames: DNS:example2.com
Issuer:   R3

Not valid before: Dec 17 21:00:13 2021 GMT
Not valid after:  Mar 17 21:00:12 2022 GMT

$ dpkg -l | grep openssl
ii  openssl                          1.0.1k-3+deb8u2                                amd64        Secure Sockets Layer toolkit - cryptographic utility

$ cat /etc/nginx/nginx.conf | grep ssl
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

$ dpkg -l | grep nginx
ii  nginx                            1.6.2-5                                        all          small, powerful, scalable web/proxy server
ii  nginx-common                     1.6.2-5                                        all          small, powerful, scalable web/proxy server - common files
ii  nginx-full                       1.6.2-5                                        amd64        nginx web/proxy server (standard version)

O que há de errado com o primeiro servidor? Como faço o https funcionar?

Eu sei que o site que recebi faz uso do ElasticSearch. Eu sei que ele se conecta ao ElasticSearch por meio de um IP privado (domínio). Eu posso ver este IP no console do EC2 em Interfaces de Rede. A coluna Status diz "em uso", mas sem ID de instância. Qual é o problema? Existe uma maneira de descobrir onde o ElasticSearch está sendo executado? Ainda não recebi acesso SSH às instâncias do EC2.

Geralmente, uma ponte de rede é um dispositivo L2 que conecta vários segmentos de rede em um. Ele não possui IPs e basicamente apenas envia quadros para todos os segmentos, exceto aquele do qual foi recebido (ou mais inteligente).

Mas com uma ponte Linux você obtém uma interface com um endereço IP. Considere o seguinte diagrama com dockercontêineres:

_{(fonte: docker.com )}

Neste caso, as interfaces de que estou falando são docker0e my_bridge.

Em seguida, você usa vethpares para conectar contêineres a uma ponte. Uma extremidade de um vethpar é representada por uma interface com um endereço IP que você pode ver em um contêiner. A outra extremidade não tem endereço IP, pertence ao namespace de rede do host. E você pode ver master docker0ou algo próximo a ele na ip asaída. Pode-se pensar nessa extremidade de um par como um conector que você conecta na porta de uma ponte.

Além disso, posso ver a 172.17.0.0/16 dev docker0 ...regra na tabela de roteamento do host, que possibilita o envio de pacotes do host para um contêiner.

Mas também posso enviar pacotes de um contêiner para a eth0interface do host. Que está em uma sub-rede diferente. E não consigo ver ao lado da interface master docker0do host na saída. O que provavelmente não faria sentido de qualquer maneira, já que uma ponte não pode conectar diferentes sub-redes. Portanto, esta parte (e a do parágrafo anterior) provavelmente não pode ser considerada parte da ponte. Em vez disso, como um comportamento extra que vem com uma ponte Linux.eth0ip a

Além disso, quando envio pacotes de um contêiner para outro, posso vê-los no namespace de rede do host (o host os iptablesprocessa).

Não importa o quanto eu tente, não consigo imaginar um diagrama com uma ponte Linux que eu não possa escolher. Quanto ao diagrama acima, parece que a ponte conecta diferentes sub-redes, o que uma ponte física não pode realizar.

Eu provavelmente prefiro colocar a ponte entre my_bridgee vethpares. Mas então deve-se admitir que você conecta as extremidades dos vethpares em my_bridge, não na ponte. E isso com uma ponte vem a capacidade de enviar pacotes do host para um contêiner e de um contêiner para a eth0interface do host.

Portanto, parece que uma ponte Linux é uma ponte de rede com algumas reviravoltas extras. E você não pode facilmente descrevê-lo em um diagrama sem introduzir imprecisões, pode? Eu estava errado sobre alguma coisa acima?

Estou tentando entender iptablesas regras adicionadas por docker, mas minhas habilidades nesse sentido estão longe de ser fortes.

Uma das coisas sobre as quais não tenho certeza é, digamos, que estou nginxexecutando e faço curl localhost, ou curl ETH0_IP(no mesmo host). Os pacotes que fluem entre curle nginxsão processados ​​por iptables(podem ser afetados pelas regras)?

Preciso de ambos para instalar pacotes? Qual é o objetivo de cada um deles?

Estou pensando em adicionar um SPF a um domínio. Portanto, estou preocupado se houver circunstâncias em que meu MTA usaria algum relé ao enviar e-mails. Tipo, quando os servidores de destino estão muito ocupados ou algo assim? Estou interessado principalmente nas configurações padrão de postfix's ou 's.exim

Um dos meus servidores ficou sem espaço recentemente. Então comecei a pesquisar sobre isso. Os nginxlogs ocuparam metade da partição. Além disso, notei uma coisa estranha. Para muitos sites (60%) rotações extras quando presentes ( example.com-access.log.53.gzquando rotate 52). E a maioria dos maiores - mas não todos - tinha apenas duas rotações:

example.com-access.log
example.com-access.log.53.gz

50% das toras tinham apenas essas duas rotações. Às vezes havia apenas buracos nas rotações (30%): uma lima ou mais. *.log.1muitas vezes faltava (25%). Às vezes havia ambos *.log.1e *.log.1.gz(2 de 172).

Você pode explicar essas rotações ausentes/duplicadas? *.log+ *.log.53.gzcase me faz pensar que em algum momento não foi possível girar *.log.1para *.log.2.gz. Mas não iria parar depois de mal sucedida gzip? Então não deve haver buracos. Ou pelo menos deve estar *.log.1presente se não estiver, não deve?

Estou executando o servidor Debian, se alguma coisa.

/etc/logrotate.conf:

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0660 root utmp
    rotate 1
}

# system-specific logs may be configured here

/etc/logrotate.d/nginx:

/var/log/nginx/*.log {
    weekly
    missingok
    rotate 52
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    size 50M
    sharedscripts
    prerotate
        if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
            run-parts /etc/logrotate.d/httpd-prerotate; \
        fi \
    endscript
    postrotate
        [ -s /run/nginx.pid ] && kill -USR1 `cat /run/nginx.pid`
    endscript
}

/etc/logrotate.d/httpd-prerotatenão existe.

Nos servidores Debian Jessie, vejo systemd-timesyncdescutando em portas UDP aleatórias. O que não é o caso dos hosts Debian Stretch. Por aleatório quero dizer que a porta que ele escuta varia de servidor para servidor. Ele precisa ouvir uma porta UDP para funcionar corretamente? Eu quero bloquear portas que não são necessárias. Isso significa que tenho que deixar todas as portas UDP abertas?

Estou tentando fazer com que os contêineres LXC usem endereços IP estáticos. Para isso eu especifico

lxc.network.ipv4 = 10.0.3.3
lxc.network.ipv4.gateway = 10.0.3.1

no lxcarquivo de configuração. Eu tenho apenas interface de loopback /etc/network/interfacesem contêineres. E na maioria das vezes funciona. Exceto para resolução de nomes de domínio. Existe uma maneira de fazer algo semelhante ao que a dns-nameserversestrofe /etc/network/interfacesfaz no lxcarquivo de configuração?

Por enquanto estou pensando em mover as configurações de rede dentro do container.

Considere o seguinte texto datilografado:

# export DEBIAN_FRONTEND="noninteractive"

# sudo debconf-set-selections <<< "mysql-community-server mysql-community-server/remove-data-dir boolean true"

# echo GET mysql-community-server/remove-data-dir | debconf-communicate
0 true

# apt purge mysql-*
...

# echo GET mysql-community-server/remove-data-dir | debconf-communicate
10 mysql-community-server/remove-data-dir doesn't exist

# sudo debconf-set-selections <<< "mysql-server mysql-server/root_password password 123456"

# sudo debconf-set-selections <<< "mysql-server mysql-server/root_password_again password 123456"

# echo GET mysql-server/root_password | debconf-communicate
0 123456

# apt install mysql-server-5.6
...

# echo GET mysql-server/root_password | debconf-communicate
0

Então, isso debconf-set-selectionsacontece automaticamente? Ou são os scripts de instalação que fazem isso? Alguma outra opção?

Estou tentando backport nanomsgde jessiepara squeeze. Mas quando eu corro:

dget http://http.debian.net/debian/pool/main/n/nanomsg/nanomsg_0.4~beta+dfsg-3.dsc

Diz:

dscverify: nanomsg_0.4~beta+dfsg-3.dsc failed signature check:
gpg: Signature made Fri 29 Aug 2014 09:49:58 PM EEST using RSA key ID 864CC8BF
gpg: Can't check signature: public key not found
Validation FAILED!!

Vi pessoas sugerindo a instalação debian-keyringdessa versão específica adicionando a linha correspondente a sources.liste APT::Default-Release "stable";aapt.conf . Mas estou preocupado com isso poluindo meu sistema com pacotes do outro lançamento.

E se estamos falando squeezeaqui. Eu não posso colocar stable, apt.confposso? Já que stableé jessieagora. E se eu colocar squeezeaí, é mais uma coisa para não esquecer na hora de atualizar debian.

Eu gostaria que pudesse fazer o download com segurança debian-keyringe jessieadicionar keyring /path/to/debian-keyring.gpga ~/.gnupg/gpg.conf(ou configuraçãoDSCVERIFY_KEYRINGS ?) Para fazê-lo funcionar. É possível? Como devo proceder sobre o assunto?