Лог жизни

Архивы рубрики ‘Linux’

# update-crypto-policies --set LEGACY

Возможные варианты:

DEFAULT

The default system-wide cryptographic policy level offers secure settings for current threat models. It allows the TLS 1.2 and 1.3 protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 2048 bits long.

LEGACY

This policy ensures maximum compatibility with Red Hat Enterprise Linux 5 and earlier; it is less secure due to an increased attack surface. In addition to the DEFAULT level algorithms and protocols, it includes support for the TLS 1.0 and 1.1 protocols. The algorithms DSA, 3DES, and RC4 are allowed, while RSA keys and Diffie-Hellman parameters are accepted if they are at least 1023 bits long.

FUTURE

A conservative security level that is believed to withstand any near-term future attacks. This level does not allow the use of SHA-1 in signature algorithms. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 3072 bits long.

FIPS

A policy level that conforms with the FIPS 140-2 requirements. This is used internally by the fips-mode-setup tool, which switches the RHEL system into FIPS mode.

Источник: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening

Использую Debian 8 и 9 для разных целей зачастую очень грязных в плане установки кучи пакетов и сборки чего-то кастомного и/или опасного/дырявого. В связи с чем есть два выхода:
1. lxc — когда надо управлять ресурсами и не позволять их выжрать все,
2. простой chroot — когда точно знаешь что делаешь.

Подготовка для chroot очень простая:
apt-get install debootstrap

Далее ставим нужную систему. Я ставлю такую же как на хосте. Вот сейчас это Debian 8:
debootstrap jessie /usr/local/jessie http://mirror.yandex.ru/debian

Создаём скрипт для монтирования и запуска чего-то нужного в этом chroot:
/usr/local/sbin/jessie.sh:

#!/bin/bash
cd /usr/local/jessie || exit
[ -z "`mount | grep /usr/local/jessie/proc`" ] && mount proc -t proc ./proc
[ -z "`mount | grep /usr/local/jessie/sys`" ] && mount sys -t sysfs ./sys
[ -z "`mount | grep /usr/local/jessie/dev`" ] && mount --bind /dev ./dev
[ -z "`mount | grep /usr/local/jessie/dev/pts`" ] && mount --bind /dev/pts ./dev/pts
chroot /usr/local/jessie /runme.sh


Теперь вешаем этот скрипт в crontab на хосте или запускаем вручную при старте хоста или вручную.

Озадачили меня немного этим https://vrm.mining-pool.ovh/index.php?page=gettingstarted
Под Debian нужно поставить следующее:
apt-get install git make automake g++ libcurl4-openssl-dev libssl-dev libjansson-dev libgmp-dev zlib1g-dev

git clone https://github.com/JayDDee/cpuminer-opt
git clone https://github.com/effectsToCause/veriumMiner
git clone https://github.com/fireworm71/veriumMiner fireworm

После этого уже можно build.sh запускать.
Параметр benchmark работает только в veriumMiner:
cpuminer -n 1048576 --benchmark
Если получается >3000, то можно вливаться и будет профит.

На текущий момент только один почтовик заявляет и выпускает хоть какие-то релизы с поддержкой SMTPUTF8 или RFC 6531. Это экспериментальные релизы Postfix 2.12.
Но даже при наличии поддержки в нём система доставки кириллической почты просто так не заработает. Поэтому запасаемся напильником.
Настраивать сервер будем под Debian 7. В моём случает он внутри VZ контейнера, а эксперименты проводились внутри LXC контейнера.
После создания контейнера сносим оттуда штатный почтовик, если он есть:

apt-get purge exim* sendmail* и пр.

Качаем последнюю версию Postfix 2.12 experimental release:

wget http://mirrors-ru.go-parts.com/postfix/source/experimental/postfix-2.12-20140905.tar.gz

Заранее создаём юзера и группу:

useradd postfix -s /bin/false
groupadd postdrop

Распаковываем:

tar -zxf postfix-2.12-20140905.tar.gz

Патчим src/smtpd/smtpd.c:

apt-get install patch
patch postfix-2.12-20140905/src/smtpd/smtpd.c smtpd.patch

