Gerald Schneider提出的问题 -server

Gerald Schneider

Asked: 2024-01-25 14:53:24 +0800 CST

Combinando OpenLDAP e Active Directory via meta backend OpenLDAP

6

Temos um aplicativo que costumava autenticar por meio de nossa instância Atlassian Crowd, mas após uma grande reescrita, essa fonte de autenticação não está mais disponível. Agora preciso de uma solução para autenticar usuários do nosso Active Directory e de um servidor OpenLDAP, que anteriormente era gerenciado pelo Crowd.

A opção mais promissora parece ser o meta backend OpenLDAP, e agora tenho uma configuração onde posso encontrar usuários de ambos os diretórios com ldapsearch, mas a autenticação só funciona para usuários AD. Encontrei algumas perguntas como esta , que foram muito úteis, mas no final das contas não funcionaram para mim.

           Application
               │
               ▼
         OpenLDAP (meta)
             │   │
             │   │
 OpenLDAP ◄──┘   └─►  Active Directory

Esta é minha configuração atual:

moduleload back_meta.la
moduleload back_ldap.la
moduleload rwm

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/msuser.schema

database meta

suffix "dc=openldap,dc=Example,dc=com"
uri "ldap://openldap.example.com/dc=openldap,dc=Example,dc=com"
map objectclass user inetOrgPerson
map attribute sAMAccountName uid
#map attribute unicodePwd userPassword
map attribute objectGUID entryUUID
map objectclass group groupOfUniqueNames
map attribute member uniqueMember
protocol-version 3
#rebind-as-user yes
idassert-authzFrom "dn.regex:.*"

suffix "DC=ad,DC=Example,DC=com"
uri "ldap://dc01.ad.example.com/DC=ad,DC=Example,DC=com"
rebind-as-user yes
chase-referrals no
readonly yes
protocol-version 3
idassert-bind
  bindmethod=simple
  binddn="CN=username,OU=Service-Accounts,DC=ad,DC=Example,DC=com"
  credentials="PASSWORD"
  flags=override
  mode=none
norefs yes
sizelimit 999
idassert-authzFrom "dn.regex:.*"

suffix "dc=Example,dc=com"
rootdn "cn=admin,dc=Example,dc=com"
rootpw PASSWORD

Parece que o único problema que resta é o campo de senha. De acordo com a documentação da MS, ambos unicodePwdexistem userPasswordno AD, mas nenhum deles funciona para o servidor OpenLDAP (que usa userPassword). Não consegui descobrir como as senhas são hash no AD, as contas armazenadas no OpenLDAP são hash com MD5 ou SSHA, dependendo da idade da senha, eu acho.

Tentei rebind-as-userligar e desligar o servidor OpenLDAP, tentei vincular com um nome de usuário em vez de anônimo, não tenho mais ideias.

O que está faltando para poder autenticar nos dois diretórios?

Gerald Schneider

Asked: 2023-09-19 21:30:39 +0800 CST

Posso liberar GRES alocado obsoleto em um nó Slurm?

6

Existe alguma maneira de limpar o GRES alocado obsoleto no Slurm?

Eu tenho um nó onde 4 GPUs estão alocadas enquanto nenhum trabalho está em execução no nó. A reinicialização do nó não libera as GPUs.

user@control1:~$ scontrol show node node2
NodeName=node2 Arch=x86_64 CoresPerSocket=64
   CPUAlloc=0 CPUTot=256 CPULoad=0.05
   AvailableFeatures=(null)
   ActiveFeatures=(null)
   Gres=gpu:tesla:8
   NodeAddr=node2 NodeHostName=node2 Version=21.08.5
   OS=Linux 5.15.0-83-generic #92-Ubuntu SMP Mon Aug 14 09:30:42 UTC 2023
   RealMemory=1025596 AllocMem=0 FreeMem=1025887 Sockets=2 Boards=1
   State=IDLE ThreadsPerCore=2 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A
   Partitions=DEFAULT
   BootTime=2023-09-19T12:58:23 SlurmdStartTime=2023-09-19T12:59:06
   LastBusyTime=2023-09-19T12:59:07
   CfgTRES=cpu=256,mem=1025596M,billing=256,gres/gpu=8,gres/gpu:tesla=8
   AllocTRES=gres/gpu=4
   CapWatts=n/a
   CurrentWatts=0 AveWatts=0
   ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s

user@control1:~$ squeue -w node2 --state=all
   JOBID     NAME     USER    STATE         TIME        QOS PRIORITY   TIME_LIMIT NODELIST(REASON)

Gerald Schneider

Asked: 2020-09-24 02:04:41 +0800 CST

Como posso encaminhar solicitações do meu servidor web?

9

Esta é uma pergunta canônica sobre proxies reversos, como eles funcionam e como são configurados.

Como posso atender solicitações de um serviço em uma porta diferente ou de um servidor diferente com o mesmo servidor da Web e distingui-lo por meio da URL?

Gerald Schneider

Asked: 2019-05-10 11:49:46 +0800 CST

grep excluir padrão de várias linhas

0

A pesquisa de padrões de várias linhas em arquivos com grep é trivial . Invertendo esse padrão nem tanto.

Background: Eu quero criar arquivos de variáveis limpos sem senhas para que eu possa enviá-los para um repositório.

Exemplo de arquivo de variável contendo uma senha criptografada:

ansible_user: rick
ansible_become_password: !vault |
        $ANSIBLE_VAULT;1.1;AES256
        35623732646263636163383738353230626565383533626261313564383832643334363632383134
        3833316539376436333462303564636236646662376535300a356631346166626632333365353465
        30343138313363666434343938393464343861666234633434383037393230633333333364383835
        3962383339373731610a316362326239386539633638646331636633333330633231383730323634
        33653332353239353662366631373037653135303163663365633532643535663933
never: 'gonna,give,you,up'

Resultado pretendido:

ansible_user: rick
never: 'gonna,give,you,up'

Eu posso facilmente combinar as linhas que contêm as senhas com este comando:

grep -Pz '.+\: !vault \|(\n\s+.+){2,}' host_vars/host.yml

O problema: O parâmetro -v, que normalmente inverte o resultado, não funciona com-P

Como posso criar uma cópia dos arquivos variáveis sem as linhas de senha?

