WoJ's questions

Ao testar um POC Zscaler (de uma perspectiva de segurança), tive dificuldade em entender como o CGNAT é roteado no cliente.

Minha principal preocupação (e pergunta) é que a rota 100.64.xy não está na tabela de roteamento (Windows 10). O gateway padrão está no meu gateway de rede local para que o tráfego também não possa ir para lá.

O que há de especial em como o tráfego CGNAT é roteado?

A tabela de roteamento no cliente é

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.43.1   192.168.43.107     50
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
     172.22.208.0    255.255.240.0         On-link      172.22.208.1    271
     172.22.208.1  255.255.255.255         On-link      172.22.208.1    271
   172.22.223.255  255.255.255.255         On-link      172.22.208.1    271
     192.168.43.0    255.255.255.0         On-link    192.168.43.107    306
   192.168.43.107  255.255.255.255         On-link    192.168.43.107    306
   192.168.43.255  255.255.255.255         On-link    192.168.43.107    306
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link    192.168.43.107    306
        224.0.0.0        240.0.0.0         On-link      172.22.208.1    271
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link    192.168.43.107    306
  255.255.255.255  255.255.255.255         On-link      172.22.208.1    271

Abaixo está a resolução de um serviço corporativo interno que está configurado no zscaler (e, portanto, roteado pelo CGNAT). O mesmo nome fora do zscaler aponta para um endereço RFC1918 clássico.

> nslookup internalcorporatesite.com
Server:  xxx.com
Address:  192.168.43.1

Non-authoritative answer:
Name:    internalcorporatesite.com
Address:  100.64.1.9

Observe que o gateway padrão 192.168.43.1não tem conhecimento do CGNAT - é uma rede local e o CGNAT é usado pelo zscaler.

Eu possuo um domínio (digamos, example.com) e queria:

• atualizar automaticamente ext.example.comcom meu DNS público (por meio de um script que fará a atualização assim que o IP fornecido pelo ISP for alterado) → isso funciona
• redirecionar o domínio apex ( example.com) para ext.example.com)
• use um curinga *.example.compara apontar paraext.example.com

Para isso, configurei as entradas DNS relevantes como (+ SOA, NS)

           IN DNAME  ext.example.com.
*          IN CNAME  ext.example.com.
ext     60 IN A      350.299.1.1

Ao consultar ext.example.com, recebo uma resposta estranha: uma concatenação recursiva deext

ext.example.com.            3508    IN      CNAME   ext.ext.example.com.
ext.ext.example.com.        3508    IN      CNAME   ext.ext.ext.example.com.
ext.ext.ext.example.com.    3508    IN      CNAME   ext.ext.ext.ext.example.com.
(about 20 such lines in total)

Parece que a partida é feita em *.example.com(o CNAME) e não ext.example.com(no Aregistro).

Existe uma maneira de forçar a especificidade no DNS? (ou seja, para que o mais específico ext.example.comseja fornecido, em vez do curinga mais geral)

Estou testando uma recuperação bare metal do meu servidor que basicamente inicia um conjunto de contêiner docker com meus serviços. Eu me recuperei de um backup /etc/docker, onde mantenho toda a configuração e volumes persistentes.

Tentei então iniciar um dos containers:

root@srv-backup:/etc/docker# docker-compose --verbose -f /etc/docker/docker-compose.d/20-registry.yaml up
compose.config.config.find: Using configuration files: /etc/docker/docker-compose.d/20-registry.yaml
ERROR: compose.cli.main.main: .IOError: [Errno 2] No such file or directory: '/etc/docker/docker-compose.d/20-registry.yaml'

No entanto, o arquivo está lá:

root@srv-backup:/# ll /etc/docker/docker-compose.d/20-registry.yaml
-rwxrwxr-x+ 1 root root 842 Jan 24 15:19 /etc/docker/docker-compose.d/20-registry.yaml*

root@srv-backup:/# cat /etc/docker/docker-compose.d/20-registry.yaml
services:
  registry:
    container_name: registry
    image: registry
    labels:
      - traefik.http.routers.registry.rule=Host(`registry.example.com`)
      - traefik.http.routers.registry.entryPoints=https
      - traefik.http.routers.registry.tls=true
      - traefik.http.routers.registry.tls.certresolver=le
      - traefik.http.middlewares.lan.ipwhitelist.sourcerange=192.168.10.0/24, 192.168.20.0/24
      - traefik.http.routers.registry.middlewares=lan
      - traefik.enable=true
    restart: unless-stopped
    volumes:
      - /etc/docker/container-data/registry:/var/lib/registry