где smtpd.patch имеет содержимое:

--- smtpd.c	2014-10-06 00:15:18.000000000 +0400
+++ smtpd.c.force.smtputf8	2014-10-07 15:36:21.352884670 +0400
@@ -2317,21 +2317,8 @@
 	return (-1);
     }
 
-    /*
-     * XXX The sender address comes first, but the optional SMTPUTF8
-     * parameter determines what address syntax is permitted. We must process
-     * this parameter early.
-     */
-    if (var_smtputf8_enable
-	&& (state->ehlo_discard_mask & EHLO_MASK_SMTPUTF8) == 0) {
-	for (narg = 3; narg < argc; narg++) {
-	    arg = argv[narg].strval;
-	    if (strcasecmp(arg, "SMTPUTF8") == 0) {	/* RFC 6531 */
-		smtputf8 = 1;
-		break;
-	    }
-	}
-    }
+    smtputf8 = 1;
+
     if (extract_addr(state, argv + 2, PERMIT_EMPTY_ADDR,
 		     var_strict_rfc821_env, smtputf8) != 0) {
 	state->error_mask |= MAIL_ERROR_PROTOCOL;

Нужно это для того, чтобы почтовые клиенты, которые на данный момент не готовы полностью к таким серверам, могли через них всё-таки почту отправлять.
Дело в том, что эта сборка Postfix для активации SMTPUTF8 режима должна на входе получить:

RCPT TO:< юзер@домен.рус> SMTPUTF8

Быстрая проверка показала, что даже почтовые клиенты заявившие о поддержке IDN почты не отправляют SMTPUTF8 в RCPT TO и тем самым создают себе проблемы с отправкой.

Готовимся к сборке:

apt-get install build-essential libdb-dev libicu-dev libssl-dev
apt-get install checkinstall
apt-get install rsyslog telnet

Заодно готовимся к использованию Dovecot в качестве средства авторизации:

apt-get install dovecot-imapd dovecot-pop3d

Собираем с поддержкой SASL и TLS:

cd postfix-2.12-20140905
make makefiles CCARGS='-DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\" -DUSE_TLS' AUXLIBS="-ldb -lnsl -lresolv -lssl"
make
make install

Теперь надо это всё настроить:
В /etc/dovecot/conf.d/10-master.conf правим сокет для авторизации (95 строка примерно):

  # Postfix smtp-auth
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }

В /etc/dovecot/conf.d/10-auth.conf (99 строка примерно) добавляем любимые способы авторизации, например:

auth_mechanisms = plain login

Перезапускаем:

/etc/init.d/dovecot restart

Должно заработать.

После правки конфиг Postfix /etc/postfix/main.cf получился такой:

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
myhostname = postfix.regtime.net
mydomain = postfix.regtime.net
inet_interfaces = all
unknown_local_recipient_reject_code = 550
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
home_mailbox = Mailbox
 
mail_spool_directory = /var/mail
  
debug_peer_level = 6
debugger_command =
	 PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
	 ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/local/man
sample_directory = /etc/postfix
readme_directory = no
inet_protocols = ipv4
meta_directory = /etc/postfix
shlib_directory = no

smtputf8_autodetect_classes = all
smtputf8_enable = yes

virtual_mailbox_domains = русскийдомен.рф
virtual_mailbox_base = /var/spool/mail
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

smtpd_sasl_type = dovecot
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

smtpd_tls_CAfile = /etc/ssl/certs/ca.pem
smtpd_tls_CApath = /etc/ssl/certs
smtpd_tls_cert_file = /etc/dovecot/dovecot.pem
smtpd_tls_key_file = /etc/dovecot/private/dovecot.pem
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache
smtpd_use_tls = yes

# Enable STARTTLS encryption 
smtp_use_tls = yes
smtp_tls_CAfile = /etc/ssl/certs/ca.pem
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
smtpd_tls_security_level = may

smtpd_tls_received_header = yes
smtpd_tls_loglevel = 1
smtpd_tls_auth_only = no
tls_random_source = dev:/dev/urandom