Gerald Schneider

Asked: 2019-03-29 02:09:11 +0800 CST

Verificação de agregação do Zabbix Expressão de função incorreta

0

Estou tentando obter um valor agregado sobre a latência de todos os datastores de todos os hosts ESXi.

Eu tentei essas variantes da grpmaxfunção de agregação :

grpmax["Hypervisors","vmware.hv.datastore.read[{$URL},{HOST.HOST},,latency]",avg,600]
grpmax["Hypervisors","vmware.hv.datastore.read[,,,latency]",avg,600]

Mas para ambos estou recebendo a mensagem de erro:

Expressão de função incorreta: grpmax["Hypervisors","vmware.hv.datastore.read[,,,latency]",avg,600]

Como devo inserir as chaves para que o zabbix as encontre na agregação?

As chaves dos itens que quero agregar são assim:

vmware.hv.datastore.read[{$URL},{HOST.HOST},datastore1,latency]
vmware.hv.datastore.read[{$URL},{HOST.HOST},datastore2,latency]
vmware.hv.datastore.read[{$URL},{HOST.HOST},datastore3,latency]

Gerald Schneider

Asked: 2019-02-13 00:09:20 +0800 CST

keepalived não detecta perda de IP virtual

9

Estou usando keepalived para alternar um IP flutuante entre duas VMs.

/etc/keepalived/keepalived.confna VM 1:

vrrp_instance VI_1 {
    state MASTER
    interface ens160
    virtual_router_id 101
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret
    }
    virtual_ipaddress {
        1.2.3.4
    }
}

/etc/keepalived/keepalived.confna VM 2:

vrrp_instance VI_1 {
    state MASTER
    interface ens160
    virtual_router_id 101
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret
    }
    virtual_ipaddress {
        1.2.3.4
    }
}

Isso basicamente funciona bem, com uma exceção: toda vez que o systemd é atualizado (está executando o Ubuntu 18.04), ele recarrega seu componente de rede, resultando na queda do IP flutuante porque não está configurado no sistema. Como ambas as instâncias keepalived ainda podem fazer ping uma na outra, nenhuma delas vê nada de errado e nenhuma delas reage a isso, resultando na permanência do IP flutuante.

Descobri que você pode verificar o IP com um script simples como este:

vrrp_script chk_proxyip {
    script "/sbin/ip addr |/bin/grep 1.2.3.4"
}

vrrp_instance VI_1 {
    # [...]
    track_script {
        chk_proxyip
    }
}

Mas não tenho certeza se esta é uma abordagem de trabalho.

Se eu entendi corretamente, aconteceria o seguinte, se eu configurar este script na VM1:

VM1 perde o IP devido a uma reinicialização do systemd
keepalived na VM1 detecta a perda do IP
keepalived muda para o FAULTestado e para de transmitir pacotes vrrp
keepalived na VM2 detecta a perda de keepalived na VM1 e coloca o IP flutuante

Neste ponto, o IP está funcionando novamente na VM2, mas a VM1 permaneceria nesse estado porque o IP nunca mais aparece na VM1. Se a VM2 ficar inativa (por qualquer motivo), a VM1 não a assumirá, porque ainda está em FAULTestado.

Como posso garantir que o IP flutuante esteja sempre ativo em uma das VMs?

Testes adicionais:

Eu tentei pingar o IP flutuante em vez de verificar se ele está ativo em um host específico em um check_script:

vrrp_script chk_proxyip {
    script "/bin/ping -c 1 -w 1 1.2.3.4"
    interval 2
}

A configuração desse script no nó 2 resultou no seguinte:

removeu o IP no nó 1 para teste
o nó 2 detectou a perda de IP e mudou de BACKUPparaFAULT
o nó 1 ignorou a mudança de estado e permaneceuMASTER

O resultado: o IP ficou inativo.

A configuração do script no nó 1 resultou no seguinte:

removeu o IP no nó 1
o nó 1 detectou a perda de IP e mudou de MASTERparaFAULT
o nó 2 detectou a mudança de estado no nó 1 e mudou de BACKUPpara MASTER, configurando o IP flutuante no nó 2

Bem, e então...

Feb 13 10:11:26 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:27 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:29 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:32 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:33 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:36 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:38 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:39 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
Feb 13 10:11:41 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering BACKUP STATE
Feb 13 10:11:44 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 13 10:11:45 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 13 10:11:47 node2 Keepalived_vrrp[3486]: VRRP_Instance(VI_1) Received advert with higher priority 150, ours 100
...

Eu tive que reiniciar o keepalived no node1 para parar o jogo de pingue-pongue entre os nós.

Gerald Schneider

Asked: 2019-02-12 02:04:30 +0800 CST

Particionamento automático pré-seed

5

Estou usando as seguintes partmanconfigurações para instalações automatizadas de VMs há alguns anos:

d-i partman-auto/disk string /dev/sda
d-i partman-auto/method string regular
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman/alignment string "optimal"
d-i partman-auto/expert_recipe string                         \
      boot-root ::                                            \
              64 512 300% linux-swap                          \
                      $primary{ }                             \
                      method{ swap } format{ }                \
              .                                               \
              500 10000 1000000000 ext4                       \
                      $primary{ } $bootable{ }                \
                      method{ format } format{ }              \
                      use_filesystem{ } filesystem{ ext4 }    \
                      mountpoint{ / }                         \
              .
d-i partman/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true

Isso cria uma pequena partição de troca no início e usa o restante do disco para a partição raiz. Isso funciona bem e permite fácil extensão de partição quando preciso aumentar o tamanho do disco virtual.

Agora estou tentando adaptar esta receita para instalar vários servidores bare metal idênticos. Para fazer isso, apenas troquei as partições e configurei os tamanhos para valores mais razoáveis para uma máquina com 256 GB de RAM e 460 GB de disco do sistema (SSDs em um RAID1 de hardware, mas isso não deve importar):

  boot-root ::                                            \
          32768 65536 1000000000 ext4                     \
                  $primary{ } $bootable{ }                \
                  method{ format } format{ }              \
                  use_filesystem{ } filesystem{ ext4 }    \
                  mountpoint{ / }                         \
          .                                               \
          16384 16384 65536 linux-swap                    \
                  $primary{ }                             \
                  method{ swap } format{ }                \
          .

