LINUX.ORG.RU
Форум — General  

github не скачивает с российского ip

 


0

1

wget 'https://github.com/cronie-crond/cronie/releases/download/cronie-1.7.2/cronie-1.7.2.tar.gz'

Вот такая ерунда.

--2024-04-10 14:23:49--  https://github.com/cronie-crond/cronie/releases/download/cronie-1.7.2/cronie-1.7.2.tar.gz
Resolving github.com (github.com)... 140.82.121.4
Connecting to github.com (github.com)|140.82.121.4|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/79243149/650dc989-2530-4e4c-a818-d1dd5b2acb39?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20240410%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240410T112347Z&X-Amz-Expires=300&X-Amz-Signature=ec918845612a9c442469215131a343edd70838bb2052a4c0415dd45825f4a0e1&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=79243149&response-content-disposition=attachment%3B%20filename%3Dcronie-1.7.2.tar.gz&response-content-type=application%2Foctet-stream [following]
--2024-04-10 14:23:49--  https://objects.githubusercontent.com/github-production-release-asset-2e65be/79243149/650dc989-2530-4e4c-a818-d1dd5b2acb39?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA53PQK4ZA%2F20240410%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240410T112347Z&X-Amz-Expires=300&X-Amz-Signature=ec918845612a9c442469215131a343edd70838bb2052a4c0415dd45825f4a0e1&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=79243149&response-content-disposition=attachment%3B%20filename%3Dcronie-1.7.2.tar.gz&response-content-type=application%2Foctet-stream
Resolving objects.githubusercontent.com (objects.githubusercontent.com)... 185.199.110.133, 185.199.111.133, 185.199.108.133, ...
Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|185.199.110.133|:443... connected.
^C

Через vpn качает. Это уже или еще нет? Кто может подтвердить?

★★★

Последнее исправление: arrecck (всего исправлений: 1)

Попробуй так

wget -vvv 'https://github.com/cronie-crond/cronie/releases/download/cronie-1.7.2/cronie-1.7.2.tar.gz'

Что говорит? Или так

curl -v -o cronie-1.7.2.tar.gz -L 'https://github.com/cronie-crond/cronie/releases/download/cronie-1.7.2/cronie-1.7.2.tar.gz'
PRN ★
()
Последнее исправление: PRN (всего исправлений: 2)

А можешь попробовать вот этот файл

curl https://habrastorage.org/r/w48/getpro/habr/avatars/353/8eb/088/3538eb088997a0fd418ce85841dd0996.png

У меня такая же ситуация с этим(и не только, этот для теста) файлом с прошлой недели. Провайдер отмораживается что у них всё нормально.

Loki13 ★★★★★
()
Последнее исправление: Loki13 (всего исправлений: 1)
Ответ на: комментарий от Loki13

Если тебе от этого легче, то у меня все работает)

curl -v 'https://habrastorage.org/r/w48/getpro/habr/avatars/353/8eb/088/3538eb088997a0fd418ce85841dd0996.png'
* Host habrastorage.org:443 was resolved.
* IPv6: (none)
* IPv4: 51.89.30.72
*   Trying 51.89.30.72:443...
* Connected to habrastorage.org (51.89.30.72) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=habrastorage.org
*  start date: Mar 26 00:00:00 2024 GMT
*  expire date: Apr 26 23:59:59 2025 GMT
*  subjectAltName: host "habrastorage.org" matched cert's "habrastorage.org"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha384WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://habrastorage.org/r/w48/getpro/habr/avatars/353/8eb/088/3538eb088997a0fd418ce85841dd0996.png
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: habrastorage.org]
* [HTTP/2] [1] [:path: /r/w48/getpro/habr/avatars/353/8eb/088/3538eb088997a0fd418ce85841dd0996.png]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET /r/w48/getpro/habr/avatars/353/8eb/088/3538eb088997a0fd418ce85841dd0996.png HTTP/2
> Host: habrastorage.org
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200 
< server: nginx
< date: Wed, 10 Apr 2024 18:27:02 GMT
< content-type: image/png
< content-length: 2333
< last-modified: Wed, 10 Jan 2018 09:09:42 GMT
< etag: W/"5a55d856-15c3"
< access-control-allow-origin: *
< strict-transport-security: max-age=31536000; includeSubDomains
< x-proxy-cache-status: HIT
< 
Warning: Binary output can mess up your terminal. Use "--output -" to tell 
Warning: curl to output it to your terminal anyway, or consider "--output 
Warning: <FILE>" to save to a file.
* Failure writing output to destination, passed 2333 returned 4294967295
* process_pending_input: nghttp2_session_mem_recv() returned -902:The user callback function failed
* Connection #0 to host habrastorage.org left intact
PRN ★
()
Ответ на: комментарий от CrX

Имея российский ip давно пора обзавестись VPN с нероссийским ip.

Ну вот есть у меня VPN, но это же не повод мне мою Gentoo через VPN обновлять. А у меня проблема схожая с проблемой ТС, только у меня ещё и ключи обновления генты скачать не может без ВПН.

Loki13 ★★★★★
()
Ответ на: комментарий от Loki13

но это же не повод мне мою Gentoo через VPN обновлять

А что делать, если и правда заблочат? Сейчас проблема может и в другом, но в целом надо готовиться к такому развитию событий.

P.S. У меня оба файла качаются нормально с российского IP.

CrX ★★★
()
Ответ на: комментарий от arrecck

сейчас проверил. github заработал, c habrstorage тоже файл без проблем скачался.

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

PS: Подозреваю что это РКН что-то блочить пытается. В рабочее время. Уходят с работы и разблочивают.

