Определение причины проблемы подключения TCP / IP

мне нужен HTTPS доступ к хосту ws.betaqxl.com, но подключиться не удается:

:: curl -k -v https://ws.betaqxl.com
* About to connect() to ws.betaqxl.com port 443 (#0)
*   Trying 91.204.81.183... Timed out
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host

две вещи, чтобы отметить:

• доступ к этому хосту для нашего IP-номера должен быть предоставлен в их брандмауэре.
• наши пакеты на этот хост должны быть маршрутизированы из нашей сети через интерфейс, отличный от интерфейса по умолчанию (статический, а не динамический IP-номер), который настроен на IP-номер, который другая сторона должна предоставить доступ к.

есть, я думаю, две вероятные причины, почему это может потерпеть неудачу:

• я заблокирован брандмауэром; несмотря на их заявления об обратном, доступ не давал.
• наш статический маршрут для этого конкретного хоста плохой и направляет мои запросы в нирвану.

Итак, человеческая ошибка здесь или там.

что дальше, чтобы определить причину проблемы?
Давайте попробуем ping и tracert.
Ну, я не получаю ping-ответы от этого хостера:

:: ping ws.betaqxl.com
Ping wird ausgeführt für ws.betaqxl.com [91.204.81.183] mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
...
Ping-Statistik für 91.204.81.183:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

другими словами, тайм-аут, 100% потере пакетов.
ICMP, заблокированный их брандмауэром, безусловно, объяснил бы это.

первый вопрос, плохой маршрут объяснить?

I думаю (но я далеко не уверен), что трассировка позволит мне увидеть, до какой точки идут пакеты.
К сожалению, некоторые компоненты сети нашей компании отрицают пакеты traceroute, so:

tracert ws.betaqxl.com

Routenverfolgung zu ws.betaqxl.com [91.204.81.183] über maximal 30 Abschnitte:

  1     *        *        *     Zeitüberschreitung der Anforderung.
  ...

другими словами, тайм-аут, нет ответа.

второй вопрос:
Будет ли трассировка, выходящая за пределы DECIX (Франкфурт), которую я могу получить из дома, но не из офиса, доказывать, что пакеты правильно маршрутизируются из сети нашей компании?

третий вопрос:
Существуют ли вероятные причины, отличные от двух перечисленных выше, почему это может произойти сбой? Моя глупая оплошность не должна быть исключена ... но имя и адрес точно правильный, а то curl и ping и tracert инструменты, как правило, надежны.

четвертый и последний вопрос:
За исключением очевидного нетехнические шаги (просим наш ИТ и их ИТ проверить конфигурацию, уже сделано что),
что еще я мог сделать на технические уровень, чтобы определить причину этого сбоя?

Извините, что задаю четыре вопроса в одном, но я думаю, вы можете видеть, что для неспециалиста в сетевых вещах все они связаны с такая же проблема.