version: '3'

root@srv-backup:/# file /etc/docker/container-data/registry
/etc/docker/container-data/registry: directory

Eu tentei todos os tipos de encantamentos com caminhos relativos e completos - o problema é o mesmo.

Eu queria saber se o daemon do docker tem acesso ao arquivo, mas também é executado como root:

root@srv-backup:/# ps -ef | grep docker
root      2048     1  0 10:58 ?        00:00:08 dockerd -G docker --exec-root=/var/snap/docker/423/run/docker --data-root=/var/snap/docker/common/var-lib-docker --pidfile=/var/snap/docker/423/run/docker.pid --config-file=/var/snap/docker/423/config/daemon.json
root      2200  2048  0 10:58 ?        00:00:07 containerd --config /var/snap/docker/423/run/docker/containerd/containerd.toml --log-level error

Estou bastante perdido porque não funciona (o arquivo docker funciona corretamente no servidor que estou tentando replicar neste exercício de DRP)

Eu gostaria de um script python como um serviço do Windows, usando sc. O problema é que o caminho para o executável tem um espaço e requer parâmetros.

Portanto

sc create DNSResolver127 binPath= '"C:\Program Files (x86)\Python36-32\python.exe" D:/32dsdnsproxy/32dsdnsproxy.py'

falha (tentei colocar toda a opção entre aspas simples)

Como adicionar tal serviço?

Gostaria de testar a conectividade UDP, iperf3mas não sei como iniciá-la no modo de servidor UDP.

iperf3 -sapenas abre um soquete TCP:

root@srv ~# lsof -i -P | grep iperf3
iperf3    21030            root    3u  IPv4 15606995      0t0  TCP *:5201 (LISTEN)

Instalei wireguardem um servidor em uma LAN e tenho um problema com um pingentre dois componentes. a topologia é a seguinte:

• srvé uma máquina Linux (Ubuntu 18.04) que possui uma interface física com o IP 192.168.10.2e uma interface virtual com o IP192.168.20.1
• remoteé uma máquina que se conecta à LAN via wireguarde tem IP192.168.20.2
• internalé uma máquina na LAN que tem IP192.168.10.5

De um modo geral, as máquinas na LAN real estão dentro 192.168.10.0/24e na VPN em 192.168.20.0/24.
Não há iptablesrestrições em nenhum lugar.
O encaminhamento de IP está ativado no srv.

O problema : eu posso pingar tudo de qualquer lugar, exceto (o IP físico 192.168.10.2da192.168.20.2 NIC no servidor da máquina remota que está na VPN).

Especificamente

• Eu posso alcançar remotetanto do srvlado de wireguard( 192.168.20.1) quanto de qualquer outra coisa na LAN ( 192.156.10.5na lista acima).
  • Eu posso chegar remotede srv(através da VPN)

A tabela de roteamento em srv( br0é a interface "física", na realidade esta é uma ponte, mas não importa aqui)

default via 192.168.10.1 dev br0 proto dhcp metric 1024
192.168.10.0/24 dev br0 proto kernel scope link src 192.168.10.2
192.168.20.0/24 via 192.168.20.1 dev wg0 proto static
192.168.20.0/24 via 192.168.10.2 dev br0 proto dhcp metric 1024

A tabela de roteamento emremote

Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.237.76.1      10.237.78.2     25
      10.237.76.0    255.255.252.0         On-link       10.237.78.2    281
      10.237.78.2  255.255.255.255         On-link       10.237.78.2    281
    10.237.79.255  255.255.255.255         On-link       10.237.78.2    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
     192.168.10.0    255.255.255.0     192.168.20.1     192.168.20.2    135
     192.168.20.0    255.255.255.0         On-link      192.168.20.2    291
     192.168.20.2  255.255.255.255         On-link      192.168.20.2    291
   192.168.20.255  255.255.255.255         On-link      192.168.20.2    291
     192.168.56.0    255.255.255.0         On-link      192.168.56.1    281
     192.168.56.1  255.255.255.255         On-link      192.168.56.1    281
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    281
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    281
        224.0.0.0        240.0.0.0         On-link       10.237.78.2    281
        224.0.0.0        240.0.0.0         On-link      192.168.20.2    291
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    281
  255.255.255.255  255.255.255.255         On-link       10.237.78.2    281
  255.255.255.255  255.255.255.255         On-link      192.168.20.2    291

