===[ Железо ]=== #post-id: 5836-03-33 #original-date: 18.07.2016 Mon #original-time: 3:33 AM #original-day: 5836 #original-host: WinXP Home SP3 (Build 2600) В общем, на днях я заметила, что у меня подозрительно притормаживает настольная машина. Началось всё с Инета, когда один сайт грузился слишком долго. Я открыла HandyCache, а тот повис. «Кэш!» – подумала я и открыла Мой компьютер. Тут Проводник и повесился. Я ждала несколько минут, пока он не отвис. Попыталась зайти на сетевой диск с тем же результатом. При этом на буке всё открывалось, я заходила на сетевые диски и открывала файлы с них. Но это объяснимо: бука работает круглосуточно, а настольная машина засыпает. Может быть после спячек авторизация сбрасывается, и при запросе к сетевому диску винда пытается авторизоваться на удалённой машине снова, и всё вешается. В итоге удалённо потушила NAS, и висяки почти прекратились, разве что системе требовалась пара секунд чтобы понять, что сетевые диски ни к чему не присоеденены. После повторного включения NAS, догадка подтвердилась: висяки постигли и буку: открываю Мой коспьютер, и наблюдаю белый квадрат. Перезагрузки NAS не помогали, даже старый трюк с его загрузкой при выдернутом сетевом кабеле не помог. В первый раз после вставки кабеля, устройство так и не увиделось в сетевом окружении, имя машины не распозновалось, хотя по айпишнику прорваться можно было. Во второй раз были те же висяки. /* Сейчас я вспоминаю это и нахожу странным, что при обращении по айпишнику висяков не было. Надо бы исследовать этот момент OO */ Попутно в syslog сообщениях от модема была куча «DNS query failed». В принципе, на NAS DNS серверы указаны отдельно, они гугловские, но видимо у самого модема возникли проблемы с разрешением имён. Висяки наблюдаются в основном при проблемах с Инетом. В тот момент Инет был, но, очевидно, провайдер опять начал безобразничать с DNS, и, считай, инета снова не было. Кроме того, такое происходит при попытке авторизации на самба-сервере, а когда вторизация состоялась, всё вроде работает. На данный момент основная теория такая: NAS (Seagate GoFlex Home) проверяет логин и пароль не только у себя в линукс-нутрях, но и на сервере Seagate Share или типа того. Так как Инета нет, процесс авторизации подвешивается и в итоге отваливается. Всё это и выражается в висяках. Зонды шалят, если коротко. Ну, бесперебойный Инет я ему обеспечить не могу, но DNS – неплохо бы. К сожалению, с установкой софта на этом устройстве есть ряд проблем, поэтому я не могла поставить Deadwood или DNSCrypt (ранее они спасли мои прочие машины). Так же на модеме или роутере такое тоже не поставишь, а баловаться всякими хирыми прошивками не охота – есть все шансы остаться без Инета и с кирпичом в ожидании, когда местные торгаши завезут ещё пару роутеров. Что делать? И тут я вспомнила, что у DeadWood есть настройка, указывающая, с каких айпишников пускать клиентов. По умолчанию он слушает только 127.0.0.1, и пускает с 127.0.0.1/16. А что если разрешить клиентам в локальной сети подключаться к нему, раз напрямую никак? /* Я не буду расписывать подробности установки и настройки DeadWood, просто опишу идею с кусками конфига ^^ Если интересны подробности – ищите предыдущий пост на эту тему. */ В общем, открываем dwood3rc.txt и начинаем настройку. Для начала привяжемся к локалхосту и адресу в локальной сети. Вариант с 0.0.0.0 не прокатил, поэтому пришлось точно указывать адреса. У меня за известными устройствами на DHCP закреплены фиксированые адреса, чтобы доступ извне через NAT иметь, так что тут проблемы не возникает. Ищем настройку «bind_address» и прописываем туда айпишники. В примере я указываю свои. Было: > bind_address="127.0.0.1" Стало: > bind_address="127.0.0.1, 192.168.1.210" Теперь ищем настройку «recursive_acl» и прописываем туда всех, кому можно коннектиться. По умолчанию там только локалхост. Я разрешила коннектиться всей локальной сети вместо конекретного айпишника just in case. Было: > recursive_acl = "127.0.0.1/16" Стало: > recursive_acl = "127.0.0.1/16, 192.168.1.0/24" /* Стыдно признаться, но я всё время путаюсь в такой форме записи =_= */ Хочу отметить, что я оставила 127.0.0.1, хотя для простоты можно было указать только адрес в локальной сети. Но это я сделала для удобстав локальных програм и системы, чтобы не перебивать айпишник в настройках сетевого интерфейса каждый раз, когда бука будет появляться в новой сети. Окей. Осталось открыть в файрволе порт 53 хотя бы для локальной сети, чтобы клиенты могли подключиться. Делать это надо для UDP и TCP, в основном – для UDP. Теперь пора указать NAS'у, где живёт хороший DNS сервер. Нам нужно залогиниться по SSH на NAS и поправить файл /etc/resolv.conf. Можно это сделать и по вэб-интерфейсу, но там вроде как только два слота для DNS серверов, а в конфиге можно указать хоть двести, что я и хочу сделать, попутно запихнув туда гугловские адреса и OpenDNS. На всякий пожарный. В начале этого файла находится подозрительный каммент: > ; generated by /sbin/dhclient-script Такой скрипт существует, и он большой. Но я видела только раз сообщение о перезаписи resolv.conf и не уверена, что его вызвало. Кроме того, я воспользовалась вот такой ссылкой и удалила часть зондов: http://www.openstora.com/wiki/index.php?title=Disabling_updates_and_external_access /* Разумеется, тут инструкции про нетгировский NAS, но принцип тот же. */ Так что есть шанс, что трагедия не повторится. А если повторится, то всегда можно поправить конфиг. В общем, логинимся и через рута пишем в /etc/resolv.conf вот такое: > nameserver 192.168.1.210 > nameserver 192.168.1.200 > nameserver 8.8.8.8 > nameserver 8.8.4.4 > nameserver 208.67.222.222 > nameserver 208.67.220.220 > nameserver 208.67.220.222 > nameserver 208.67.222.220 Первые две строчки – машины в локальной сети, на которых стоят DeadWood и DNSCrypt. Если по какой-то причине они будут не доступны, NAS не растеряется и будет прорываться на актуальные DNS сервера (но у него всё равно чаще всего это не получится). Собственно, после этого даже без перезагрузки NAS должен подхватить новые DNS сервера, и начать ломиться по надёжному каналу, а не через дикую природу. Открываем Мой компьютер и изумляемся фантастической скорости работы и постоянной доступности сетевых дисков. ---------- ~ ---------- Кстати о. Когда я пыталась прорваться по SSH на NAS через PuTTY, я неожиданно столкнулась с проблемой, которой раньше не видела. Раньше, когда я логинилась, PuTTY не находил в настройках приватного ключа и предлагал ввести пароль. После того как я начала юзать агент, эта схема перестала работать, и PuTTY начинал пихать SSH серверу все ключи подряд, пока не получал отказ из-за превышения попыток авторизации. Я нашла галочку про ключ и сняла её. В общем и целом это сработало, и PuTTY прекращал перебирать ключи, но иногда это не помогало, и приходилось тушить агент на время работы с NAS. В этот раз что-то пошло не так (может быть последнее обновление сказалось), и я не получала запрос пароля даже если агент был закрыт. Просто очень длгое ожидание и разрыв соедиенения со стороны сервера. Я поначалу связала это с проблемами описанными выше. Но что-то не клеилось. Раньше даже если самба была в дауне, я прекрасно заходила через тот же SFTP, а это тот же SSH. Да и в этот раз я как-то не задумываясь зашла с работы по SFTP глянуть один файл из бэкапов, и вдруг поняла, что WinSCP-то работает. Короче, в настройках авторизации была отдельная страница с каким-то GSS API, который тоже был включен. Как только я сняла галочку, все проблемы волшебным образом исчезли, и сервер сразу предлагал мне ввести пароль. Как я уже сказала, раньше такой фигни не было! ---------- ~ ---------- /* (Не)интересно, какое бы гогно вылезло в камментах к этому посту, если бы он был на пойнтожуйках? */