Настройка для довольно простого использования обычных системых mailbox’ов на одном кириллическом домене. Те кто разбирается в Postfix чуть более глубоко — может это легко перенастроить под более привычные ему варианты.

В /etc/postfix/virtual_mailbox пишем:

имя.фамилия@русскийдомен.рф  user1

где user1 — системный юзер, которого нужно добавить штатной командой:

useradd user1 -s /bin/false

А в /etc/postfix/uid_maps:

имя.фамилия@русскийдомен.рф  1000

где 1000 — это uid для user1.

Тут же становится понятно, что для авторизации будет использован классический ASCII логин user1 и пароль к нему. В качестве POP3/IMAP4/SMTP сервера postfix.regtime.net.

Преобразуем это в хэш:

postmap /etc/postfix/aliases
postmap /etc/postfix/virtual_mailbox
postmap /etc/postfix/uid_maps

Перечитываем конфиг или запускаем, перезапускаем Postfix:

postfix reload/stop/start

Проверяем:

# telnet localhost 25
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 postfix.regtime.net ESMTP Postfix
EHLO localhost
250-postfix.regtime.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8
quit
221 2.0.0 Bye
Connection closed by foreign host.

Теперь когда сервер умеет работать с кириллическими адресами настало время выбрать клиента.
Гарантировано работает Claws Mail начиная с версии 3.9.3.
Evolution 3.10.4 тоже справляется с этой задачей.
Есть специальный клиент — EAI-SMTPUTF8 v.2.0
Гарантированно не работает Mozilla Thunderbird.

Существует как минимум два самых известных способа пробросить порт через Linux машину.
1. iptables
2. ssh
Недавно начал использовать еще один очень просто вариант — xinetd.
Сначала поставим его: apt-get install xinetd
Теперь настраиваем произвольные порты, например:

service proxy7001
{
        disable = no
        type = UNLISTED
        socket_type = stream
        protocol = tcp
        wait = no
        bind = 127.0.0.1
        user = www-data
        redirect = 172.18.1.3 7001
        port = 7001
}

Что имеем? Локальный порт tcp 7001, который форвардится на сервер с IP 172.18.1.3 и порт 7001.

В некоторых случаях это проще и легче, чем iptables и ssh. Действуйте по ситуации. 😉

Были закуплены вот такие модули. На ds 1307. Годны для использования на Raspberry Pi B.
Подключаются довольно просто:
VCC — 5V, GND — 0, SCL — к GPIO 1, SDA — к GPIO 0.
Картинки для простоты понимания:

Далее на Raspberry делаем следующие:

# apt-get install i2c-tools
# modprobe i2c-bcm2708
# modprobe rtc-ds1307
# modprobe -r i2c-bcm2708
# i2cdetect 1
# echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
# hwclock -r

После чего должно появиться некое время и дата с подключенного модуля.
Если всё получилось, то оставляем это на постоянку:

# echo 'i2c-dev' >> /etc/modules
# echo 'rtc-ds1307' >> /etc/modules
# sed -i 's/blacklist i2c-bcm2708/#blacklist i2c-bcm2708/' /etc/modprobe.d/raspi-blacklist.conf

В /etc/rc.local добавляем перед exit следующее:

for bus in $(ls -d /sys/bus/i2c/devices/i2c-*);
do
  echo ds1307 0x68 >> $bus/new_device;
  if [ -e /dev/rtc0 ];
  then
    break; # RTC found, bail out of the loop
  else
    echo 0x68 >> $bus/delete_device
  fi
done
hwclock -s

Вот здесь описано как сделать iSCSI Quorum Disk для двухголового Proxmox’а, но на RH-based Linux, что довольно странно, т.к. сам Proxmox построен на Debian, хотя и с RedHat ядром.
Но у меня реально есть только Дебианы и там не везде есть LVM.
Итак…

dd if=/dev/zero of=/var/proxmox2quorumdisk bs=1024 count=100

И никакого lvm не надо.
Ставим сервер aka target.


apt-get install iscsitarget iscsitarget-dkms
echo "ISCSITARGET_ENABLE=true" > /etc/default/iscsitarget


В /etc/iet/ietd.conf пишем:


Target iqn.2013-02.tld.domain.host:p1qdisk.lun1
IncomingUser rquser rqpass
OutgoingUser
Lun 0 Path=/var/proxmox2quorumdisk,Type=fileio
Alias LUN1
MaxConnections 4


echo "iqn.2013-02.tld.domain.host:p1qdisk.lun1 IP1,IP2,IP3" > /etc/iet/initiators.allow


И… запускаем:

/etc/init.d/iscsitarget start

Теперь может возникнуть желание расшарить этот диск только с определенного IP. Статная обёртка в Debian этого не позволяет. Пропатчить можно так:

echo "ISCSITARGET_OPTIONS='--address=IP'" >> /etc/default/iscsitarget

И правим в /etc/init.d/iscsitarget в функции ietd_start строку:

start-stop-daemon --start --quiet --oknodo --exec $DAEMON -- $ISCSITARGET_OPTIONS

Перезапускаем:

/etc/init.d/iscsitarget restart

Теперь настроим клиента aka initiator.

apt-get install open-iscsi

Правим /etc/iscsi/iscsid.conf:

node.startup = automatic

/etc/init.d/open-iscsi restart

Подключаем диск:


iscsiadm -m discovery -t st -p IP
iscsiadm -m node

iscsiadm -m node --targetname "iqn.2013-02.tld.domain.host:p1qdisk.lun1" --portal "IP:3260" --op=update --name node.session.auth.authmethod --value=CHAP
iscsiadm -m node --targetname "iqn.2013-02.tld.domain.host:p1qdisk.lun1" --portal "IP:3260" --op=update --name node.session.auth.username --value=rquser
iscsiadm -m node --targetname "iqn.2013-02.tld.domain.host:p1qdisk.lun1" --portal "IP:3260" --op=update --name node.session.auth.password --value=rqpass
iscsiadm -m node --targetname "iqn.2013-02.tld.domain.host:p1qdisk.lun1" --portal "IP:3260" --login


По идее после этого должен появиться новый диск. У меня это /dev/sdc

Теперь на нём создадим Quorum Disk:

fdisk /dev/sdc

Далее создаём новый раздел: n, p, 1, w. Ну там для размера Enter понажимаем для подтверждения полного размера.

mkqdisk -c /dev/sdc1 -l p1qdisk

Перезагружаем клиентов на клиентах:

/etc/init.d/open-iscsi restart

А дальше по тексту оригинальной инструкции и всё сработает.

Сначала подготовим сервер. Я ставил это на Fedora 18 и Debian 7, на x86, amd64 и arm в исполнении Raspberry Pi. Разница только в способе установки пакетов.
Сначала инструменты для работы с sms через 3g/4g модемы Huawei, которые создают /dev/ttyUSB* устройства при подключении.

Huawei выбран потому что эти модемы работают очень стабильно в отличие от ZTE. Прочие производители не тестировались ввиду отсутствия в свободной продаже в Самаре.

При подключении 3G модема в USB должны появиться три устройства:


/dev/ttyUSB0
/dev/ttyUSB1
/dev/ttyUSB2


Обычно нулевое устройство — основное для передачи данных. Оно же занимается для подключения по GPRS и производным протоколам. Если модем не используется для этого, то 0 устройство можно использовать для SMS. А вот если используется, что для разных модемов для отправки SMS придётся подбирать экспериментальным путём либо 1 либо 2 устройство.

Приступим.

apt-get install gammu gammu-smsd

В связи с особенностью используемых мной шлюзов хранить всё это будем в /home/sms


mkdir -p /home/sms
cd /home/sms
rm -f /etc/gammu-smsdrc
ln -s /etc/gammu-smsdrc /home/sms/gammu-smsdrc


Конфиг /home/sms/gammu-smsdrc:


[smsd]
Service = files
PIN = 0000
LogFile = syslog
InboxPath = /home/sms/inbox/
OutboxPath = /home/sms/outbox/
SentSMSPath = /home/sms/sent/
ErrorSMSPath = /home/sms/error/

debuglevel = 1
logfile = /home/sms/smsd.log