As demais partman*diretivas são idênticas.

Tanto quanto eu entendo a documentação (e posts adicionais como este ), isso deve criar uma grande partição raiz que abrange quase todo o disco, com uma partição swap entre 16 e 64 GB no final.

Bem, não. Ele cria uma partição de 450 MB, seguida por uma partição de troca de 460 GB.

Quando instalo a mesma máquina com o preseed para VMs, as partições são criadas corretamente conforme definido no arquivo preseed:

Então, o que estou fazendo de errado com a receita da máquina bare metal?

Se for importante, a iso de instalação é baseada na iso do servidor Ubuntu 16.04.5.

Saída de fdisk /dev/sdaeparted /dev/sda print :

Mais algumas variantes que tentei:

# this belongs to tha last block, as suggested by @Peter
#d-i partman-basicfilesystems/choose_label string gpt
#d-i partman-basicfilesystems/default_label string gpt
#d-i partman-partitioning/choose_label string gpt
#d-i partman-partitioning/default_label string gpt
#d-i partman/choose_label string gpt
#d-i partman/default_label string gpt

d-i partman-auto/expert_recipe string                         \
      boot-root ::                                            \
##########################
              65536 1 -1 ext4                             \
                      $primary{ } $bootable{ }                \
                      method{ format } format{ }              \
                      use_filesystem{ } filesystem{ ext4 }    \
                      mountpoint{ / }                         \
              .                                               \
              65536 65536 65536 linux-swap                    \
                      $primary{ }                             \
                      method{ swap } format{ }                \
              .                                               
##########################
#              1 1 -1 ext4                             \
#                      $primary{ } $bootable{ }                \
#                      method{ format } format{ }              \
#                      use_filesystem{ } filesystem{ ext4 }    \
#                      mountpoint{ / }                         \
#              .                                               \
#              65536 65536 65536 linux-swap                    \
#                      $primary{ }                             \
#                      method{ swap } format{ }                \
#              .                                               
##########################
#              32768 50 5242880 ext4                             \
#                      $primary{ } $bootable{ }                \
#                      method{ format } format{ }              \
#                      use_filesystem{ } filesystem{ ext4 }    \
#                      mountpoint{ / }                         \
#              .                                               \
#              16384 100 65536 linux-swap                    \
#                      $primary{ }                             \
#                      method{ swap } format{ }                \
#              .                                               
##########################
# use along with the annoted partman-* directives above
#              538 538 1075 free                           \
#                      $iflabel{ gpt }                     \
#                      $reusemethod{ }                     \
#                      method{ efi }                       \
#                            format{ }                     \
#              .                                           \
#              1 1 -1 ext4                                 \
#                  $primary{ } $bootable{ }                \
#                  method{ format } format{ }              \
#                  use_filesystem{ } filesystem{ ext4 }    \
#                  mountpoint{ / }                         \
#              .                                           \
#              65536 65536 65536 linux-swap                \
#                  $primary{ }                             \
#                  method{ swap } format { }               \              .                         
#              .

Não faz diferença, a partição raiz resultante sempre tem apenas 453 MB.

Gerald Schneider

Asked: 2018-12-14 03:27:13 +0800 CST

A implantação do Kolla OpenStack falha com "haproxy: aguardando o IP virtual aparecer"

1

Estou tentando implantar o OpenStack Queens com kolla-ansible (7.0.0) em hosts Ubuntu, seguindo o guia oficial .

Depois de bem-sucedido bootstrap-serverse prechecko deploycomando falhar:

RUNNING HANDLER [haproxy : Waiting for virtual IP to appear] **********************************************************  
fatal: [testcloudcontrol01]: FAILED! => {"changed": false, "elapsed": 300, "msg": "Timeout when waiting for 10.52.41.98:3306"}  
fatal: [testcloudcontrol02]: FAILED! => {"changed": false, "elapsed": 300, "msg": "Timeout when waiting for 10.52.41.98:3306"}

A razão para a verificação falhar é que o kolla_internal_vip_addressnão aparece.

globals.yml

config_strategy: "COPY_ALWAYS"
kolla_base_distro: "ubuntu"
kolla_install_type: "binary"
openstack_release: "queens"
kolla_internal_vip_address: "10.52.41.98"
kolla_internal_fqdn: "testcloudapi.example.com"
kolla_external_vip_address: "{{ kolla_internal_vip_address }}"
kolla_external_fqdn: "{{ kolla_internal_fqdn }}"
network_interface: "ens160"
api_interface: "ens160"
storage_interface: "ens161"
keepalived_virtual_router_id: "148"

Atualmente estou fixo em rainhas porque quero replicar nosso ambiente de produção para testes.

A saída de ip addrum dos nós em que o haproxy deve implantar:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:a1:6a:2c brd ff:ff:ff:ff:ff:ff
    inet 10.52.41.100/24 brd 10.52.41.255 scope global ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fea1:6a2c/64 scope link
       valid_lft forever preferred_lft forever
3: ens161: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:a1:7d:07 brd ff:ff:ff:ff:ff:ff
    inet 10.52.42.100/24 brd 10.52.42.255 scope global ens161
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fea1:7d07/64 scope link
       valid_lft forever preferred_lft forever
4: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:a1:23:6e brd ff:ff:ff:ff:ff:ff
    inet 10.52.40.100/24 brd 10.52.40.255 scope global ens224
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fea1:236e/64 scope link
       valid_lft forever preferred_lft forever
5: ens256: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:a1:20:12 brd ff:ff:ff:ff:ff:ff
    inet 10.52.44.100/24 brd 10.52.44.255 scope global ens256
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fea1:2012/64 scope link
       valid_lft forever preferred_lft forever
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:b0:8a:93:e7 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever

Os nós são máquinas virtuais VMware com placas VMXNet3.

Saída de docker logs keepalived:

