Мне нужен 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, заблокированный их брандмауэром, наверняка объяснит это.
Первый вопрос, объяснит ли это плохой маршрут?
Я думаю (но далеко не уверен), что traceroute позволит мне увидеть, до какой точки отправляются пакеты. К сожалению, некоторые компоненты в сети нашей компании запрещают пакеты traceroute, поэтому:
tracert ws.betaqxl.com
Routenverfolgung zu ws.betaqxl.com [91.204.81.183] über maximal 30 Abschnitte:
1 * * * Zeitüberschreitung der Anforderung.
...
Другими словами, тайм-аут, нет ответа.
Второй вопрос: будет ли трассировка, выходящая за пределы DECIX (Франкфурт), которую я могу получить из дома, но не из офиса, доказать, что пакеты правильно маршрутизируются из сети нашей компании?
Третий вопрос: есть ли другие причины, кроме двух, перечисленных выше, почему это может не сработать? Моя глупая оплошность не должна быть исключена ... но имя хоста и весь URL определенно верны, а инструменты curl ping и tracert , как правило, надежны.
Четвертый и последний вопрос: за исключением очевидных нетехнических действий (когда наши ИТ-специалисты и их ИТ-специалисты проверили конфигурацию, уже сделали это), что еще я могу сделать на техническом уровне, чтобы определить причину этого сбоя?
Извините за то, что задали четыре вопроса в одном, но я думаю, вы можете видеть, что для неопытного в сетевых вещах все они связаны с одной и той же проблемой.