Loki13 ★★★★★
()
Ответ на: комментарий от CrX

Имея российский ip давно пора обзавестись VPN с нероссийским ip. Уже много лет как сложно без этого представить нормальное пользование интернетом.

Бред.

VPN и ему подобные технологии для личного использования ниразу за более чем четверть века за компьютером не потребовались. И это несмотря на обширный охрат потребностей в том или ином софте, документации и т.п.

anonymous
()
Ответ на: комментарий от Loki13

Подозреваю что это РКН что-то блочить пытается. В рабочее время. Уходят с работы и разблочивают.

Надуманная ситуация. Скорее ошибка провайдера. У меня несколько раз в месяц ночью провайдер профилактические работы выполняет, либо свет «моргает», видимо, из-за стройки нового микрорайона с прокладкой новых сетей, после этого несколько минут, а то и час с доступом к некоторым ресурсам проблемы.

anonymous
()
Ответ на: комментарий от TPPPbIHDELj

У меня для одного из серых ip провайдера блокировался доступ к liberachat, так как этот ip был в каком-то списке. Для других было всё норм. Мне в итоге просто белый ip выдали и этим проблема решилась.

grem ★★★★★
()

УМВР, IP стопудово российский, средства обхода не используются.

Скорее всего, что-то не так конкретно с твоим IP/провайдером.

hobbit ★★★★★
()
Ответ на: комментарий от CrX

Такой вариант прикроют/запретят точно раньше, чем VPN

Не уверен.

В Китае с VPN борются, а с симками из Гонконга - нет.

Насчет «дорого и пинг большой» - согласен. Тем не менее, до переезда на Филиппины, я держал две симки (одну из Гонконга, другую с Филиппин) на такой случай и периодически проверял.

AEP ★★★★★
()
Ответ на: комментарий от anonymous

VPN и ему подобные технологии для личного использования ниразу за более чем четверть века за компьютером не потребовались. И это несмотря на обширный охрат потребностей в том или ином софте, документации и т.п.

Или речь не про РФ или потребности узкие или 3.14-шь. Ограничения притом с обеих сторон забора наблюдаются.

anonymous
()
Ответ на: комментарий от anonymous

Надуманная ситуация. Скорее ошибка провайдера.

Вот у меня в 9:24 утра, так картинка с хабра загружалась, а сейчас уже нет.

Причем вешается всё на этапе

== Info: Host habrastorage.org:443 was resolved.
== Info: IPv6: (none)
== Info: IPv4: 51.89.30.72
== Info:   Trying 51.89.30.72:443...
== Info: Connected to habrastorage.org (51.89.30.72) port 443
== Info: ALPN: curl offers h2,ht
tp/1.1
=> Send SSL data, 5 bytes (0x5)
0000: 16 03 01 02 00                                  .....
== Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
=> Send SSL data, 512 bytes (0x200)
.... [Тут блобик небольшой]
Loki13 ★★★★★
()

Не знаю что они там мутят, но проблема сводится к резолву objects.githubusercontent.com. Как только повторится проблема сравню днсы и будем разбираться. Костыльный фикс (у меня сработало 3/3 раз) - почистите днс кеш.

anonymous
()
Ответ на: комментарий от anonymous

Столкнулся с аналогичной проблемой на днях. При попытке резолва objects.githubusercontent.com мы получаем следующие IP-адреса:

185.199.108.133
185.199.111.133
185.199.110.133
185.199.109.133

Все IP-адреса доступны из РФ. Однако при попытке обращения к 185.199.110.133 по HTTPS наблюдаю блокировку с местного провайдера + Yandex Cloud серверов. Пока не могу с уверенностью сказать связанно ли это с PКН, но вот костыльное решение проблемы:

echo -e "185.199.108.133 185.199.109.133 185.199.111.133\tobjects.githubusercontent.com" >> /etc/hosts
anonymous
()
Ответ на: комментарий от anonymous

Немного углубившись, оказалось, что мое предыдущее костыльное решение не исправляет проблему полностью. Если брать за правду то что PКН на самом деле заблокировал 185.199.110.133, то потенциально мы можем столкнуться с частичной недоступностью ~280 доменов GitHub.com (https://imgur.com/a/tNnrRFc), исходя из информации Reverse Lookup SecurityTrails.

В итоге пришел к следующему решению проблемы:

iptables -t nat -A OUTPUT -d 185.199.110.133 -j DNAT --to-destination 185.199.109.133

Данное правило будет изменять адрес назначения для исходящих пакетов с адресом назначения 185.199.110.133 на 185.199.109.133.

Также я проанализировал список из 282 доменов, полученных из SecurityTrails с помощью Reverse Lookup и обнаружил, что все домены резолвятся в 4 ранее упомянутых IP-адреса.

185.199.108.133
185.199.109.133
185.199.110.133
185.199.111.133

Таким образом, подобное правило не должно как-либо заафектить на работоспособность других ресурсов.

anonymous
()
Ответ на: комментарий от etwrq

Да там вроде английским по черному написано в чем проблема)

Warning: Binary output can mess up your terminal. Use "--output -" to tell 
Warning: curl to output it to your terminal anyway, or consider "--output 
Warning: <FILE>" to save to a file.

И я просто соединение делал, файл мне не нужен.

PRN ★
()
Последнее исправление: PRN (всего исправлений: 1)

Вероятно один ip (185.199.110.133) был в черных списках у РКН. Сейчас я проверил все 4 ip адреса 185.199.108.133 - 185.199.111.133. Со всех работает. Через пару дней можно еще раз проверить.

arrecck ★★★
() автор топика
General