файл отрицательного размера

Сегодня настраивал маршрутизатор (pfsense) для подсоединения офисной сетки через нового интернет-провайдера. Казалось бы, задачка элементарная, что там может быть сложного..
Но я, как обычно, наступил на загадочные грабли:

1) Настроил DHCP-сервер, для проверки подключил свой ноутбук, посмотрел ifconfig’ом, вроде адрес нормальный выдался, но в интернеты ходить почему-то не получается.

Traceroute вообще никуда не доходит, даже до pfsense’а.
Запустил ip route show, и офигел: default route почему-то не в этот pfsense, а в какой-то совершенно другой IP, которого в этой сетке вообще нету..
А ip address show показал, что на eth0 кроме адреса, выданного pfsense’ом, есть ещё один, из той сетки, где этот непонятный default gateway..

Попробовал повыключать-повключать eth0, ничего не поменялось. Ну, то есть, когда выключал, все адреса и маршруты пропадали, а когда обратно включал – появлялись те же два адреса, и default route в тот же несуществующий gateway.

Посмотрел в /etc/network/interfaces – там ничего нету. Запустил гномовский конфигуратор NetworkManager‘а – там всё настроено чисто по DHCP, никаких дополнительных адресов нету.

Решил поискать, где оно ещё может быть – запустил в /etc grep того загадочного IP, и.. он нашёлся в /etc/NetworkManager/system-connections/Wired connection 1 :
[ipv4]
method=auto
address1=10.12.1.38/24,10.12.1.1

Но в гномовском сетевом конфигураторе ничего подобного почему-то не видно.. А если уж Network Manager взял из этого конфига статический адрес и gateway, так какого ж хрена он на тот же интерфейс прицепил ещё и DHCP’шный адрес??

Короче, удалил нафиг этот address1, всё заработало..

Оригинал этой записи в личном блоге.

Позавчера попробовал поставить у себя на десктопе в virtualbox’е виртуальную машинку с pfsense’ом, чтобы проверить, где он глючит. Но скопировать оригинальный диск с VMware’ного сервера не удалось — типа, ошибка случилась. Непонятно какая.. Короче, пришлось установить заново с нуля, и скопировать туда конфиг с той рабочей машинки.

Pfsense’овые WAN и LAN прикрутил к виртуальным host-only сеткам, чтоб можно было туда зайти с десктопа. Зашёл и по ssh, и через веб, стал менять настройки VPNов.
Дефектов в config.xml не случилось, но некоторые изменения почему-то внезапно вызывали перезагрузку машины.. Хотя после перезагрузок она нормально читала свой конфиг и успешно запускалась.

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

Первым делом попробовал на десктопе прикрутить NAT через eth0 к тому host-only интерфейсу vboxnet0, на котором у десктопа как раз и был адрес gateway, использовавшийся pfsense’ом. Но почему-то не сработало. Похоже, эти vboxnet’ы управляются только virtualbox’ом, а нормальные сетевые утилиты на них не работают.

Потом попробовал соединить в бридж pfsense’овый WAN с десктопным eth0. Это, естественно, тоже не сработало, потому что у pfsense’а там был статический публичный адрес из своей сети, и она использовала в качестве gateway адрес из той же сети, которого в местной сетке вовсе не было.

Ну, отключил там на WAN статический адрес, включил DHCP, pfsense получил адрес из местной сетки и правильный gateway, но.. почему-то всё равно никуда соединиться не мог. Запустил tcpdump, и оказалось, что несмотря на полученный по DHCP адрес, pfsense почему-то отправлял пакеты наружу со своего публичного CARP-адреса, который тоже был из той же публичной сети, потому он в местной сетке не работал: пакеты наружу не проходили, но даже если б прошли, ответы бы всё равно не вернулись.

Попробовал выключить в pfsense этот CARP-адрес, а не дают — типа, он используется в настройках многих VPN’ов, поэтому нельзя его удалить..

Выходит, надо использовать тот статический адрес и NAT’ить его самим virtualbox’ом. Вернул адрес, прицепил WAN к virtulabox’овому NAT, — тоже не работает. Кажись, virtualbox там свои адреса использует, из 192.168..

