У меня gentoo и тор показывает то же самое, что и на скрине. hide.me из Нидерландов показывает то же, что и на скрине.
Возможно, браузер под windows и телефон сохранили старую версию.
Еще, быть может, сайт не трокали, а сменили DNS-запись.
host xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai выдает:
xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai has address 151.248.112.54
xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai has IPv6 address 2a00:f940:2:1:2::32
xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai mail is handled by 20 mail.xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai.
xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai mail is handled by 10 mail.xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai.
Что именно не поняли?
dd копирует содержимое входного файла в выходной. Копирование (чтение и запись) происходит блоками, размер блока устанавливается параметром bs. dd может пропускать несколько блоков в входном файле, количество задается параметром skip.
dd if=/dev/sdX of=/path/to/fileN bs=1M count=1450 skip=M
N -- номер файла, от 0
M = 1450 * N
Можете попробовать это автоматизировать:
for i in $(seq 0 13); do echo dd if=/dev/sdX of="/path/to/file${i}" bs=1M count=1450 skip=$((i * 1450)); done
Если устроит, уберете echo.
man dd
bs -- это block size в байтах, K = 1024, M = 1024 K, по умолчанию bs=512 (байтов)
skip -- количество блоков, которые пропустить на входе
seek -- количество блоков, которое пропустить на выходе
Ядро не будет загружаться с root=UUID=... без initramfs. Именнт в initramfs встраивают код для поиска файловой системы по UUID файловой системы.
Ядро понимает два значения для параметра root: путь к устройству (/dev/sdX, /dev/sdXn, /dev/mmcblk*, ...) и PARTUUID=xxx (в случае, если диск размечен как GPT, то у каждого раздела есть собственный UUID, не совпадающий с UUID файловой системы).
Вы так и не описали стою систему. В простом случае -- да, достаточно параметра root. UUID может не работать без initramfs, PARTUUID может работать. Рекомендуется ro вместо rw,.
Спасибо, ipam я проглядел. Похоже, это наиболее работоспособный вариант.
В моем случае пришлось указать: subnet=192.168.0.0/24, gateway=192.168.0.2, а шлюз по-умолчанию через aux_addresses.
Минусом остается только необходимость ручного соединение получившегося моста с существующим сразу после отработки docker-compose up -d.
Что я пока не нашел -- будет ли на выходе broadcast bonding со второй стороны N*M дублей пакетов или нет. Судя по фразе "it simply broadcasts all traffic out both interfaces" -- нет, а к чему приведет размножение каждого RTP-пакета на несколько копий, я не знаю.
Интересно, что Вы подразумеваете под "вышвырнуть тоннели"? Два офиса, несколько обычных "домашних" провайдеров. Каждое подключение к провайдеру дает нам один статический внешний IP-адрес, на шлюзе NAT + VPN. L2 здесь только внутри тоннелей (т.е. тоннели типа tap, а не tun).
Кодек был G.722, стал G.711 (alaw) -- там всего 8 телефонов во втором офисе, хотя и постоянно занятые.
Да, OpenVPN на tap-интерфейсах. Проверяли на ipip туннелях -- OpenVPN проблем не вносит.
Добавлю, что ping -n -i 0.02 в течение длительного времени выдал следующую статистику:
74303 packets transmitted, 74302 received, 0% packet loss, time 1537223ms
rtt min/avg/max/mdev = 1.867/10.826/442.226/12.490 ms
Возможно, браузер под windows и телефон сохранили старую версию.
Еще, быть может, сайт не трокали, а сменили DNS-запись.
host xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai выдает:
xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai has address 151.248.112.54
xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai has IPv6 address 2a00:f940:2:1:2::32
xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai mail is handled by 20 mail.xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai.
xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai mail is handled by 10 mail.xn--80aaaseifpbhscigao1cf1o7a0c.xn--p1ai.