Не удается получить доступ к сайту linux

Обновлено: 05.07.2024

Я попытался изменить DNS-серверы на общедоступные. Я даже попытался загрузиться из Fedora LiveCD и , затем , изменив DNS на те (и даже на OpenDNS), но то же самое происходит. Что может быть по своей сути неправильным в некоторых конфигурациях в самой Linux, что вызывает эту проблему?

Кто-нибудь знает, почему это происходит и как оно может быть исправлено?

3 ответа

У вас есть симптомы проблемы MTU : некоторые TCP-соединения замораживаются, более или менее воспроизводимо для данной команды или URL-адреса, но без легко различимого общего шаблона. Типичным симптомом является то, что интерактивные сеансы ssh работают хорошо, но передача файлов почти всегда терпит неудачу. Кроме того, pppoe является номером один для проблемы MTU для домашних пользователей. Поэтому я предписываю проверку MTU.

Что это такое? m aximum t ransmission u nit - максимальный размер пакета по сетевой ссылке. MTU варьируется от транспортной среды до транспортной среды, например. проводной Ethernet и Wi-Fi (802.11) имеют разные MTU и ATM (которые составляют большую часть инфраструктура междугородной связи), каждая из которых имеет свой собственный MTU. PPPOE - это инкапсулированный протокол, что означает, что каждый пакет состоит из нескольких байтов заголовка, за которым следует базовый пакет, - поэтому он уменьшает максимальный размер пакета на размер заголовка. IP позволяет маршрутизаторам фрагментировать пакеты, если они обнаруживают, что они слишком велики для следующего перехода, но это не всегда работает. В теории надлежащее MTU должно быть открыто автоматически , но это также не всегда работает. В частности, googling предполагает, что Network Manager не всегда должным образом воздействует на информацию MTU, полученную при обнаружении MTU, но я не знаю, какие версии затронуты или что представляют собой проблемные варианты использования.

Как измерить его. Если у вас tracepath из Linux iputils , запустите tracepath 8.8.8.8 , чтобы увидеть MTU по пути к DNS-серверу Google. Если ваша версия traceroute имеет --mtu option, запустите traceroute -n --mtu 8.8.8.8 . См. Откройте для себя MTU между мной и IP-адресом назначения для получения дополнительных параметров.

Как установить его (замените 1454 на MTU, который вы определили, и eth0 по названию вашего сетевого интерфейса)

  • Как один раз (Linux): run ifconfig eth0 mtu 1454
  • Постоянно (Debian и дериваторы, такие как Ubuntu, если не используете Network Manager): Изменить /etc/network/interfaces . Сразу после ввода вашего сетевого интерфейса (после iface eth0 … ), добавьте строку с помощью pre-up ifconfig $IFACE mtu 1454 . В качестве альтернативы, если ваш IP-адрес является статическим, вы можете добавить параметр mtu 1454 в iface eth0 inet static .

Постоянно (Debian и производные, такие как Ubuntu, с или без Network Manager): Создайте сценарий под названием /etc/network/if-pre-up.d/mtu со следующим содержимым и сделайте его выполнимым по всему миру ( chmod a+rx ):

Дополнительные ресурсы

  • Как диагностировать надежное ненадежное соединение? (в частности ответ Майка Пеннингтона ) может оказаться полезным, если простой метод измерения и ограничения, описанный здесь, не работает.

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

Я бы попробовал добавить аппаратный маршрутизатор, специально рекомендованный номером модели вашим интернет-провайдером. Мало того, что это может привести к согласованию PPPoE-соединения точно так же, как ваш интернет-провайдер, возможно, он также решит проблему с SSL-соединениями.

Если это не поможет вашей непосредственной проблеме, вы все равно получите от нее несколько преимуществ.

Во-вторых, большинство домашних маршрутизаторов позволяют делиться своим интернет-соединением с несколькими ПК.

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

Я попытался изменить DNS-серверы на общедоступные. Я даже пытался загрузиться с Fedora LiveCD и затем сменить DNS на них (и даже на OpenDNS), но происходит то же самое. Что может быть по сути не так с некоторыми конфигурациями в самом Linux, которые вызывают эту проблему?