Тогда создал в virtualbox’е отдельную NAT Network, явно приписав туда сетку, которую использовал pfsense, и на стороне сервера приделал туда адрес gateway. А фиг, всё равно наружу не ходит, и даже этот gateway не пингается, хотя он там точно должен быть.

Долго думал, как бы всё же организовать связь с интернетами. Разве что поставить туда ещё одну виртуальную машинку в качестве gateway, и на ней организовать NAT.. Но приделывать к маршрутизатору дополнительный маршрутизатор — это ж бред..

В конце концов грабли удалось обойти следующим образом:

Оригинал этой записи в личном блоге.

Вчера один коллега сделал элементарные изменения в настройках маршрутизатора (pfsense). После чего этот pfsense завис нафиг. Я попробовал его перегрузить, всё равно не отзывается. Пришлось подключиться к консоли и внимательно смотреть, чё там не так. (Машинка виртуальная, поэтому подключиться к её консоли оказалось относительно просто, а вообще-то она в Кении..) Оказалось, что сам маршрутизатор вполне себе грузится, но почему-то IP-адресов на сетевых интерфейсах нету. Посмотрел в конфиг — адреса на месте. Перегрузил ещё раз, а они опять пропали. На консоли обнаружилась очень странная ошибка: “PHP Fatal error: Cannot create references to/from string offsets nor overloaded objects in /etc/inc/xmlparse.inc on line 77“..

Посмотрел в этот xmlparse.inc, а это оказался скрипт на PHP. Сравнил его с таким же файлом на другом pfsense, который успешно работает — файлы совершенно одинаковые. Проверил изменения в config.xml – немножко действительно есть, но формат файла вполне нормальный. Подложил прежнюю версию конфига, перегрузил pfsense – опять та же ошибка. Попробовал более старую версию конфига подложить, где ещё не было вчерашних изменений, а фиг — всё то же самое..

После этого начальник предложил запустить на этом pfsense reset, а потом приделать IP-адреса заново. Попробовал — вышло. Но всё остальное заново руками конфигурировать не хотелось, поэтому попробовал опять подложить старый конфиг, и внезапно он успешно прочитался, и всё заработало.

А сегодня решил сам попробовать поменять то, что вчера менял коллега. Через веб-интерфейс. В натуре, мелочи в настройках одного VPN: IKEv1 на Auto, hash с sha512 на sha1, DH group с 16 на 2. Аблин, опять те же грабли!

pfsense опять перестал отвечать, и после перезагрузки опять показывал на консоли ту же ошибку, и не мог прицепить IP-адреса к сетевым интерфейсам. Пришлось, подсунуть вчерашний полупустой config – он заработал. Потом подложил старый конфиг с полными настройками – тоже заработал.

Ну какого хрена эти PHPшные быдлокодеры пишут такой дурацкий софт?! Изменения, сделанные через ихний же веб-интерфейс, оказываются настолько кривыми, что потом весь конфиг не может прочитаться. Короче, нафиг этот pfsense. Пожалуй, надо переезжать на более приличные системы. Может, на какой-нибудь VyOS. Хотя у него web-интерфейса нет, но и таких граблей тоже нет.

Оригинал этой записи в личном блоге.

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

Ну я первым делом проверил живость наших машинок – количество процессов, загрузку процессоров, отсутствие проблем с дисками, но вроде всё в норме. Попробовал оттуда позапускать telnet, traceroute, tcptraceroute в сторону нужных серверов — и в натуре, то работает, то не работает. Ощущение такое, что где-то по дороге сеть перегружена, и оттого пакеты частично пропадают. Причём пропадают прямо сразу, traceroute иногда даже первого хопа не видит, хотя это наш собственный маршрутизатор на pfSense. Зашёл на него, процессор не сильно загружен, памяти хватает, своп вообще не используется, диск полупустой, трафик не сильно большой. На всякий случай спросили у провайдера, он прислал примерный график входящего/исходящего трафика за последние сутки, так вообще мелочи, меньше мегабита в секунду.

Итак, вопрос: попробуйте угадать, что там случилось, и как его починить.

Ответ под катом.

Оригинал этой записи в личном блоге.