Сегодня опять настраивал 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 используется, так что есть шанс получить те же (или даже ещё более кривые) грабли.
Оригинал этой записи в личном блоге.
no subject
no subject
no subject
>Все изменения в xml руками вписывать не сильно просто
Вот же блин, даже упёртые противники IDE, AKA фанаты vim, имеют плагины для этого.