[gammu]
port = /dev/ttyUSB0
model = at
connection = at19200
synchronizetime = yes
logfile = /home/sms/gammu.log
logformat = textalldate
use_locking = yes
;gammuloc =
;gammucoding = utf8


Файл запуска/перезапуска сервиса /home/sms/restart:


#!/bin/bash

killall -q gammu-smsd && sleep 10

cd /home/sms
>smsd.log
touch smrsh.log
chmod 1660 smsd.log smrsh.log
mkdir -p error inbox outbox sent
chmod 1770 error inbox outbox sent
chgrp mail smsd.log smrsh.log error inbox outbox sent

gammu-smsd -c /home/sms/gammu-smsdrc -d


С учётом того под каким юзером будем запускать этого домена нужно сделать:

chown -R user:group /home/sms

Нужно учесть, что юзер должен принадлежать группе, которая может писать в /dev/ttyUSB0.

Ну и запускаем:

/home/sms/start

Для автоматического запуска в /etc/rc.local вписываем эту же команду.

Проверить работу можно так, заменив телефон на свой:

gammu-smsd-inject -c gammu-smsdrc TEXT "+79020000000" -textutf8 "дата/date `date`" -unicode

Теперь создаём отдельный поддомен для отправки sms через e-mail. В sendmail добавляем его в /etc/mail/local-host-names и прописываем в virtusertable:

@subdomain.domain.tld smsg

а в aliases:

smsg: "|/etc/mail/smrsh/smsg"

smsg может выглядеть так:

#!/bin/bash

LOG=/tmp/smsg
BF=''
SMS=''
MOB=''

date >> $LOG
set >> $LOG
env >> $LOG