+ sudo -E kolla_set_configs
INFO:__main__:Loading config file at /var/lib/kolla/config_files/config.json
INFO:__main__:Validating config file
INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
INFO:__main__:Copying service configuration files
INFO:__main__:Deleting /etc/keepalived/keepalived.conf
INFO:__main__:Copying /var/lib/kolla/config_files/keepalived.conf to /etc/keepalived/keepalived.conf
INFO:__main__:Setting permission for /etc/keepalived/keepalived.conf
INFO:__main__:Writing out command to execute
++ cat /run_command
+ CMD='/usr/sbin/keepalived -nld -p /run/keepalived.pid'
+ ARGS=
+ [[ ! -n '' ]]
+ . kolla_extend_start
++ modprobe ip_vs
++ '[' -f /run/keepalived.pid ']'
+ echo 'Running command: '\''/usr/sbin/keepalived -nld -p /run/keepalived.pid'\'''
Running command: '/usr/sbin/keepalived -nld -p /run/keepalived.pid'
+ exec /usr/sbin/keepalived -nld -p /run/keepalived.pid
Thu Dec 13 12:10:26 2018: Starting Keepalived v1.3.9 (10/21,2017)
Thu Dec 13 12:10:26 2018: Opening file '/etc/keepalived/keepalived.conf'.
Thu Dec 13 12:10:26 2018: Starting Healthcheck child process, pid=11
Thu Dec 13 12:10:26 2018: Opening file '/etc/keepalived/keepalived.conf'.
Thu Dec 13 12:10:26 2018: Starting VRRP child process, pid=12
Thu Dec 13 12:10:26 2018: ------< Global definitions >------
Thu Dec 13 12:10:26 2018:  Router ID = testcloudcontrol01.example.com
Thu Dec 13 12:10:26 2018:  Default interface = eth0
Thu Dec 13 12:10:26 2018:  LVS flush = false
Thu Dec 13 12:10:26 2018:  VRRP IPv4 mcast group = 224.0.0.18
Thu Dec 13 12:10:26 2018:  VRRP IPv6 mcast group = ff02::12
Thu Dec 13 12:10:26 2018:  Gratuitous ARP delay = 5
Thu Dec 13 12:10:26 2018:  Gratuitous ARP repeat = 5
Thu Dec 13 12:10:26 2018:  Gratuitous ARP refresh timer = 0
Thu Dec 13 12:10:26 2018:  Gratuitous ARP refresh repeat = 1
Thu Dec 13 12:10:26 2018:  Gratuitous ARP lower priority delay = 4294
Thu Dec 13 12:10:26 2018:  Gratuitous ARP lower priority repeat = -1
Thu Dec 13 12:10:26 2018:  Send advert after receive lower priority advert = true
Thu Dec 13 12:10:26 2018:  Send advert after receive higher priority advert = false
Thu Dec 13 12:10:26 2018:  Gratuitous ARP interval = 0
Thu Dec 13 12:10:26 2018:  Gratuitous NA interval = 0
Thu Dec 13 12:10:26 2018:  VRRP default protocol version = 2
Thu Dec 13 12:10:26 2018:  Iptables input chain = INPUT
Thu Dec 13 12:10:26 2018:  Using ipsets = true
Thu Dec 13 12:10:26 2018:  ipset IPv4 address set = keepalived
Thu Dec 13 12:10:26 2018:  ipset IPv6 address set = keepalived6
Thu Dec 13 12:10:26 2018:  ipset IPv6 address,iface set = keepalived_if6
Thu Dec 13 12:10:26 2018:  VRRP check unicast_src = false
Thu Dec 13 12:10:26 2018:  VRRP skip check advert addresses = false
Thu Dec 13 12:10:26 2018:  VRRP strict mode = false
Thu Dec 13 12:10:26 2018:  VRRP process priority = 0
Thu Dec 13 12:10:26 2018:  VRRP don't swap = false
Thu Dec 13 12:10:26 2018:  Checker process priority = 0
Thu Dec 13 12:10:26 2018:  Checker don't swap = false
Thu Dec 13 12:10:26 2018:  SNMP keepalived disabled
Thu Dec 13 12:10:26 2018:  SNMP checker disabled
Thu Dec 13 12:10:26 2018:  SNMP RFCv2 disabled
Thu Dec 13 12:10:26 2018:  SNMP RFCv3 disabled
Thu Dec 13 12:10:26 2018:  SNMP traps disabled
Thu Dec 13 12:10:26 2018:  SNMP socket = default (unix:/var/agentx/master)
Thu Dec 13 12:10:26 2018:  Network namespace = (default)
Thu Dec 13 12:10:26 2018:  DBus disabled
Thu Dec 13 12:10:26 2018:  DBus service name = (null)
Thu Dec 13 12:10:26 2018:  Script security disabled
Thu Dec 13 12:10:26 2018:  Default script uid:gid 0:0
Thu Dec 13 12:10:26 2018: Registering Kernel netlink reflector
Thu Dec 13 12:10:26 2018: Registering Kernel netlink command channel
Thu Dec 13 12:10:26 2018: Registering gratuitous ARP shared channel
Thu Dec 13 12:10:26 2018: Opening file '/etc/keepalived/keepalived.conf'.
Thu Dec 13 12:10:26 2018: WARNING - default user 'keepalived_script' for script execution does not exist - please create.
Thu Dec 13 12:10:26 2018: Truncating auth_pass to 8 characters
Thu Dec 13 12:10:26 2018: SECURITY VIOLATION - scripts are being executed but script_security not enabled.
Thu Dec 13 12:10:26 2018: ------< Global definitions >------
Thu Dec 13 12:10:26 2018:  Router ID = testcloudcontrol01.example.com
Thu Dec 13 12:10:26 2018:  Default interface = eth0
Thu Dec 13 12:10:26 2018:  LVS flush = false
Thu Dec 13 12:10:26 2018:  VRRP IPv4 mcast group = 224.0.0.18
Thu Dec 13 12:10:26 2018:  VRRP IPv6 mcast group = ff02::12
Thu Dec 13 12:10:26 2018:  Gratuitous ARP delay = 5
Thu Dec 13 12:10:26 2018:  Gratuitous ARP repeat = 5
Thu Dec 13 12:10:26 2018:  Gratuitous ARP refresh timer = 0
Thu Dec 13 12:10:26 2018:  Gratuitous ARP refresh repeat = 1
Thu Dec 13 12:10:26 2018:  Gratuitous ARP lower priority delay = 5
Thu Dec 13 12:10:26 2018:  Gratuitous ARP lower priority repeat = 5
Thu Dec 13 12:10:26 2018:  Send advert after receive lower priority advert = true
Thu Dec 13 12:10:26 2018:  Send advert after receive higher priority advert = false
Thu Dec 13 12:10:26 2018:  Gratuitous ARP interval = 0
Thu Dec 13 12:10:26 2018:  Gratuitous NA interval = 0
Thu Dec 13 12:10:26 2018:  VRRP default protocol version = 2
Thu Dec 13 12:10:26 2018:  Iptables input chain = INPUT
Thu Dec 13 12:10:26 2018:  Using ipsets = false
Thu Dec 13 12:10:26 2018:  ipset IPv4 address set = keepalived
Thu Dec 13 12:10:26 2018:  ipset IPv6 address set = keepalived6
Thu Dec 13 12:10:26 2018:  ipset IPv6 address,iface set = keepalived_if6
Thu Dec 13 12:10:26 2018:  VRRP check unicast_src = false
Thu Dec 13 12:10:26 2018:  VRRP skip check advert addresses = false
Thu Dec 13 12:10:26 2018:  VRRP strict mode = false
Thu Dec 13 12:10:26 2018:  VRRP process priority = 0
Thu Dec 13 12:10:26 2018:  VRRP don't swap = false
Thu Dec 13 12:10:26 2018:  Checker process priority = 0
Thu Dec 13 12:10:26 2018:  Checker don't swap = false
Thu Dec 13 12:10:26 2018:  SNMP keepalived disabled
Thu Dec 13 12:10:26 2018:  SNMP checker disabled
Thu Dec 13 12:10:26 2018:  SNMP RFCv2 disabled
Thu Dec 13 12:10:26 2018:  SNMP RFCv3 disabled
Thu Dec 13 12:10:26 2018:  SNMP traps disabled
Thu Dec 13 12:10:26 2018:  SNMP socket = default (unix:/var/agentx/master)
Thu Dec 13 12:10:26 2018:  Network namespace = (default)
Thu Dec 13 12:10:26 2018:  DBus disabled
Thu Dec 13 12:10:26 2018:  DBus service name = (null)
Thu Dec 13 12:10:26 2018:  Script security disabled
Thu Dec 13 12:10:26 2018:  Default script uid:gid 0:0
Thu Dec 13 12:10:26 2018: ------< VRRP Topology >------
Thu Dec 13 12:10:26 2018:  VRRP Instance = kolla_internal_vip_148
Thu Dec 13 12:10:26 2018:    Using VRRPv2
Thu Dec 13 12:10:26 2018:    Want State = BACKUP
Thu Dec 13 12:10:26 2018:    Running on device = ens160
Thu Dec 13 12:10:26 2018:    Skip checking advert IP addresses = no
Thu Dec 13 12:10:26 2018:    Enforcing strict VRRP compliance = no
Thu Dec 13 12:10:26 2018:    Using src_ip = 10.52.41.100
Thu Dec 13 12:10:26 2018:    Gratuitous ARP delay = 5
Thu Dec 13 12:10:26 2018:    Gratuitous ARP repeat = 5
Thu Dec 13 12:10:26 2018:    Gratuitous ARP refresh timer = 0
Thu Dec 13 12:10:26 2018:    Gratuitous ARP refresh repeat = 1
Thu Dec 13 12:10:26 2018:    Gratuitous ARP lower priority delay = 5
Thu Dec 13 12:10:26 2018:    Gratuitous ARP lower priority repeat = 5
Thu Dec 13 12:10:26 2018:    Send advert after receive lower priority advert = true
Thu Dec 13 12:10:26 2018:    Send advert after receive higher priority advert = false
Thu Dec 13 12:10:26 2018:    Virtual Router ID = 148
Thu Dec 13 12:10:26 2018:    Priority = 1
Thu Dec 13 12:10:26 2018:    Advert interval = 1 sec
Thu Dec 13 12:10:26 2018:    Accept enabled
Thu Dec 13 12:10:26 2018:    Preempt disabled
Thu Dec 13 12:10:26 2018:    Promote_secondaries disabled
Thu Dec 13 12:10:26 2018:    Authentication type = SIMPLE_PASSWORD
Thu Dec 13 12:10:26 2018:    Password = 0RXbQYFF
Thu Dec 13 12:10:26 2018:    Tracked scripts = 1
Thu Dec 13 12:10:26 2018:      check_alive weight 0
Thu Dec 13 12:10:26 2018:    Virtual IP = 1
Thu Dec 13 12:10:26 2018:      10.52.41.98/32 dev ens160 scope global
Thu Dec 13 12:10:26 2018: ------< VRRP Scripts >------
Thu Dec 13 12:10:26 2018:  VRRP Script = check_alive
Thu Dec 13 12:10:26 2018:    Command = /check_alive.sh
Thu Dec 13 12:10:26 2018:    Interval = 2 sec
Thu Dec 13 12:10:26 2018:    Timeout = 0 sec
Thu Dec 13 12:10:26 2018:    Weight = 0
Thu Dec 13 12:10:26 2018:    Rise = 10
Thu Dec 13 12:10:26 2018:    Fall = 2
Thu Dec 13 12:10:26 2018:    Insecure = no
Thu Dec 13 12:10:26 2018:    Status = INIT
Thu Dec 13 12:10:26 2018:    Script uid:gid = 0:0
Thu Dec 13 12:10:26 2018: ------< NIC >------
Thu Dec 13 12:10:26 2018:  Name = lo
Thu Dec 13 12:10:26 2018:  index = 1
Thu Dec 13 12:10:26 2018:  IPv4 address = 127.0.0.1
Thu Dec 13 12:10:26 2018:  IPv6 address = ::
Thu Dec 13 12:10:26 2018:  is UP
Thu Dec 13 12:10:26 2018:  is RUNNING
Thu Dec 13 12:10:26 2018:  MTU = 65536
Thu Dec 13 12:10:26 2018:  HW Type = LOOPBACK
Thu Dec 13 12:10:26 2018: ------< NIC >------
Thu Dec 13 12:10:26 2018:  Name = ens160
Thu Dec 13 12:10:26 2018:  index = 2
Thu Dec 13 12:10:26 2018:  IPv4 address = 10.52.41.100
Thu Dec 13 12:10:26 2018:  IPv6 address = fe80::250:56ff:fea1:6a2c
Thu Dec 13 12:10:26 2018:  MAC = 00:50:56:a1:6a:2c
Thu Dec 13 12:10:26 2018:  is UP
Thu Dec 13 12:10:26 2018:  is RUNNING
Thu Dec 13 12:10:26 2018:  MTU = 1500
Thu Dec 13 12:10:26 2018:  HW Type = ETHERNET
Thu Dec 13 12:10:26 2018: ------< NIC >------
Thu Dec 13 12:10:26 2018:  Name = ens161
Thu Dec 13 12:10:26 2018:  index = 3
Thu Dec 13 12:10:26 2018:  IPv4 address = 10.52.42.100
Thu Dec 13 12:10:26 2018:  IPv6 address = fe80::250:56ff:fea1:7d07
Thu Dec 13 12:10:26 2018:  MAC = 00:50:56:a1:7d:07
Thu Dec 13 12:10:26 2018:  is UP
Thu Dec 13 12:10:26 2018:  is RUNNING
Thu Dec 13 12:10:26 2018:  MTU = 1500
Thu Dec 13 12:10:26 2018:  HW Type = ETHERNET
Thu Dec 13 12:10:26 2018: ------< NIC >------
Thu Dec 13 12:10:26 2018:  Name = ens224
Thu Dec 13 12:10:26 2018:  index = 4
Thu Dec 13 12:10:26 2018:  IPv4 address = 10.52.40.100
Thu Dec 13 12:10:26 2018:  IPv6 address = fe80::250:56ff:fea1:236e
Thu Dec 13 12:10:26 2018:  MAC = 00:50:56:a1:23:6e
Thu Dec 13 12:10:26 2018:  is UP
Thu Dec 13 12:10:26 2018:  is RUNNING
Thu Dec 13 12:10:26 2018:  MTU = 1500
Thu Dec 13 12:10:26 2018:  HW Type = ETHERNET
Thu Dec 13 12:10:26 2018: ------< NIC >------
Thu Dec 13 12:10:26 2018:  Name = ens256
Thu Dec 13 12:10:26 2018:  index = 5
Thu Dec 13 12:10:26 2018:  IPv4 address = 10.52.44.100
Thu Dec 13 12:10:26 2018:  IPv6 address = fe80::250:56ff:fea1:2012
Thu Dec 13 12:10:26 2018:  MAC = 00:50:56:a1:20:12
Thu Dec 13 12:10:26 2018:  is UP
Thu Dec 13 12:10:26 2018:  is RUNNING
Thu Dec 13 12:10:26 2018:  MTU = 1500
Thu Dec 13 12:10:26 2018:  HW Type = ETHERNET
Thu Dec 13 12:10:26 2018: ------< NIC >------
Thu Dec 13 12:10:26 2018:  Name = docker0
Thu Dec 13 12:10:26 2018:  index = 6
Thu Dec 13 12:10:26 2018:  IPv4 address = 172.17.0.1
Thu Dec 13 12:10:26 2018:  IPv6 address = ::
Thu Dec 13 12:10:26 2018:  MAC = 02:42:b0:8a:93:e7
Thu Dec 13 12:10:26 2018:  is UP
Thu Dec 13 12:10:26 2018:  MTU = 1500
Thu Dec 13 12:10:26 2018:  HW Type = ETHERNET
Thu Dec 13 12:10:26 2018: Using LinkWatch kernel netlink reflector...
Thu Dec 13 12:10:26 2018: VRRP_Instance(kolla_internal_vip_148) Entering BACKUP STATE
Thu Dec 13 12:10:26 2018: /check_alive.sh exited with status 1
Thu Dec 13 12:10:28 2018: /check_alive.sh exited with status 1
Thu Dec 13 12:10:30 2018: VRRP_Instance(kolla_internal_vip_148) Now in FAULT state
Thu Dec 13 12:10:30 2018: /check_alive.sh exited with status 1
Thu Dec 13 12:10:32 2018: /check_alive.sh exited with status 1
[message repeats until I stop the container]