Qual pode ser a razão de um pacote enviado de 192.168.20.2, embora 192.168.20.1não chegue 192.168.10.2?

Eu tenho um Edgerouter 4 e estou tentando entender as áreas de configuração para DHCP e DNS, quando use-dnsmasq enabledefinido.

Vejo quatro lugares onde a configuração pode ser feita:

1. a partir da linha de comando ( set service dns forwarding ... parece ser a maneira de fornecer parâmetros DNS (mas não DHCP?))

2. editando (EDIT: uma cópia de) /config/config.boote carregando-o

Esses dois parecem estar intimamente ligados, a configuração da linha de comando parece ser escrita para/config/config.boot

3. configurando/etc/dnsmasq.conf

4. adicionando um arquivo/etc/dnsmasq.d

As configurações seguem o dnsmasqarquivo de configuração , tenho o arquivo /etc/dnsmasq.d/dnsmasq-dhcp-config.confque foi criado para mim.

Nota: Eu tenho uma forte preferência pela abordagem onde /etc/dnsmasq.confseria tudo comentado como é hoje, e tenho todas as minhas configurações de DNS e DHCP em arquivos que vivem em /etc/dnsmasq.d. Posso aceitar que esta configuração não será visível na GUI (na DNSpágina).

Minhas perguntas

• Como essas abordagens de configuração funcionam juntas?
• É possível usar apenas a abordagem 3. ou 4.?
• Se sim:
  • há inconvenientes? (= inconvenientes como a necessidade de fazer backup dos arquivos durante uma atualização, falta de visibilidade na GUI, etc.)
  • existem incompatibilidades? (= algo pode ser configurado exclusivamente via 1., 2. ou 3./4.?)

O Aregistro para hello.world.example.compode ser registrado

• como a helloentrada no domínioworld.example.com
• ou como a hello.worldentrada no domínioexample.com

Existe uma diferença prática, do ponto de vista dos serviços que resolvem o nome , entre essas duas abordagens?

Tanto quanto eu posso dizer, a resolução de ambos produz o valor A record (o IP) para que as respostas não sejam discerníveis para o cliente.

Eu tenho dois servidores DNS secundários para uma zona. Um desses servidores, ao receber uma solicitação de um intervalo específico, deve modificar um dos registros.

Para dividir a resposta, estou planejando usar uma visão:

acl dmz { 192.168.0.0/24; localhost; };
acl lan { 10.0.0.0/8; };

view dmz {
  match-clients { dmz; };
  zone "example.info" {
    type slave;
    masters { 10.100.10.254; };
    file "/etc/bind/db.example-dmz.info";
  };

};

view lan {
  match-clients { lan; };
  zone "example.info" {
    type slave;
    masters { 10.100.10.254; };
    file "/etc/bind/db.example-lan.info";
  };

};

A configuração acima divide as respostas, mas as respostas são as mesmas.

Gostaria que, quando o dispositivo 192.168.0.10(em dmz) solicitasse a resolução de foo.example.info, enviasse de volta 192.168.0.20em vez da resposta da zona transferida.

Como substituir esta única entrada?

Eu tenho um domínio ( example.com) que está configurado para ter duas visualizações. host1.example.comestará 10.0.0.1em uma rede interna e 149.120.10.14(um IP público) quando consultado de fora.

Isso significa que um dispositivo conectado à Internet deve ter seu conjunto usual de DNSs usado normalmente (os que obtém do DHCP, digamos 8.8.8.8) e eles serão resolvidos host1.example.compara seu IP externo.

Quando conectado via VPN, este dispositivo deve, no entanto, receber do servidor OpenVPN um DNS específico para resolver example.com (e apenas example.com) .

Meu entendimento é que usando

push "dhcp-option DNS 10.10.10.100"

onde 10.10.10.100está o servidor DNS interno acessível por VPN substituiria os servidores DNS no dispositivo, perdendo os que já possuía.

Existe uma maneira de enviar um servidor de nomes DNS com a opção de usá-lo apenas para um domínio específico e manter os outros DNSs existentes (usados ​​para resolução de Internet/empresa)?

