Файл конфигурации связывания 802.3ad на сервере Ubuntu 16.04 LTS

Если я использую ручную настройку в командной строке (следуя инструкциям ядра ), я могу правильно настроить свое сетевое соединение:

# modprobe bonding mode=4 miimon=100
# ifconfig bond0 up
# ip link set eno1 master bond0
# ip link set eno2 master bond0

Для записи, переключатель используется Cisco Nexus 2248, и я не указываю IP-адрес, потому что есть дополнительный уровень 802.1q (наличие или отсутствие которого в файле конфигурации не влияет на проблему).

Проблема в том, что я не могу создать правильный файл / etc / network / interfaces , чтобы это выполнялось автоматически во время загрузки. В сети существует много путаницы между различными версиями пакета ifenslave, особенно с его документацией, а также с тем, как избежать состояний гонки при использовании ifup. То, что работало с предыдущими версиями Ubuntu, больше не работает. И я бы не стал Не удивлюсь, если systemd сделает вещи еще более беспорядочными. По сути, что бы я ни пытался, мои скрипты застревают во время загрузки, и мне приходится ждать одну или пять минут, прежде чем процесс загрузки завершится.

Это лучшее, что я мог достичь:

auto lo
iface lo inet loopback

allow-bond0 eno1
iface eno1 inet manual
       bond-master bond0

allow-bond0 eno2
iface eno2 inet manual
       bond-master bond0

auto bond0
iface bond0 inet manual
       bond-mode 4
       bond-slaves eno1 eno2
       bond-miimon 100

Во время загрузки выводится bond0 останавливается на одну минуту (поскольку bond0 ждет, пока будет запущен хотя бы один из его ведомых устройств, этого никогда не происходит, поэтому время ожидания истекает), но затем после загрузки системы срабатывает использование ifup eno1 и bond0 начинает работать правильно.

Если я укажу auto eno1 , то процесс загрузки остановится на пять минут, bond0 никогда не будет запущен должным образом и при попытке использовать ifdown eno1 получит застрял, потому что ожидает блокировки в / run / network / где угодно (не могу вспомнить точный файл, * Имя хоста НЕ было ...

У меня есть хост с сертификатом LE, и он хорошо работает в браузерах, но я все еще не могу подключиться с помощью curl , openssl , wget , POST (libwww-perl):

curl

# curl -v -3 https://example.com/
* Hostname was NOT found in DNS cache
*   Trying 123.123.123.123...
* Connected to example.com (123.123.123.123) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to example.com:443 
* Closing connection 0

openssl

# openssl s_client -connect example.com:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 295 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

wget

# wget --post-data "key=val" -vvv https://example.com/
--2016-05-11 11:19:01--  https://example.com/
Resolving example.com (example.com)... 123.123.123.123
Connecting to example.com (example.com)|123.123.123.123|:443... connected.
Unable to establish SSL connection.

POST

# echo 'key=val' | POST https://example.com:443 
Can't connect to example.com:443

LWP::Protocol::https::Socket: SSL connect attempt failed with unknown error SSL wants a read first at /usr/share/perl5/LWP/Protocol/http.pm line 41, <STDIN> line 1.

Конфигурация Vhost:

<VirtualHost *:443>
  ServerName example.com
  SSLEngine On
  SSLProtocol ALL -SSLv2 -SSLv3
  SSLHonorCipherOrder On
  SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
  SSLVerifyDepth 10
  SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/live/example.com/fullchain.pem
  DocumentRoot "/var/www/"
</VirtualHost>
3
задан 11 May 2016 в 11:38
1 ответ

Думаю, ваша проблема связано с DNSSEC. Для зоны существует запись DS:

[me@risby ~]$ dig ds codestronaut.com
[...]
;; ANSWER SECTION:
codestronaut.com.       86363   IN      DS      19465 8 1 42AFC90FE0A61D3993051C55B6C4C35518713921

, но запись A для chat беззнаковая:

[me@risby ~]$ dig +dnssec +trace chat.codestronaut.com
[...]
codestronaut.com.       172800  IN      NS      dns1.yandex.net.
codestronaut.com.       172800  IN      NS      dns2.yandex.net.
codestronaut.com.       86400   IN      DS      19465 8 1 42AFC90FE0A61D3993051C55B6C4C35518713921
codestronaut.com.       86400   IN      RRSIG   DS 8 2 86400 20160517050727 20160510035727 34745 com. Xk/mK5Y8LigJyP+iPF9arhZXKmsDvslfigom/7BZ2orIKHFGAX8/Q9eE O4rRCZPQD82WBssFHf/jcYSUiZrF/j6Ovq4sPbOJbjPUUoHlkOb8uGe/ 3erv6snM8SKVu8eSaE42cj8efvNRZR4S1MMesD5HGG1gMzjQLkTvHiEN wmE=
;; Received 329 bytes from 192.54.112.30#53(h.gtld-servers.net) in 18 ms

chat.codestronaut.com.  21600   IN      A       95.158.40.23
;; Received 66 bytes from 2a02:6b8::213#53(dns1.yandex.net) in 66 ms

Обратите внимание на отсутствие записи RRSIG для chat.codestronaut .com . Это приводит к тому, что поиск DNS просто не выполняется на определенных платформах:

[me@risby ~]$ curl https://chat.codestronaut.com
curl: (6) Could not resolve host: chat.codestronaut.com

Я не думаю, что есть много шансов заставить все это работать надежно, пока вы не исправите свой DNS; либо попросите вашего регистратора прекратить публикацию записи DS для зоны, либо правильно подпишите вашу зону. Я не говорю, что это единственная проблема, но наличие работающего DNS в значительной степени является предварительным условием для всего остального, включая отладку.

Править : вы говорите, что отключили DNSSEC, но изменение еще не распространено (это может занять до дня, поскольку TTL для вашей старой записи DS составлял 86400 с). Используя клиент без DNSSEC, я не могу воспроизвести проблемы, о которых вы сообщаете, но хочу отметить, что вы используете SNI в этой системе (т. Е. Доступно несколько сертификатов SSL, включая оба chat.codestronaut.com и panel.codestronaut.com ).

curl -v -3 явно не поддерживает SNI (поскольку SNI является расширением TLS и поэтому недоступен в SSLv3) . openssl s_client работает нормально после предупреждения о SNI:

[me@lory tmp]$ openssl s_client -connect chat.codestronaut.com:443 -servername chat.codestronaut.com
[...]
Certificate chain
 0 s:/CN=chat.codestronaut.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
 1 s:/CN=chat.codestronaut.com
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
 2 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

, хотя без флага SNI ( -servername ... ) он получает сертификат для панели . вместо этого.

Итак, в настоящий момент ваш исходный отчет « он хорошо работает в браузерах, но я все еще не могу подключиться с помощью [других инструментов] », похоже, сводится к «, он работает хорошо,кроме случаев, когда я подключаюсь с использованием инструментов, которые не должны работать в этой настройке ". Это немного похоже на отсутствие проблем.

10
ответ дан 3 December 2019 в 04:52

Теги

Похожие вопросы