É isso, ambas as instâncias keepalived ficam no estado FAULT, o endereço IP não é ativado em nenhuma das VMs.

Passei por essa pergunta e a resposta , mesmo não tendo as mensagens de erro nos arquivos de log:

keepalived_virtual_router_id foi alterado e é único
Eu corri kolla-genpwdnovamente. Eu confirmei que keepalived_passwordestá definido em/etc/kolla/passwords.yml
kolla_internal_vip_addressé acessível a partir de network_interface. O IP principal dessa interface está na mesma rede. Posso definir manualmente o endereço IP adicional e funciona.
kolla-ansible precheckspassa
selinux não está ativo no Ubuntu

No lado do hipervisor, tentei habilitar Promiscuous modeo grupo de portas dessa interface. Isso não fez diferença.

Gerald Schneider

Asked: 2018-05-15 22:41:32 +0800 CST

Registrar variável ansible em várias tarefas

9

Estou usando as seguintes tarefas em um script ansible que instala atualizações em vários servidores. Estas tarefas são para máquinas CentOS:

- name: Check for outstanding reboot
  shell: needs-restarting > /dev/null || echo Reboot required
  when: ansible_distribution_major_version|int < 7
  register: result
- name: Check for outstanding reboot
  shell: needs-restarting -r > /dev/null || echo Reboot required
  when: ansible_distribution_major_version|int >= 7
  register: result