Update: Только видел здесь , что кто - то имел подобную проблему и решить ее, поставив NetworkManager.conf файл /etc/NetworkManager . Что должно быть в этом файле?

У вас есть признаки проблемы MTU : некоторые TCP-соединения зависают, более или менее воспроизводимо для данной команды или URL, но без какого-либо легко различимого общего шаблона. Характерным признаком является то, что интерактивные сеансы SSH работают хорошо, но передача файлов почти всегда заканчивается неудачей. Кроме того, pppoe является источником проблем MTU для домашних пользователей. Поэтому я прописываю проверку MTU.

Что это? М aximum т ransmission у нита максимального размера пакета по каналу сети. MTU варьируется от транспортной среды к транспортной среде, например, проводной Ethernet и Wi-Fi (802.11) имеют разные MTU, а каналы ATM (которые составляют большую часть инфраструктуры дальней связи) имеют свои собственные MTU. PPPOE - это инкапсулированный протокол, который означает, что каждый пакет состоит из нескольких байтов заголовка, за которым следует базовый пакет, поэтому он уменьшает максимальный размер пакета на размер заголовка. IP позволяет маршрутизаторам фрагментировать пакеты, если они обнаруживают, что они слишком велики для следующего перехода, но это не всегда работает. В теории должен быть обнаружен надлежащий MTUавтоматически , но это тоже не всегда работает. В частности, поиск в Google предполагает, что Network Manager не всегда должным образом действует на информацию MTU, полученную из обнаружения MTU, но я не знаю, какие версии подвержены уязвимости или каковы проблемные варианты использования.

Как измерить это. Если у вас есть tracepath из Linux iputils , запустите, tracepath 8.8.8.8 чтобы увидеть MTU по пути к DNS-серверу Google. Если ваша версия traceroute имеет --mtu опцию, запустите traceroute -n --mtu 8.8.8.8 . Посмотрите Обнаружение MTU между мной и целевым IP для большего количества вариантов.

Как его установить (замените 1454 на MTU, которое вы определили, и eth0 на имя вашего сетевого интерфейса)

Пишу бота на питоне. Запустил Фласк, по адресу localhost:5000 на пк с линукс открывается страница, которую он формирует. Однако при попытке открыть эту страницу через локалку по ip:5000 вылетает ошибка: Не удается получить доступ к сайту. Помогите советом, подскажите, что делать…


По-хорошему, принято в качестве веб-сервера использовать отдельную софтину (в настоящее время чаще всего это nginx), которая принимает запросы и передаёт их серверу приложения (в вашем случае это flask). Но если уж очень хочется: run(host=0.0.0.0,…) @AlexanderProkoshev это конечно оффтоп, но в настоящее время чаще всего это nginx . Давайте поделимся статистикой. Есть, например, вот такое. nginx из года в год показывает стабильный рост, но под определение "чаще всего" пока еще не подходит. Из прошлогоднего. Да, есть у nginx региональные предпочтения, но в целом это опять таки не "чаще всего". А еще бывает так, что Apache стоит за nginx-ом.

Если я правильно понимаю сервер запущен слушать на localhost:5000, но ты питаешься получить доступ к нему из другого устройства в подсети. Но это действительно не сработает.

Проблема в том что когда ты говоришь серверу слушать какой-то адрес, это значит принимать соединения с интерфейса который связан с этим адресом. 127.0.0.1 назначен интерфейсу loopback (lo при выводе ip addr), и предназначен для работы внутри устройства.

Но если необходимо предоставить доступ не только устройству необходимо изменит интерфейс, простейший вариант слушать 0.0.0.0:5000, это дефолтный хост, все запросы необработанные определенным интерфейсом в конце концов попадут туда, доступ в таком случае можно получит с устройства, из локальной сети и даже из Интернета.

Но если необходимо ограничить доступ только для локальной сети, тогда надо слушать на адресе из этой сети, напимер 192.168.0.10:5000, или что-то в этом духе, в зависимости от IP-адреса локальной сети.


Веб сервер в локальной сети только один

