Не удается получить доступ к избранным сайтам https в Linux через PPPoE
Раньше мое интернет-соединение было прямым соединением с моим провайдером. Тогда все работало бы нормально как в Windows, так и в Ubuntu (двойная загрузка). Однако некоторое время назад они начали нуждаться в том, чтобы я набирал номер (PPPoE), используя имя пользователя и пароль. Шлюз, маска подсети, IP, DNS-серверы остались прежними. Но с тех пор я не смог просматривать определенные сайты в Ubuntu, хотя в Windows таких проблем не было. Некоторые примеры веб-сайтов — страница входа в Ovi (хотя share.ovi.com загружается нормально, а nokia.com загружается нормально), Live Mail (работает в Chrome (ium) и Opera, но не в Firefox (как 3.6, так и 4)) Mozilla Аддоны сайта и другие случайные сайты.
На некоторых сайтах, которые не загружаются, отображаются сообщения о тайм-ауте, а на некоторых сайтах (например, moz addons) браузер будет пытаться загрузить без конца (я оставлял его таким даже несколько часов, но не заметил ничего другого). бывает).
Я попытался изменить DNS-серверы на общедоступные. Я даже пытался загрузиться с Fedora LiveCD и затем сменить DNS на них (и даже на OpenDNS), но происходит то же самое. Что может быть по сути не так с некоторыми конфигурациями в самом Linux, которые вызывают эту проблему?
Кто-нибудь знает, почему это происходит и как это можно исправить?
Примечание. Этот вопрос был опубликован в SU, но не получил никаких ответов.
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 для большего количества вариантов.
Не имея автоматизированных инструментов, вы можете измерить вручную. Попробуйте отправить ping-пакеты заданного размера внешним хостам, которые на них отвечают, например ping -c 1 -s 42 8.8.8.8 (в Linux; в других системах посмотрите документацию вашей ping команды). Ваши пакеты должны пройти для достаточно малых значений 42 (если 42 не работает, что-то блокирует пинг.). Для больших значений пакет не пройдет. 1464 — типичное максимальное значение, если ограничивающим элементом инфраструктуры является ваша локальная сеть Ethernet. Если вам повезет, когда вы отправите слишком большой пакет, вы увидите сообщение вроде Frag needed and DF set (mtu = 1492) . Если вам не повезло, продолжайте экспериментировать со значением, пока не найдете максимальное значение, а затем добавьте 28 ( -s указывает размер полезной нагрузки, и помимо этого есть 28 байтов заголовков). Смотрите такжеКак оптимизировать подключение к Интернету, используя MTU и RWIN на форумах Ubuntu.
Как его установить (замените 1454 на MTU, которое вы определили, и eth0 на имя вашего сетевого интерфейса)
- Как раз (Linux): запустить 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 ):
Другие ресурсы
- Как диагностировать надежно ненадежное соединение? (в частности , ответ Майка Пеннингтона ) может оказаться полезным, если описанный здесь простой метод измерения и ограничения не работает.
Источник
Debian по-прежнему отказывается использовать HTTPS
APT (advanced packaging tool) — программа для установки, обновления и удаления программных пакетов в операционных системах Debian и основанных на них (Ubuntu, Linux Mint и т. п.). Иногда также используется в дистрибутивах, основанных на Mandrake. Пакеты скачиваются по интернету из репозиториев по незащищённому соединению, без использования протокола TLS и шифрования. Возникает вопрос: почему? Разве HTTPS не обеспечивает лучшую безопасность? Debian считает, что HTTPS — лишняя сущность, поскольку система SecureAPT проверяет контрольную сумму для скачанных файлов и криптографическую gpg-подпись всего пакета.
Один из разработчиков Debian запустил сайт whydoesaptnotusehttps.com («Почему APT не использует HTTPS»), где объясняет официальную позицию.
Как работает SecureAPT
Во-первых, apt сравнивает хэши файлов из пакета. Они публикуются на сайте Debian в файле Release…
…и передаются вместе с пакетом.
Чтобы защитить файл Release от подделки, система SecureAPT добавляет цифровую подпись gpg, которая находится в файле Release.gpg:
Программа apt скачивает файл Release.gpg и проверяет подпись с помощью доверенных публичных ключей, которые хранятся в файле /etc/apt/trusted.gpg. По умолчанию там записан записан публичный ключ архива Debian.
Это последняя линия защиты, поэтому Debian периодически меняет ключи. Новые ключи распространяются с пакетом debian-archive-keyring, а также публикуются на веб-странице.
После публикации нового публичного ключа происходит ещё одна процедура. Секретный ключ, который использовался для генерации открытого ключа, с помощью программы gfshare делится на пять частей и распределяется между пятью авторитетными разработчиками по схеме разделения секрета Шамира. Чтобы восстановить секрет, как минимум трое из пяти разработчиков должны предоставить свои части секрета. Математическое доказательство схемы Шамира публиковалось на Хабре: оно основано на том, что через две точки на плоскости можно провести неограниченное число полиномов степени 2. Чтобы выбрать из них единственный — нужна третья точка. Проще говоря, схема основана на полиномиальной интерполяции.
Итак, в системе SecureAPT секретный ключ разделён на пять частей и надёжно защищён, криптографическая подпись файла Release проверяется общедоступным публичным ключом, а в этом файле хранятся контрольные суммы файлов из пакета. Зачем же использовать HTTS, если всё так защищено?
Зачем использовать HTTP?
Основная задача HTTPS — скрыть трафик от посторонних глаз (провайдер, государственные службы и другие злоумышленники), чтобы третье лицо не смогло:
- Вмешаться в трафик (модифицировать его).
- Прослушать трафик (сбор информации, разведка).
Система SecureAPT частично защищает от первой угрозы, но не от второй. Поскольку пакеты передаются по открытым каналам, то постороннее лицо видит, какие конкретно пакеты скачиваются и откуда. Злоумышленник может и подменить пакеты и цифровую подпись, но тогда она не пройдёт проверку.
Разработчик Debian пишет:
HTTPS не обеспечивает значимой конфиденциальности для получения пакетов, поскольку злоумышленник обычно видит, с какими хостами вы связываетесь. Если вы подключитесь к зеркалу дистрибутива, будет совершенно очевидно, что вы загружаете обновления.
Вероятно, этот абзац написан в те времена, когда браузеры и интернет-сервисы не начали поддерживать технологию DNS over TLS и DNS over HTTPS (DoH) для шифрования DNS-трафика. Например, в апреле 2018 года её внедрил один из крупнейших CDN-провайдеров Cloudfalre, а в октябре 2018 года Google Public DNS тоже включил поддержку DNS over TLS.
Таким образом, после соответствующей настройки системы можно эффективно прятать DNS-запросы от постороннего лица, которое прослушивает трафик. Также идёт активная работа над внедрением других технологий, которые скрывают адресата пакетов. То есть в будущем HTTPS всё-таки сможет обеспечить должную конфиденциальность.
Debian приводит ещё один аргумент: даже на зашифрованном соединении «несложно выяснить, какие файлы скачивает пользователь по размеру трафика». Эту «уязвимость» можно использовать даже при анализе трафика через Tor.
Наконец, Debian не видит причин полностью доверять центрам сертификации: существует более 400 CA, которые предлагают сертификаты для любого домена. У многих плохая репутация, а некоторые напрямую контролируются государством. Сложно определить, какому CA можно доверять.
Таким образом, по мнению Debian, самое главное — гарантировать подлинность файлов в пакете, а не защитить само соединение.
Почему бы не внедрить HTTPS поверх существующего механизма SecureAPT? Разработчик считает это сложной инженерной задачей, которая требует безопасного обмена и хранения секретных ключей. Кроме того, внедрение HTTPS подразумевает «введение в заблуждение пользователей относительно уровня безопасности и конфиденциальности» по причинам, описанным выше.
В 2019 году сознательный отказ от HTTPS выглядит весьма экстравагантно, поэтому позиция Debian вызвала оживлённую дискуссию на Hacker News, где комментаторы выдвинули несколько контраргументов.
Что думаете вы, нужно ли шифровать трафик apt? (Опрос ниже).
Источник
Настройка HTTPS в Linux
Что такое HTTPS протокол и зачем он нужен? HTTPS — обеспечивает безопасное (зашифрованное) интернет соединение. При работе с каким либо сайтом по HTTPS протоколу, все передаваемые, между клиентов и сервером данные шифруются. Для шифрования данных используется SSL сертификат. В основном такие соединения используются интернет-магазинами, банками. В общем сайтами где осуществляется передача пользователем своих личных данных. Существует множество SSL сертификатов. В данной статье не будут рассматриваться виды или типы SSL сертификатов.
Рассмотрим настройку HTTPS протокола на сервере Linux с установленной CentOS с web сервером Apache (httpd). В принципе директивы конфигурации web сервера на разных дистрибутивах Linux не отличаются друг от друга. Отличие есть только в названии пакетов, которые необходимо установить. Все начинается с установки web сервера Apache и модуля mod_ssl. Данный web сервер рассматривается, т.к. на данный момент он является самым популярным среди своих аналогов.
Вводим команду: yum install httpd mod_ssl
После установки пакетов, mod_ssl уже будет загружен в конфигурацию apache, необходимо запустить сам web сервер командой service httpd start . Если при запуске не возникло ошибок, то продолжим редактирование файла конфигурации.
Для настройки возможности использования HTTPS на вашем сервере необходимо отредактировать главный файл конфигурации apache — httpd.conf. В нем прописываются сами виртуальные хосты, по которым web сервер понимает какую папку ему необходимо просмотреть, чтобы найти файлы сайта, которые он будет обрабатывать. Для того, чтобы Ваш сайт открывался по безопасному протоколу Вам необходимо объявить хост — NameVirtualHost ваш_IP:443 . Обычно apache работает на 80 порту (стандартный порт протокола http), для HTTPS используется 443 порт. В блоке VirtualHost ваш_IP:443 необходимо прописать все стандартные директивы конфигурации ServerName, DocumentRoot, ServerAlias и т.д. Для включения HTTPS протокола необходимо дополнительно, в этом же VirtualHost прописать еще несколько директив и перезапустить сервис командой service httpd restart. Директивы:
SSLEngine on
SSLCertificateFile /path/to/your/cert/file/cert.crt
SSLCertificateKeyFile /path/to/your/key/file/cert.key
SSLCACertificateFile /path/to/your/ca/file/ca.crt
В принципе настройка завершена. Вы можете использовать самоподписанный сертификат для работы или же купить SSL сертификат у центра сертификации или у реселлеров. При использовании самоподписанного сертификата браузеры выдают предупреждения о том, что сертификат используемый на сервере является самоподписанным и к нему нет доверия.
Источник
Не работают некоторые https-сайты на debian
Давно заметил, что на Debian не открываются некоторые https-сайты
Естественно куки, кеш и т.д. чистить бессмысленно, четко видно, что проблема системная и не зависит от браузера. Более того, такая же бяка на других машинах с debian (версии разные: 6, 7, 8)
Очевидно, что проблема в протоколе, но почему только с некоторыми сайтам и как это решается? И главное ничего не нагугливается, может кто в курсе в чем проблемы? На том же компе на virtualbox на винде эти же сайты благополучно открываются (то есть проблема точно не у интернет-провайдера).
Это в железе проблема.
проблема в дебьяне
да нет, иначе почему на этом же железе на виртуальной машине на винде эти же сайты открываются — это раз, два — на других дебианах других железяк с этими же сайтами та же проблема.
на сайтах ключи или протокол новый в дебьяне устаревшие(и каменного века) либы не поддерживают это
попробуй пользоваться нормальным дистрибутивом
это 100%, единственное я не знаю почему это происходит и как решать? Вот к примеру у меня есть сервера от online.net, теперь чтобы зайти к ним в аккаунт приходится заходить с виртуальной машины с винды, что за фигня, раньше (где-то месяц назад) нормально ходил с дебиана, но были аналогичные проблемы с некоторыми другими сайтами на https. Проблема однозначно в ОС, но что именно и как решать хз.
ну нифига себе, оказывается чтобы зайти на такие сайты нужно сменить всего лишь. дистрибутив ) другие идеи будут?
лечись от аутизма,он тут у подавляющего большинства лоровцев
ведро то у тебя поди 2.4 версии еще-все правильно делаешь,борись терпи экономь!
Нет, ядра посвежее, например с компа с которого щас пишу:
$ uname -a Linux valet-comp 3.2.0-0.bpo.4-amd64 #1 SMP Debian 3.2.63-2+deb7u1
bpo60+1 x86_64 GNU/Linux
Но это debian 6 и с этого компа данный сайт не открывается (как и некоторые другие)
Также не открывается этот и некоторые другие сайты на https с ноута с debian 6 (но ядро не древнее как гавно мамонта), с ноута с debian 7 (там уже по умолчанию ядро не ниже чем 3.2 кажется) и с компа с debian 8. Но на одном ноуте с debian 8 он таки открывается (что кстати странно)! Ну и везде на виртуалке с любой винды он естественно открывается. Куда копать, пофик на дистр и ядро — ведь все равно же должны сайты открываться, что за жесть.
не открываются некоторые https-сайты
Это обычное состояние современных HTTPS-сайтов, ничего удивительного. По-возможности, просто избегай их.
А это нормально, что этот сайт грузит все восемь ядер CPU на 25%? Может и не велика потеря?
Это обычное состояние современных HTTPS-сайтов, ничего удивительного. По-возможности, просто избегай их.
С чего бы это избегать их?
А это нормально, что этот сайт грузит все восемь ядер CPU на 25%?
Никогда не замечал подобного, между прочим это сайт очень крупного ДЦ во Франции.
Вообще-то у меня там аккаунт, заказанные сервера, я вынужден туда заходить, просто теперь приходится ходить туда через ж..пу ой винду на виртуальной машине, что за.
Кстати я и избегал их (вынуждено, хотя понимал, что проблемы именно в дебиане), но когда дело коснулось в том числе сайта, куда я просто вынужден заходить так как у меня там аккаунт, я просто не выдержал и создал эту тему. Ведь наверняка есть какое-то решение данной проблемы, несколько лет этот сайт благополучно работал в дебиане (на некоторых других проблема уже была), то есть с таким успехом скоро и яндекс с гуглом перестанет работать, что тогда — тоже не избегать их.
Сервер не найден
Firefox не может найти сервер http://www.kremlin.ru.
Проверьте, не допущена ли ошибка при наборе адреса, например, ww.example.com вместо http://www.example.com
Если ни одна страница не загружается – проверьте настройки соединения с Интернетом.
Если компьютер или сеть защищены межсетевым экраном или прокси-сервером – убедитесь, что Firefox разрешён выход в Интернет.
у меня открывается, по http вроде бы все открываются, а вот по https не все, вот вопрос почему и как это решить?
Дебиан 7? Щас проверю.
valet
А у меня работает, только что обновил 7.11 (давно не трогал) и установил firefox-esr
Информация о системе:
Информация о браузере:
Устанавливал как обычно: apt-get install firefox-esr firefox-esr-l10n-ru .
А это нормально, что этот сайт грузит все восемь ядер CPU на 25%?
Ни чего у меня не грузит, одно ядро, два потока, открылся чуть похуже ЛОРа, свежая 45-я лиса.
Тем не менее у меня на разных компах и разных дебианах не работает, работает только на одном ноуте, на котором debian 8/
Посмотри на конфиг репозиториев, из бекпортов тут ни чего нет. Приведи в такой же вид, обнови через apt-get dist-upgrade . Установи чистую лису, она тоже идет прям из репозитория, без извращений. Проверь на чистом профиле.
Вот если тогда не заработает — будем думать чем твой дебиан отличает о того из которого я пишу тебе этот месседж.
Уточню, а то мало ли — предыдущее сообщение касается 7.11.
Так мне такой вариант не подходит, с каких это пор, чтобы зайти на какой-то сайт нужно обновлять дистрибутив, вы серьезно? Другие варианты никак? Мне не хочется ламать всю рабочую систему (а я уверен, что при dist-upgrade точно что-то сломается и перестанет работать и тогда придется ломать мозг мне), меня все устраивает кроме вот такого вот беспредела по «неоткрытию НЕКОТОРЫХ сайтов по https»
Подозреваю, что проблема в этом
$ openssl version OpenSSL 0.9.8o 01 Jun 2010
Но почему такое происходит? Нельзя ли как-то заставить систему игнорировать безопасность что ли (или в чем там проблема) чтобы открывались принудительно нужные мне сайты.
а я уверен, что при dist-upgrade точно что-то сломается и перестанет работать и тогда придется ломать мозг мне
Там жаба и браузер, замены готовит команда LTS, можешь ограничиться ‘apt-get upgrade’ — придут только обновления безопасности.
Скачай портабельную версию с сайта лисы тогда, в конце концов.
Нельзя ли как-то заставить систему игнорировать безопасность что ли
Сайты выключили не безопасные протоколы на своей стороне. Тебя спасет портабельная версия, вот тебе пакет:
А так можешь сидеть с голым задом дальше, хозяин барин.
В дебиане нету проблемы, нечего брехать попусту. ЛТС поддерживается, и думаю даже на Squeeze заведется лиса в портабельной сборке.
А то что ТС боится накатить обновления безопасности — ну это его дело.
В тебе проблема, задрал все темы зафлуживать.
на сайтах ключи или протокол новый в дебьяне устаревшие(и каменного века) либы не поддерживают это
Да, сайты повыключали говно мамонта и правильно сделали. Все критические библиотеки 7.11 будут обновляться минимум до мая 2018 года. Для 8-ки и того дольше.
Это обычное состояние современных HTTPS-сайтов, ничего удивительного. По-возможности, просто избегай их.
В рамках оффтопа: недавно набрёл на https-only говнолэндинг какой-то местной веб-шаражки с талантливыми верстальщиками™, так там мало того что с включённым NoScript вообще никакой контент не отображается, так ещё и сертификат на 3 месяца просрочен. Это чтобы ты представил масштабы бедствия.
ЛТС поддерживается, и думаю даже на Squeeze заведется лиса в портабельной сборке.
собственно на основном рабочем компе как раз древний как гавно мамонта сквиз, больше всего надо заставить работать как минимум этот сайт именно здесь. буду пробовать установить портабельную версию esr — надеюсь это не поломает iceweasel, он продолжит работать в штатном режиме или что-то сломается?
А то что ТС боится накатить обновления безопасности — ну это его дело.
Да, боюсь и смысла не вижу, как говориться «работает — не трогай». Когда-то на одном ноуте решил обновиться со сквиз до джесси. Делал все в точности по официальной инструкции с офсайта дебиана: там предлагалось, насколько я помню, поэтапное обновления сначала до визи, а потом до джесси. И кто бы сомневался — ничего не вышло, причем насколько я помню даже до визи не удалось проапгрейдиться — посыпались какие-то ошибки, я пробовал гуглить их и решать по мере поступления, в результате задолбался и тупо все снес и поставил свеженький дебиан 8 — только так. Поэтому сейчас ставить хоть какие-то обновления на рабочую лошадку очень не хочется, что-то сломается это точно и получу проблемы посерьезнее чем невозможность открыть некоторые сайты по https и тогда придется ломать мозг.
Да, сайты повыключали говно мамонта и правильно сделали
А чего правильно? Что это им дает? Я понимаю, что моя система может быть уязвимой если не обновлять, но им чем это грозит? И да, почему эти же сайты работают на древней винде с виртуалки, где тоже ничего никогда не обновлялось?
Все критические библиотеки 7.11 будут обновляться минимум до мая 2018 года. Для 8-ки и того дольше.
Вот это поворот. то есть если я не буду обновлять дистр, то рано или поздно у меня ни один сайт не откроется — так что ли? И сразу возникает мысль, а какого фига оно все без проблем работает на какой-то древней винде типа xp.
установить портабельную версию esr — надеюсь это не поломает iceweasel, он продолжит работать в штатном режиме или что-то сломается?
Она живёт в отдельной директории в которую ты распакуешь архив. Но! Подхватывает дефолтный конфиг пользователя в хомяке, аккуратней, сломает: забекапь заранее. Еще искаропки настроено автообновление (во время работы только, без демонов), исправляется в настройках самой лисы одной галкой.
Когда-то на одном ноуте решил обновиться со сквиз до джесси.
В рамках одной ветки рекомендуется устанавливать обновления безопасности, у тебя там дыр сейчас как в дуршлаке, если не больше. И та самая эпичная в OpenSSL — Heartbleed. Тут в 7.11 дист-упгрейд касается ЛТС и замены совсем уж древностей (jawa, древний iceweasel на ESR-firefox). Для сквиза тоже был ЛТС и там обновы выходили, у меня нет уже их, можешь посмотреть — там был перенос репозиториев ЛТС на новые адреса, можешь поискать старые мануалы.
Поэтапно обновлять да, не всегда без проблем — сразу несколько выпусков особенно. Быстрее заново сконфигурировать, особенно всякие десктопы. Кстати, заморозка 5 февраля, емнип, так что если что-то будешь накатывать — ставь сразу тестинг.
Вот это поворот. то есть если я не буду обновлять дистр, то рано или поздно у меня ни один сайт не откроется — так что ли? И сразу возникает мысль, а какого фига оно все без проблем работает на какой-то древней винде типа xp.
На винде XP та же лиса как раз такая как я тебе дал ссылки на пакеты — всё своё носит с собой, нужной свежести. Поэтому и работает.
Меньше вероятность что будут скомпрометированы соединения. После Heartbleed думать о безопасности стали чуточку больше.
работают на древней винде с виртуалки, где тоже ничего никогда не обновлялось?
Какой там браузер и какая версия?
Online.net Special Deals Order English Base price Company Blog Console Webmail Services status +1 302-782-0229 Online.net Online.net
Debian 8.7, Firefox 45 ESR из репозитория jessie
Источник