Eu tenho um dispositivo ao qual não consigo mais me conectar (ssh, salt, ...), não tenho acesso físico fácil - mas que ainda abre uma sessão OpenVPN no meu servidor. Para tentar recuperá-lo, gostaria de:

• no servidor forçar uma reconexão para este cliente
• quando o cliente se reconecta - envie um script que o cliente executaria (primeiro eu daria uma olhada no que está acontecendo por meio de um despejo dos logs e configurações e, em seguida, possivelmente recuperaria as configurações corretas)

Existem soluções para os scripts serem executados no cliente uma vez que ele se conecta, mas todos assumem que esta é a escolha do cliente (= a configuração está no lado do cliente). Estou procurando o contrário.

Posso ver que um problema de segurança é essa abordagem (o provedor de VPN pode assumir a máquina do cliente), mas talvez haja uma maneira que não seja óbvia na documentação?

É possível obter um TLD genérico , como .example. Uma pesquisa de DNS examplepassaria pelos servidores raiz, que encontrariam um registro de cola examplee encaminhariam a solicitação para o NS designado. Isso não é diferente de .comou outros.

Isso significa que posso fornecer endereços de e-mail como hello@examplee hospedar um site em example.

Como esses nomes simples são resolvidos em clientes (clientes para DNS, podem ser servidores ou máquinas reais de usuários finais)?

• um servidor Linux server.foo.comcom uma resolução típica anexaria a uma consulta tão simples o domínio em que está - supondo que a solicitação seja para um host em seu domínio. Solicitaria então a resolução de example.foo.com, o que não é o esperado

• Acredito que o mesmo aconteceria com um servidor Windows (?)

• no lado do usuário final, digitar, examplepor exemplo, o Chrome acionará uma pesquisa da palavra example, pois está faltando um endereço completo e pontilhado

Eu vejo linhas como

Feb 13 21:45:48 srv named[2355]: address not available resolving 'secure.gravatar.com/A/IN': 2a04:fa87:ffff::c6b5:7405#53
Feb 13 21:42:29 srv named[2355]: address not available resolving 'la1.akamaiedge.net/AAAA/IN': 2001:500:a8::e#53

/var/log/syslogapesar de rodar bindapenas no modo IPv4

srv # cat /etc/default/bind9
# run resolvconf?
RESOLVCONF=no

# startup options for the server
OPTIONS="-u bind -4"

Por que é tão?

Eu tenho um bind9servidor autoritativo para o meu domínio example.com. A resolução direta funciona, os PTRs também até certo ponto.

atualmente tenho

254.10.10   IN  PTR srv.

na minha zona PTR para 10.x, que resolve corretamente para

root@srv ~# dig -x 10.10.10.254
(...)
;; ANSWER SECTION:
254.10.10.10.in-addr.arpa. 604800 IN    PTR     srv.

Gostaria que a resolução fosse um FQDN e portanto substituído srv.por srv(removido o ponto) na configuração acima, levando a uma resolução de

root@srv ~# dig -x 10.10.10.254
(...)
;; ANSWER SECTION:
254.10.10.10.in-addr.arpa. 604800 IN    PTR     srv.10.in-addr.arpa.

Como posso informar bind9para resolver 10.10.10.254 em srv.example.comvez de srv.10.in-addr.arpa?

Nota: eu sei que poderia ter

254.10.10   IN  PTR srv.example.com.

na minha configuração. O que estou procurando é como definir o domínio anexado padrão.

docker inspectretorna todos os tipos de informações interessantes sobre uma imagem docker ou contêiner (ou outro objeto).

Onde essas informações são armazenadas? É possível editá-lo?

Tenho um container criado ( docker create) a partir de uma imagem que estava usando EXPOSE 22noDockerfile

Eu inicio via docker start <container name or ID>e acesso via ssh.

Agora preciso expor mais uma porta, de um serviço rodando neste container. Não consigo recriá-lo, ele precisa ter seus parâmetros de inicialização alterados para expor essa porta extra. Isso é possível?

Eu esperava que docker startisso permitisse os mesmos parâmetros de docker createou , docker runmas esse não é o caso.

Nota: sei que a filosofia do docker é criar containers efêmeros . É um fato da vida que eu tenho que lidar com este contêiner altamente customizado (em vez de recriá-lo)

Gostaria de encaminhar ( rsyslog 8.4.2-1) todas as mensagens syslog para uma porta em 127.0.0.1. Para fazer isso, adicionei um arquivo em /etc/rsyslog.d/expose-42000.conf:

*.* @127.0.0.1:42000

Depois de reiniciar o rsyslog (sem mensagens de erro nos logs), tentei ouvir as mensagens recebidas:

netcat -u 127.0.0.1 42000

Não houve saída, apesar de ter mensagens aparecendo no formato /var/log/syslog.

Para ter certeza de que o arquivo está realmente incluído, executei rsyslogd no modo de depuração e vejo que a inclusão acontece:

# rsyslogd -dn
(...)
8836.556859167:main thread    : requested to include config file '/etc/rsyslog.d/expose-42000.conf'
8836.556895084:main thread    : config parser: pushed file /etc/rsyslog.d/expose-42000.conf on top of stack
Next token is token PRIFILT ()
Shifting token PRIFILT ()
Entering state 14
Reading a token: Next token is token LEGACY_ACTION ()
Shifting token LEGACY_ACTION ()
Entering state 12
Reducing stack by rule 35 (line 168):
   $1 = token LEGACY_ACTION ()
8836.557893160:main thread    : tried selector action for builtin:omfile: -2001
8836.557908388:main thread    : tried selector action for builtin:ompipe: -2001
8836.557923233:main thread    : tried selector action for builtin-shell: -2001
8836.558022055:main thread    : tried selector action for builtin:omdiscard: -2001
8836.558038075:main thread    : tried selector action for builtin:omfwd: 0
8836.558052488:main thread    : Module builtin:omfwd processes this action.
8836.558136499:main thread    : template: 'RSYSLOG_TraditionalForwardFormat' assigned
8836.558160039:main thread    : action 1 queue: parameter dump:
8836.558174916:main thread    : action 1 queue: queue.filename '[NONE]'
8836.558273542:main thread    : action 1 queue: queue.size: 1000
8836.558288080:main thread    : action 1 queue: queue.dequeuebatchsize: 16
8836.558302414:main thread    : action 1 queue: queue.maxdiskspace: 0
8836.558368788:main thread    : action 1 queue: queue.highwatermark: -1
8836.558384865:main thread    : action 1 queue: queue.lowwatermark: -1
8836.558413762:main thread    : action 1 queue: queue.fulldelaymark: -1
8836.558442666:main thread    : action 1 queue: queue.lightdelaymark: -1
8836.558470770:main thread    : action 1 queue: queue.discardmark: 980
8836.558552633:main thread    : action 1 queue: queue.discardseverity: 8
8836.558594909:main thread    : action 1 queue: queue.checkpointinterval: 0
8836.558608920:main thread    : action 1 queue: queue.syncqueuefiles: 0
8836.558623042:main thread    : action 1 queue: queue.type: 3 [Direct]
8836.558691335:main thread    : action 1 queue: queue.workerthreads: 1
8836.558727077:main thread    : action 1 queue: queue.timeoutshutdown: 0
8836.558741599:main thread    : action 1 queue: queue.timeoutactioncompletion: 1000
8836.558827751:main thread    : action 1 queue: queue.timeoutenqueue: 50
8836.558855694:main thread    : action 1 queue: queue.timeoutworkerthreadshutdown: 60000
8836.558869846:main thread    : action 1 queue: queue.workerthreadminimummessages: -1
8836.558884102:main thread    : action 1 queue: queue.maxfilesize: 1048576
8836.558950182:main thread    : action 1 queue: queue.saveonshutdown: 1
8836.558983020:main thread    : action 1 queue: queue.dequeueslowdown: 0
8836.558997187:main thread    : action 1 queue: queue.dequeuetimebegin: 0
8836.559011113:main thread    : action 1 queue: queuedequeuetimend.: 25
8836.559025491:main thread    : Action 0xb97a40: queue 0xb99120 created
-> $$ = nterm s_act ()
Stack now 0 1 14
Entering state 22
Reducing stack by rule 32 (line 164):
   $1 = nterm s_act ()
-> $$ = nterm actlst ()
Stack now 0 1 14
Entering state 21
Reading a token: 8836.559386173:main thread    : config parser: reached end of file /etc/rsyslog.d/expose-42000.conf
8836.559390418:main thread    : config parser: resume parsing of file /etc/rsyslog.conf at line 51
(...)

Há algo que estou perdendo?

Ao configurar meu primeiro dockerambiente, criei uma rede específica:

root@srv /e/docker# docker network inspect docker
[
    {
        "Name": "docker",
        "Id": "7b20560b36032d36ffe6c0ebece6b4408355d207f4e203a2957b0434ee0afdc1",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "10.200.0.0/24"
                }
            ]
        },
        "Internal": false,
        "Containers": {},
        "Options": {},
        "Labels": {}
    }
]

Criei um container a partir de uma imagem para esta rede com um IP específico:

root@srv /e/docker# docker create --network docker --ip 10.200.0.2 --hostname dev -p 22:22 --name dev base
807f3892241d314d20837c4c749912097e1f34c62884401acd9a06e201cb5876

Em seguida, iniciei este contêiner e obtive:

root@srv /e/docker# docker start dev
Error response from daemon: driver failed programming external connectivity on endpoint dev (807f3892241d314d20837c4c749912097e1f34c62884401acd9a06e201cb5876): Error starting userland proxy: listen tcp 0.0.0.0:22: bind: address already in use
Error: failed to start containers: dev

Na verdade, ele tem um supervisordinício sshd -Dque, por padrão, se liga a todos os endereços IP disponíveis para esse host . Como seu IP é 10.200.0.2, eu esperava sshdvincular a ele 127.0.0.1e 10.200.0.2. Parece que esta porta é tomada por algo, mas o quê?

O host está em sshdexecução, mas isso não deve importar para o contêiner convidado, certo? (uma vez que vive em seu próprio mundo que conhece apenas os dois IPs acima)?

EDIT após comentários: Ou seja, gostaria sshdde vincular ao IP do container (aquele que vê = 10.200.0.2) e ter essa porta exposta fora do container, no mesmo IP. Ou, em termos práticos, gostaria de poder, a partir do host, ssh root@10.200.0.2chegar sshdao container.

Estou testando o docker como uma alternativa ao systemd-nspawn. Eu gostaria de usar uma ponte separada por contêiner.

Toda a documentação que vi é sobre usar docker0ou criar uma ponte alternativa - para ser usada por todos os contêineres (que compartilham a mesma ponte).

Isso é algo possível com o docker?

Gostaria de me conectar a um servidor OpenVPN de um host Ubuntu que também serve como firewall para outras conexões internas (dois APs e várias máquinas virtuais em execução nesse servidor).

Minha conexão trava em

Sat Nov 19 22:09:41 2016 UDPv4 link remote: [AF_INET]185.145.38.234:1194
Sat Nov 19 22:10:41 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Nov 19 22:10:41 2016 TLS Error: TLS handshake failed
Sat Nov 19 22:10:41 2016 SIGUSR1[soft,tls-error] received, process restarting
Sat Nov 19 22:10:41 2016 Restart pause, 2 second(s)

A tcpdumpda conexão mostra que

root@srv ~# tcpdump -i any host 185.145.38.234
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
22:35:38.933443 IP 192.168.0.10.41552 > 185.145.38.234.openvpn: UDP, length 42
22:35:40.116782 IP 192.168.0.10.41552 > 185.145.38.234.openvpn: UDP, length 42
22:35:44.849548 IP 192.168.0.10.41552 > 185.145.38.234.openvpn: UDP, length 42

Posso me conectar do mesmo prompt a qualquer serviço, todo o tráfego é permitido. Ao tentar conectar especificamente a essa porta, recebo

root@srv ~# nc -v -u 185.145.38.234 1194
Connection to 185.145.38.234 1194 port [udp/openvpn] succeeded!

Eu tenho o mesmo comportamento para tcpconexões OpenVPN (incluindo o bem-sucedido nc).

A primeira razão que posso pensar para tal comportamento (o cliente envia uma solicitação e não recebe nada de volta) é o roteamento ou firewall incorreto. Mas qualquer outra conexão do mesmo sistema (mesmo prompt, a curl www.google.compor exemplo) é bem-sucedida. Não há firewall desse local (o tráfego é totalmente aberto).

Outro motivo pode ser alguma filtragem upstream (do ISP). Este não é o caso, pois um cliente na LAN (que transita pela máquina acima e finalmente sai pela mesma interface) pode se conectar com sucesso.

O que poderia ser um outro motivo para esta falha de mensagem e conexão?