Это уже не просто блин, а вовсе бл***!

Сегодня опять настраивал 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 используется, так что есть шанс получить те же (или даже ещё более кривые) грабли.


You can read this post at LiveJournal.
This entry was posted in Uncategorized and tagged , , , , , . Bookmark the permalink.

Leave a Reply