- name: Report reboot
  debug: msg="{{ result.stdout_lines }}"

O resultado:

TASK [Check for outstanding reboot] ***********************************************************************************
skipping: [host1]
skipping: [host2]
skipping: [host5]
changed: [host3]
changed: [host4]

TASK [Check for outstanding reboot] ***********************************************************************************
skipping: [host3]
skipping: [host4]
changed: [host2]
changed: [host1]
changed: [host5]

TASK [Report reboot] **************************************************************************************************
fatal: [host3]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'stdout_lines'\n\nThe error appears to have been in '/path/to/updates.yml': line 52, column 5, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n    register: result\n  - name: Report reboot\n    ^ here\n\nexception type: <class 'ansible.errors.AnsibleUndefinedVariable'>\nexception: 'dict object' has no attribute 'stdout_lines'"}
ok: [host1] => {
    "msg": [
        "Reboot required"
    ]
}
fatal: [host4]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'stdout_lines'\n\nThe error appears to have been in '/path/to/updates.yml': line 52, column 5, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n    register: result\n  - name: Report reboot\n    ^ here\n\nexception type: <class 'ansible.errors.AnsibleUndefinedVariable'>\nexception: 'dict object' has no attribute 'stdout_lines'"}
ok: [host2] => {
    "msg": [
        "Reboot required"
    ]
}
ok: [host5] => {
    "msg": [
        "Reboot required"
    ]
}
        to retry, use: --limit @/path/to/updates.retry