while read L; do
    echo $L >> $LOG
    if [ -z "$L" ]; then
        BF=1
        continue
    fi
    if [ -z "$BF" ]; then
        if [ "${L:0:4}" == "To: " ]; then
            TO=${L:4}
            TO=${TO# *}
            TO=${TO%@*}
            if [ ${#TO} != 10 ] || [ "${TO:0:1}" != "9" ]; then
                echo "BAD TO" >> $LOG
                exit 403
            fi
            MOB="+7"$TO
        fi
    else
        if [ -z "$SMS" ]; then
            SMS=$L
        else
            SMS=$SMS$'\n'$L
        fi
    fi
done

if [ -n "$MOB" ] && [ -n "$SMS" ]; then
    echo "--- SMS ---" >> $LOG
    echo "$MOB" >> $LOG
    echo "$SMS" >> $LOG
    echo "=== === ===" >> $LOG
    gammu-smsd-inject -c /home/sms/gammu-smsdrc TEXT "$MOB" -textutf8 "$SMS" -unicode -len 319  1>>$LOG 2>&1
fi

На днях обновился до Fedora 20.
Сам процесс прошел по банальному сценарию:

export LANG=C
rpm --import https://fedoraproject.org/static/246110C1.txt
yum update yum
yum --releasever=20 distro-sync

Всё прошло без сучка и задоринки. Перезагрузился тоже без проблем.
А вот со входом в систему случилось странное. По привычке ввёл пароль и попал… в Gnome 3, которым не пользуюсь вообще. Да и не было его на моём ноуте до этого. А теперь аж три гуя на выбор: Gnome, MATE, Xfce. После перевхода с принудительным выбором Xfce стало привычно. Но чего-то не хватало, а именно bluetooth аплета. А у меня наушники беспроводные.

Смотрим чего натворил yum:

Jan 28 21:12:34 Erased: PackageKit-device-rebind-0.8.9-6.fc19.x86_64

Jan 28 21:12:40 Erased: mate-bluetooth-libs-1.6.0-5.fc19.x86_64
Jan 28 21:12:40 Erased: mate-bluetooth-1.6.0-5.fc19.x86_64

Jan 28 21:12:42 Erased: gvfs-obexftp-1.16.3-2.fc19.x86_64
Jan 28 21:12:43 Erased: 1:obex-data-server-0.4.6-5.fc19.x86_64
Jan 28 21:13:21 Erased: jpackage-utils-1.7.5-27.fc19.noarch
Jan 28 21:13:30 Erased: systemd-sysv-204-18.fc19.x86_64
Jan 28 21:13:44 Erased: xfce4-icon-theme-4.4.3-8.fc19.noarch

Читаем release note (http://docs.fedoraproject.org/en-US/Fedora/20/html/Release_Notes/sect-Release_Notes-Changes_for_Desktop.html), охреневаем, думаем, чешемся, пробуем замену (yum install -bluedevil),
охреневаем еще больше:

Установить  2 пакета (+33 зависимых)

Объем загрузки: 83 M
Объем изменений: 182 M

Плюём и пользуем консоль:

$ /usr/bin/bluetoothctl
[NEW] Controller C4:85:08:46:3C:E5 ssg-0 [default]
[NEW] Device 00:60:D1:00:55:30 Bluetooth Mouse
[NEW] Device 76:8E:46:66:20:4C ANDROID BT
[NEW] Device 98:6C:F5:7E:6A:5E ZTE_LEO_Q1
[NEW] Device 2C:26:C5:DB:63:87 ZTE V880E
[NEW] Device 00:0D:FD:35:CD:14 Motorola S305
[NEW] Device 00:60:D1:00:17:AA Bluetooth Mouse
[bluetooth]# agent on
Agent registered
[bluetooth]# connect 00:0D:FD:35:CD:14
Attempting to connect to 00:0D:FD:35:CD:14
[CHG] Device 00:0D:FD:35:CD:14 Connected: yes
Connection successful
[bluetooth]# quit

Всё. Наушники работают.

Иногда можно получить ошибку:

Failed to connect: org.bluez.Error.NotReady

Лечится так:

hciconfig hci0 up

Минувшие выходные прошли под флагом борьбы за свой оплаченный интернет.
Сначала (в пятницу) соединения начали рваться, а потом вообще пропал всходящий трафик. В общем, под выходные спецы на той стороне что-то намутили.

Проблема номер раз.
Выдают белый внешний IP в стандартной PPPoE сессии. При этом все соединения наружу идут с другого IP. Первым сломался DynDNS. Сначала подумал, что проксируют. Перенастроил соединение добавив в /etc/ppp/peer/rt.fttb строку:
unit 35
Это дало постоянное имя интерфейса ppp35 для этого соединения (у меня несколько внешних pppoe). Затем исправил /etc/ddclient.conf:
use=if, if=ppp35
Технически всё заработало, но по ssh внутрь всё равно снаружи попасть было нельзя — трафик не шел. Справедливости ради стоит заметить, что внутри Ростелекома соединения на этот белый IP шли на ура.
Поскольку аналогичная конфигурация в другой точке города работала по иному, то тщательно сравнил и нашел разницу. Оказалось дело в диапазонах белых IP адресов, которые выдавались.
Оказалось, что на каждой точке есть две железки, которые дают инет:

# pppoe-discovery -I eth1
Access-Concentrator: MX960-1
Got a cookie: 85 3d c1 4b 07 46 95 f6 3c 64 72 08 ab cd 4b f2
--------------------------------------------------
AC-Ethernet-Address: 00:25:9e:80:b5:07
Access-Concentrator: MX960-2
Got a cookie: 85 3d c1 4b 07 46 95 f6 3c 64 72 08 ab cd 4b f2
--------------------------------------------------
AC-Ethernet-Address: 00:25:9e:80:b6:08

Опытным путём выяснилось, что MX960-1 выдаёт нормальные белые адреса, а MX960-2 — недоступные.
Пишем в /etc/ppp/peers/rt.fttb:
plugin rp-pppoe.so rp_pppoe_ac 'MX960-1' eth1
и получаем всегда то что нам надо. Разумеется пока эта самая железка будет доступна. Если она пропадёт, то инета не будет вообще никакого.

Проблема номер два.
Часть сайтов стала недоступна. Закономерностей нет. Протокол значения не имеет. Даже ssh сессии начали рваться. Первая же мысль, которую я почему-то быстро отогнал, была верной — MTU.
Странно, что не провелась параллель между первой проблемой и этой.
Но в результате она решилась очень даже тривиально (хоть и с подсказки):
iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Не ожидал такого через два-то с половиной года довольно стабильной работы…