А локалхостов — много.

Укажите конкретный ип адрес. Твой планшет по сути тоже локалхост.

garik_keghen ★★★★★ ( 06.01.17 23:37:50 )
Последнее исправление: garik_keghen 06.01.17 23:38:22 (всего исправлений: 1)

Веб сервер в локальной сети только один

И всегда открывался только этот сервер.

Открываеться 192.168.0.101, но по внешнему ip ничего не открывается. Что делать?

но по внешнему ip ничего не открывается

Было все нормально, все открывалось, с Ростелекомом, потом сменился провайдер из-за переезда. По внешнему ip ничего не открывается, хотя по localhost все открывалось. Решил что в сервере проблема, у текущего провайдера ограничений никаких нет, переустановил, localhost не открывается.

А почему по внешнему ничего не открывалось? Спасибо


а по ssh на localhost пускает? ))



Попробуй подсоединиться, во-первых, по ip компьютера в локальной сети (не 127.0.0.1, в ifconfig после inet у интерфейса правильного).

А по поводу внешнего ip — стоит убедиться, что новый провайдер даёт белые ip.


А по поводу внешнего ip — стоит убедиться, что новый провайдер даёт белые ip.

Ещё может понадобиться настроить NAT loopback чтобы ходить по белому айпи изнутри сети.

В TP Link есть? Пробежался - нету.

Открываеться 192.168.0.101, но по внешнему ip ничего не открывается.


Ещё может понадобиться настроить NAT loopback чтобы ходить по белому айпи изнутри сети.


Если у нового айпишники серые выдаются, то и Port Forwarding, и NAT loopback на данном этапе бессмысленны и факт того что они настроены бесполезен.


Вы случаем не забыли, что у новый провайдер выдал новый, т.е. другой IP-адрес?


В TP Link есть? Пробежался - нету.


Если у нового айпишники серые выдаются

Хотя, помнится, мой провайдер перед тем как начать выдавать белый айпи прямо на интерфейс клиента сначала выдавал серый, а потом у себя мапил его на уникальный белый.


Хотя, помнится, мой провайдер перед тем как начать выдавать белый айпи прямо на интерфейс клиента сначала выдавал серый, а потом у себя мапил его на уникальный белый.

Как это проявлялось, как выяснилось и на что влияло?

В моём городе Ростелеком ещё со времён когда он был Волгателекомом без проблем даёт белые IP, ничего дополнительно просить/доплачивать даже не надо. И всё нормально работает.

Провайдер недавно появился в городе, пока нормально, ip 87.238.x.x.

Всегда использовал noip, было все нормально, но не с этим провайдером..


Как это проявлялось, как выяснилось и на что влияло?

На сетевой интерфейс клиента по DHCP выдавался серый айпи (192.168.*.*), но все сервисы, поднятые клиентом, были доступны извне по статическому белому айпи, уникальному для каждого клиента, который указывался в личном кабинете. Лет пять назад начали выдавать те же самые статические белые адреса уже прямо на интерфейс клиента, всё это что тогда что сейчас автоматически и бесплатно.


Всегда использовал noip, было все нормально, но не с этим провайдером..

Возможно что этот провайдер засунул тебя за NAT, из-за чего ты и не можешь всякими noip пользоваться, либо тебе 80/443 порт закрыли. Лучше прочти договор и спроси у техподдержки провайдера.

Не то что noip, я по внешнему ip перейти не могу, соседей просил перейти - тоже самое. Позвонил, никаких ограничений на порты нет, сказали потом уточнят про белый ip. Но почему перед переустановки ubuntu переходило по localhost? Сейчас 16.04 не переходит.


У нас статика отдельной услугой идёт, приходится dyndns-сервисы использовать.

В целом механизм понятен, спасибо.


Но почему перед переустановки ubuntu переходило по localhost?

h578b1bde ★☆ ( 07.01.17 00:34:30 )
Последнее исправление: h578b1bde 07.01.17 00:34:52 (всего исправлений: 1)

/etc/hosts 127.0.0.1 localhost 127.0.1.1 computer

::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters

Читайте также: