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

Да нифига! Они у нас в компании и тут работают, и в Англии, и никаких проблем не вызывают.
А основные дефекты у меня на работе почему-то провоцируются африканцами. В смысле, вовсе не неграми, а просто живущими в Африке. Там и белых нынче немало.

Вот, например, выдали мне задачу организовать там VPN с одним клиентом. Казалось бы, ничего сложного тут нет. Они прислали форму со всеми параметрами, я всё сконфигурировал, переслал им через тамошнего нашего сотрудника PSK (ключ для шифрования), но этот VPN больше месяца не удавалось включить. Обсуждали это с ними в онлайновом чате, я просил проверить ихние настройки, они просили прислать скриншоты настройки VPNа с нашей стороны, но ничего не помогло. В конце концов выяснилось, что они у себя почему-то установили совершенно другой ключ. И когда его прислали, и я его подправил, и VPN таки заработал.

Или вот сейчас там один сервер стал дико тормозить. Тамошний сотрудник решил, что туда слишком много запросов приходит, и попросил меня заблокировать доступ к тамошнему апачу со всех IP, разрешить только с одного. Ну, я на firewall’е это быстро сделал, а он пожаловался, что после redirect’а с того IP, он не может попасть на веб-сайт. Ну, естественно, доступ же заблокирован.
Оказалось, что он на самом деле хотел разрешить запросы не с самого этого IP, а со ссылками с тамошнего веб-сервера. То есть, referer в запросах проверять надо, а вовсе не IP-адрес клиентского браузера.

А теперь ещё просит меня сконфигурировать на том сервере несколько экземпляров apache. А нафига это там может понадобиться, толком объяснить не может.

Выходит, что термин “афрадминистраторы” не просто так придуман, а имеет реальные основания..

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

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

А потом в первом приделанном VPNе отключил DPD (dead peer detection), и после сохранения опять те же грабли — pfsense завис нафиг, а после перезагрузки не смог приделать IP-адреса к сетевым интерфейсам. Пришлось, как и вчера, запустить reset, потом подложить прежний конфиг из backup’ной директории — а фиг, всё равно не работает. Потом попробовал парочку других конфигов, но всё равно не помогло.

В конце концов скопировал все конфиги из backup’а на другую машинку и стал рассматривать, в чём различия. И тут наконец-то обнаружилась причина этих граблей: в нескольких конфигах (а они в XML’ном формате) нашлась идиотская штука, которая, собственно, и разваливала эти xml’и:

        <remoteid>
            <type>address</type>
            <address>10.11.12.13</address>
        </remoteid>
    rithm-option>
        <pfsgroup>0</pfsgroup>

Похоже, это обрезанный кусок <encryption-algorithm-option> , но вот как он туда попал, и как продолжал там иногда оставаться при перезаписывании конфига — это загадка. Явно криворукие похапэшные быдлокодеры виноваты.

Потом подложил более старый конфиг, в котором этой фигни ещё не было, и pfsense наконец заработал. А DPD подредактировал в том конифге руками, сработало.

Ну, короче, как водится, грабли удалось обойти, но на это потратился почти весь рабочий день. А главное — непонятно, как их в будущем избежать. Все изменения в xml руками вписывать не сильно просто. А в командной строке там тот же php используется, так что есть шанс получить те же (или даже ещё более кривые) грабли.

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

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

Из последних случаев:
— Юзер не может залогиниться в свой ноутбук (с 10 виндой). Отдельного администраторского эккаунта там нету, только он сам. Только что, говорит, всё было нормально, а тут отошёл чайку попить, экран заблокировал, а обратно не попасть.. При мне попробовал перенабрать пароль несколько раз, в натуре, не работает. Ну я первым делом проверил CapsLock, не, не оно.

— Почта из скрипта не доходит в список рассылки (в гуглопочте). А очень надо. Отдельным получателям нормально доходит, а в рассылку гугл письма принимает, после чего они куда-то исчезают. Как мне раньше рекомендовали, добавил в адрес отправляющего сервера в гугловый whitelist, никакого эффекта. Попробовал руками послать, та же картина, мне самому пришло, а в рассылку — фиг.

— В одном из датацентров внезапно отвалились все VPN-туннели. Зашёл на тамошний роутер, попробовал перезапустить их руками, фиг. Почитал логи, говорит, phase1 по таймауту отваливается. Зашёл на остальные роутеры, куда он должен присоединяться, стал проверять живость интернетов [tcp]traceroute’ом, так они ни туда, ни обратно не доходят, отваливаются где-то посредине. Но при этом я-то в тот роутер зашёл, сначала по https, потом по ssh, никаких проблем. Попробовал telnet’ом – во все стороны работает. А IPSec никак. А лично сходить посмотреть, что у него может быть не так с сетью, не получится. Он в Южной Африке..

– После перезагрузки proxmox’а в нём померла виртуальная машинка. А она нужная, там firewall для гостевого wifi. Нажимаю кнопочку start, машинка вроде как started, но через пару секунд опять stopped. И заглянуть некуда, консоль так быстро запуститься не успевает. В логах самого proxmox’а никаких подробностей, только длиннющая команда, которой он пытался запустить эту виртуалку, и в конце “failed: exit code 1″. А чё конкретно там failed, поди угадай..

Ну, в общем, я это всё починил, но столько граблей за какие-то полдня — это как-то ненормально.

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

Задача для продвинутых сисадминов. Остальным вряд ли будет интересно.

( Read the rest of this entry » )

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

# netstat -npa
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:32768           0.0.0.0:*               LISTEN     -                   
tcp        0      0 0.0.0.0:2049            0.0.0.0:*               LISTEN     -           
udp        0      0 0.0.0.0:32768           0.0.0.0:*                          -                   
udp        0      0 0.0.0.0:2049            0.0.0.0:*                          -        


# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
VPN-концентратор  192.168.0.1     255.255.255.255 UGH    1500 0          0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
66.150.15.0     0.0.0.0         255.255.255.0   U         0 0          0 tun0
сеть-на-работу  0.0.0.0         255.255.224.0   U         0 0          0 tun0
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0

Upd: первая половина - это паранойя. Так в линуксе, оказывается, выглядит ядрёный nfs.
2049 - это сам nfs, а 32768 - nlockmgr

Но вот откуда взялся лишний маршрут в VPN?
Upd 2: это я его, оказывается, сам вписал в конфигурацию vpn-клиента. Осталось вспомнить, когда и зачем..
Доктор, это лечится?