curl зависает после приветствия клиента
Эта ошибка возникла из-за отсутствия зависимостей, которые apt-get не удалось решить.
В моем случае пакеты уже были загружены apt-get при первой попытке установки. Глядя на первый вывод, dpkg выдает ошибку в этом пакете libc6_2.24-9_amd64.deb .
dpkg -i /var/cache/apt/archives/libc6_2.24-9_amd64.deb
В этом каталоге apt-get сохраняет файлы deb в качестве кеша.
Во втором выводе вы могли увидеть, что есть еще одна зависимость, поэтому найдите нужный пакет в этом каталоге и установите его.
dpkg -i /var/cache/apt/archives/libc-bin_2.24-9_amd64.deb
Если больше нет зависимостей, вы можете продолжить установку.
apt-get install gcc/testing
Внимательно посмотрите на полученный файл. информация о командах apt-get, иначе вы можете прекратить удаление импортированных вещей в вашей системе
У меня недостаточно баллов для комментариев, но ответ Чарли помог мне решить проблему с настройкой маскировки. Однако я не мог удалить устройство, так как в моем случае это было исходящее соединение ppp0.
В данном случае мне помогло уменьшить mtu других клиентов до значения устройства ppp0 (1492 )либо напрямую, либо через конфигурацию dhcpd. В этом случае симптомами были проблемы с рукопожатиями TLS при попытке получить электронные письма (только с некоторых серверов )и с потоковой передачей видео от других клиентов.
У меня такая же проблема с двумя инфраструктурами, подключенными через OpenVPN.
Curl не работает с https/http
Решение Чарли мне подошло.
Я перешел по этой ссылке:https://www.sonassi.fr/help/troubleshooting/setting-correct-mtu-for-openvpn.
Таким образом, чтобы найти правильный MTU, вы можете использовать эту команду:
bryan@debian-dev11@ping -c 1 -M do -s 1472 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 1472(1500) bytes of data.
1480 bytes from 10.0.0.5: icmp_seq=1 ttl=126 time=6.19 ms
Где 1472 — это тестируемый MTU
И ответ с плохим MTU
bryan@debian-dev11:~$ ping -c 1 -M do -s 1474 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 1474(1502) bytes of data.
ping: local error: Message too long, mtu=1500
Брандмауэр вашего целевого сервера должен принимать запросы icmp/echo.
В моем конкретном случае я был за двумя маршрутизаторами, через два правила nat, одно за другим. Когда пакет прибыл на конечный хост, конечный хост запрашивал отсутствующую часть другого шлюза, а не исходный IP-адрес... поэтому запрос не мог прийти на исходный хост.