Como você pode ver, ambas as tarefas de verificação armazenam o resultado em uma variável chamada "resultado", mas apenas as variáveis para os hosts na segunda tarefa (com ansible_distribution_major_version|int >= 7) são preenchidas, resultando nas mensagens de erro. Parece que a segunda tarefa de verificação anula os resultados da tarefa anterior.

É possível manter os resultados de ambas as tarefas? Ou tenho que copiar a tarefa de relatório e adicionar a verificação de versão a ambas? Prefiro ter o relatório em um só lugar.

A versão do Ansible é 2.4.4.0

Gerald Schneider

Asked: 2018-04-20 01:11:32 +0800 CST

o ansible-playbook 2.5 não encontra vars de grupo ao especificar um arquivo de inventário diretamente

1

Eu tenho usado scripts ansible para algumas tarefas de um tiro, por exemplo, fazendo uma primeira configuração após o provisionamento de uma VM.

Eu tenho um script que cria um arquivo de inventário temporário, usa-o para executar um playbook ansible e exclui o arquivo temporário depois:

INVENTORY=$(mktemp /tmp/inst-inventory.XXXXXX)
echo "[$FLAVOR]" > $INVENTORY
echo "$HOSTNAME user_password='$USER_PASSWORD' admin_password='$ADMIN_PASSWORD'" >> $INVENTORY
ansible-playbook -i $INVENTORY `dirname $0`/firstsetup_$FLAVOR.yml --become
rm $INVENTORY

Isso funcionou perfeitamente, mas desde a atualização do ansible de 2.4 para 2.5, os playbooks não podem mais encontrar variáveis definidas no group_varsdiretório.

$ playbooks/firstsetup.sh HOSTNAME ubuntu
Password for localadmin: PASSWORD

Running ansible-playbook firstsetup_ubuntu.yml on HOSTNAME

PLAY [ubuntu] *********************************************************************************************************

TASK [Gathering Facts] ************************************************************************************************
fatal: [HOSTNAME]: FAILED! => {"msg": "The field 'become_pass' has an invalid value, which includes an undefined variable. The error was: 'ubuntu_inisc_initialpass' is undefined"}
        to retry, use: --limit @/home/geschnei/playbooks/firstsetup_ubuntu.retry

PLAY RECAP ************************************************************************************************************
HOSTNAME                    : ok=0    changed=0    unreachable=0    failed=1

Isso undefined variableé definido ~/.ansible/group_vars/ubuntu.ymle encontrado quando executo o mesmo manual em um host listado no arquivo de inventário regular.

O roteiro para o Ansible 2.5 lista:

Adicionada opção para definir o diretório do playbook para adhoc, inventário e console para permitir o 'carregamento de caminho relativo'

O que parece estar relacionado, mas não consigo encontrar informações mais específicas sobre isso. O Guia de Portação 2.5 também não menciona nada sobre isso.

O que tenho que configurar para que o ansible-playbook encontre os group_varsarquivos novamente?

Gerald Schneider

Asked: 2017-11-14 23:15:02 +0800 CST

Mostrar pacotes atualizados com o gerenciamento de pacotes Ansible

7

Eu tenho um playbook Ansible simples que uso para executar atualizações em todos os servidores que gerencio:

- hosts: ubuntu
  tasks:
  - name: install all updates
    apt:
      upgrade: dist
      update_cache: yes
      autoremove: yes
      autoclean: yes
- hosts: centos
  tasks:
  - name: install all updates
    yum:
      name: '*'
      update_cache: yes
      state: latest
# use debug to show the output
    register: result
  - name: Show Output
    debug: msg="{{ result.stdout_lines }}"

Existe alguma maneira de fazer com que o Ansible me mostre quais pacotes são atualizados no processo? Nem o módulo apt nem o yum fornecem uma opção para isso.

A versão do Ansible atualmente usada é 2.4.

Gerald Schneider

Asked: 2017-01-12 02:05:58 +0800 CST

Depurando um tempo limite com autenticação ldap no apache

5

Estou tentando depurar um problema de tempo limite que tenho com o Apache, há alguns meses.

O padrão se parece com isso:

A cada primeira solicitação de uma nova sessão (ou após algum tempo após a última solicitação), o navegador solicita instantaneamente as credenciais e, em seguida, envia a solicitação com autenticação básica. Então o servidor espera exatamente 1 minuto antes de enviar o resultado.

As solicitações subsequentes são atendidas instantaneamente, isso só acontece para solicitações após algum tempo (não consegui identificar exatamente ainda, entre 5 e 15 minutos).

O fato de o tempo de espera ser reproduzível exatamente 60 segundos me parece um tempo limite. Se eu cancelar a solicitação e clicar em recarregar, recebo o URL solicitado instantaneamente.

Como o prompt de senha também aparece instantaneamente, posso descartar um problema com o handshake SSL entre o cliente e o servidor ou problemas de DNS nessa perna. Não importa se eu solicito um script PHP ou um arquivo de texto em branco, o que também elimina um problema com scripts no servidor. Acho que o resultado do processo de autenticação é armazenado em cache por um tempo, portanto, não é necessário para solicitações subsequentes.

Observe que a autenticação sempre é bem-sucedida, portanto, também posso descartar um problema "o controlador de domínio não respondeu".

O Apache 2.4 está sendo executado no Windows Server 2012 R2. Está configurado para autenticação LDAP:

<Location />
    AuthType Basic
    AuthName "AD Login"
    AuthBasicProvider ldap
    LDAPReferrals Off
    #AuthLDAPUrl ldap://dc01.domain.de:3268/dc=ad,dc=domain,dc=de?sAMAccountName?sub?(objectClass=*)
    #AuthLDAPUrl ldap://ad.domain.de:389/dc=ad,dc=domain,dc=de?sAMAccountName?sub?(objectClass=*) STARTTLS
    AuthLDAPUrl ldap://ad.domain.de:389/dc=ad,dc=domain,dc=de?sAMAccountName?sub?(objectClass=*) TLS
    AuthLDAPBindDN "[email protected]"
    AuthLDAPBindPassword "secret"
    Require valid-user
    Require all denied
</Location>

Como você pode ver, tentei diferentes tipos de conexão com os controladores de domínio, realmente não parece importar qual método de criptografia eu uso ou se eu passo a criptografia.

ad.domain.de resolve para vários controladores de domínio, mas o comportamento é o mesmo se eu me conectar a um controlador de domínio específico.

Sem entradas no logon de erro LogLevel info, ainda estou hesitante em aumentá-lo para debug, pois sei por experiência que tenho problemas para filtrar as informações de depuração geradas.

Existe alguma coisa que eu perdi ainda que eu possa usar para depurar o problema, ou eu tenho que passar pelo log de nível de depuração?

Gerald Schneider

Asked: 2016-02-25 01:21:41 +0800 CST

VMware OpenStack integrado com um único cluster

1

Atualmente, estou no processo de implantação do VMware Integrated OpenStack para uma instalação de teste que entrará em produção posteriormente.

No estágio atual, temos três hosts ESXi, mais serão adicionados posteriormente. Configurei todos os três hosts em um único cluster, porque li (aparentemente mal) a documentação de instalação que recomenda o uso de três clusters, mas é possível usar um único cluster.

No momento, o cluster está executando uma instância do vCenter e o vApp de gerenciamento do VIO.

Ao implantar a instância do OpenStack, não consigo selecionar o cluster como um cluster de computação, aparentemente porque ele já está em uso como o cluster de gerenciamento.

Então, parece que eu preciso:

um cluster de gerenciamento com pelo menos três hosts
um cluster de computação com pelo menos um host

É possível substituir esses requisitos para um ambiente de teste?

Gerald Schneider

Asked: 2014-12-21 14:33:01 +0800 CST

Site OpenVPN para túnel VPN de site com Windows Server 2012 R2

1

Esta é a configuração dos meus clientes:

         Site A                                     Site B
     192.168.2.0/24                             192.168.0.0/24
Client A1 --|-- Server A                    Server B --|-- Client B1
            |   (192.168.2.2)           (192.168.0.2)  |
            |   (10.8.0.6)                 (10.8.0.1)  |
Client A2 --|-- Router A ---- Internet ---- Router B --|-- Client B2
            |   (192.168.2.1)         (192.168.0.254)  |
Client A3 --|                                          |-- Client B3

O servidor A se conecta ao servidor B via OpenVPN para conectar os dois sites entre si. O Servidor A e o Servidor B eram Windows Server 2003 e agora foram reinstalados com o Windows 2012 R2. Agora o roteamento, que funcionava com a configuração de 2003, não funciona mais.

Adicionei as seguintes rotas nos servidores:

Server A: 192.168.0.0 mask 255.255.255.0 gw 10.8.0.1
Server B: 192.168.2.0 mask 255.255.255.0 gw 10.8.0.6

Rotas enviadas para os clientes via DHCP:

Clients A: 192.168.0.0 mask 255.255.255.0 gw 192.168.2.2
           default gw 192.168.2.1
Clients B: 192.168.2.0 mask 255.255.255.0 gw 192.168.0.2
           default gw 192.168.0.254

Configuração OpenVPN no Servidor A (cliente OpenVPN)

client
dev tun
proto udp
remote dyndns.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert server-sb.crt
key server-sb.key
remote-cert-tls server
comp-lzo
verb 3

Configuração do OpenVPN no Servidor B (servidor OpenVPN)

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

Pings:

Servidor A -> 10.8.0.1 OK
Servidor B -> 10.8.0.6 OK
Servidor A -> 192.168.2.2 FALHA
Servidor B -> 192.168.0.2 FALHA
Qualquer dispositivo A -> Qualquer dispositivo B FALHA
Qualquer dispositivo B -> Qualquer dispositivo A FALHA

Os firewalls em todas as máquinas com Windows foram desativados durante os testes. Meu diagnóstico é que o túnel VPN funciona, mas o problema é uma configuração no OpenVPN que impede o roteamento ou algo em minhas tabelas de roteamento está desativado.

Tenho certeza de que é a mesma configuração do Windows 2003, onde todos os dispositivos podem acessar todos os outros dispositivos em ambos os sites.

O encaminhamento de IPv4 e o roteamento de LAN estão ativados em Roteamento e acesso remoto.

Combinando OpenLDAP e Active Directory via meta backend OpenLDAP

Posso liberar GRES alocado obsoleto em um nó Slurm?

Como posso encaminhar solicitações do meu servidor web?

grep excluir padrão de várias linhas

Verificação de agregação do Zabbix Expressão de função incorreta

keepalived não detecta perda de IP virtual

Particionamento automático pré-seed

A implantação do Kolla OpenStack falha com "haproxy: aguardando o IP virtual aparecer"

Registrar variável ansible em várias tarefas

o ansible-playbook 2.5 não encontra vars de grupo ao especificar um arquivo de inventário diretamente

Mostrar pacotes atualizados com o gerenciamento de pacotes Ansible

Depurando um tempo limite com autenticação ldap no apache

VMware OpenStack integrado com um único cluster

Site OpenVPN para túnel VPN de site com Windows Server 2012 R2

Você pode passar usuário/passar para autenticação básica HTTP em parâmetros de URL?

Ping uma porta específica

Verifique se a porta está aberta ou fechada em um servidor Linux?

Como automatizar o login SSH com senha?

Como posso dizer ao Git para Windows onde encontrar minha chave RSA privada?

Qual é o nome de usuário/senha de superusuário padrão para postgres após uma nova instalação?

Qual porta o SFTP usa?

Linha de comando para listar usuários em um grupo do Windows Active Directory?

O que é um arquivo Pem e como ele difere de outros formatos de arquivo de chave gerada pelo OpenSSL?

Como determinar se uma variável bash está vazia?

Gerald Schneider's questions