Т.е. второй подсети IPv6 нет? Она вообще-то нужна, чтобы через адрес из нее проходил маршрут к подсети для клиентов. В примере выше про IPv4 использование этого адреса еще и как для входящих соединений VPN-сервера — это совпадение.
Без нее можно выкрутиться, но будет очень костыльно. Гуглить в сторону odhcpd из OpenWRT.
У организации есть большая подсеть белых адресов (скажем, 192.0.2.0/24) для раздачи клиентам. Еще нужен один белый адрес (скажем, 198.51.100.2) из другой подсети.
Вешаем на сервер на eth0 адрес 198.51.100.2. На вышестоящем маршрутизаторе прописываем маршрут до 192.0.2.0/24 через 198.51.100.2, и распространяем его (через BGP) по всему интернету. Или это сделает за нас вышестоящий провайдер.
На сервере делаем --dev tun --topology subnet. На tap0 при этом OpenVPN повесит адрес 192.0.2.1/24 и будет выдавать IP из этой подсети клиентам.
Клиентам говорим, чтобы подсоединялись к 198.51.100.2.
Пользователь купил SIM-карту DataSIM от LeFrenchMobile и поехал с ней в Финляндию (что не является надуманным примером — роуминг дешевый по всей Европе). Итог: IP определяется как французский, NAT делается во Франции, ping отличается (из-за сотового соединения), временная зона отличается на один час. Т.е. два пункта, по которым можно сделать вывод о наличии средств анонимизации, есть.
Но вопрос, является ли SIM-ка в роуминге средством анонимизации, для меня не является однозначным. Но это точно не VPN и не прокси.
Рассматриваем для определенности случай, когда пользователь в России, VPN-провайдер в Финляндии, а проверялка в Швеции.
Случай 1: провайдер NAT'ит. Те выдает клиенту «серый» адрес. В этом случае пинги от проверялки до видимого внешнего адреса пользователя идут из Швеции в Финляндию, т.е. близко, а запрос пустой страницы от пользователя идет из России через Финляндию в Швецию, т.е. далеко. Проверка срабатывает.
Случай 2: провайдер дает клиенту белый IP. В этом случае пинги от проверялки до этого IP идут пользователю — т.е. из Швеции через Финляндию на «финский» IP в Россию. Запрос пустой страницы идет, как и раньше, из России через Финляндию в Швецию, т.е. точно так же далеко. Проверялка утверждает, что VPN по критерию с пингом обнаружить не удалось.
Проблема «очень умного и потому опасного» ИИ является на 100% надуманной и никогда не будет актуальной. Но уже сейчас актуальна проблема промышленного саботажа. Не обязательно создавать ИИ умнее человека, достаточно внедрить закладку.
А еще раньше была актуальна проблема вражеской пропаганды, действующей на человека и мотивирующей вредить.
Работает, но не во всех сетях. Сертификат вместе со всей цепочкой должен влезть в один UDP-пакет. С классическими сертификатами RSA-2048 от общепризнанных удостоверяющих центров, запросто получается UDP-пакет на 5 килобайт, т.е. требуется фрагментация. А некоторые провайдеры режут все фрагменты, чтобы защитить свою сеть от DoS атак. ECDSA-256 от общепризнанных удостоверяющих центров тоже не пролезает (1.8 килобайта), как, впрочем, и самоподписанный RSA-2048 без цепочки. Т.е. единственный невзламываемый вид сертификата, с которым можно избежать необходимости фрагментировать UDP-пакеты на стадии IKE_AUTH — это самоподписанный ECDSA-256.
Да, есть расширение для фрагментации на уровне UDP (RFC 7383), но оно очень свежее и не поддерживается в Windows.
Обязательно! Включите опцию «Блокировать неизвестные сайты» (в особых настройках на странице Фильтр), чтобы блокировать все сайты неизвестные для сервиса SkyDNS и не попасть на только появившийся сайт с неподходящим контентом.
Обязательно! Включите опцию «Использовать безопасный поиск». В этом случае все запросы к поисковым системам будут перенаправляться на безопасный поиск SkyDNS – poisk.skydns.ru
Собственно — как у автора вообще получилось поискать что-то в Google?
В Вашем случае, автомат опорной частоты работает (больная тема в Windows для аналогичных решений через WDM->ASIO)?
Нет. JACK работает с фиксированной (задаваемой при запуске) частотой дискретизации. Ну и этот автомат все равно не имел бы смысла, так как тогда бы было необходимо иметь (или генерировать на лету тем же ресемплингом) отдельный фильтр для каждой частоты дискретизации. С ресемплингом фильтра мы получили бы искажения того же толка, что и с ресемплингом фильтруемого звука, т.е. овчинка не стоит выделки.
P.S. ресивера у меня действительно нет, есть интегральный усилитель Rotel RA-1570.
Цель — передать звук из PulseAudio в BruteFir (поскольку другой программы для свертки звука с FIR-фильтром нет). BruteFir умеет только быть либо JACK-клиентом, либо записывать со звуковой карты, либо читать из файла. Поэтому JACK оказался наименее затратным способом выполнить стыковку этих программ.
А вот ответ на вопрос про преобразование количества бит средствами ALSA: использовать имя устройства, начинающееся с «plughw:». Например, plughw:1
Ну и на самом деле тест с таким дорогим оборудованием можно было не проводить. Любая карта, которая успешно пропускает AC3 или DTS на ресивер, является по определению BitPerfect — а ресивер у пользователя, который задается таким вопросом, скорее всего, есть.
Сам вопрос про BitPerfect считаю академическим. Мое личное мнение: он нужен только для пропуска AC3 и DTS на ресивер. Я все равно пропускаю весь звук через фильтр (цепочка: pulseaudio -> jack -> brutefir -> alsa), чтобы частично скомпенсировать объективные акустические недостатки комнаты, и вам того же буду советовать, когда появится «родная» поддержка в PulseAudio (если нет такой же функции в ресивере). Фильтр построен с помощью измерительного микрофона и drc-fir.sourceforge.net/doc/drc.html
Т.е. выходит, что Oracle «просто работает» на облачных серверах, и никакого тюнинга «дисковой» подсистемы не требуется? Или такой тюнинг уже сделан перед тем, как облачный сервер передается заказчику?
Занимаюсь электроникой, но метастабильность у меня больше ассоциировалась с приемом внешних аналоговых сигналов, и поэтому для меня странно, что в статье не упоминается триггер Шмитта, который по идее надо бы поставить перед D-входом первого тактируемого триггера.
Без нее можно выкрутиться, но будет очень костыльно. Гуглить в сторону odhcpd из OpenWRT.
У организации есть большая подсеть белых адресов (скажем, 192.0.2.0/24) для раздачи клиентам. Еще нужен один белый адрес (скажем, 198.51.100.2) из другой подсети.
Вешаем на сервер на eth0 адрес 198.51.100.2. На вышестоящем маршрутизаторе прописываем маршрут до 192.0.2.0/24 через 198.51.100.2, и распространяем его (через BGP) по всему интернету. Или это сделает за нас вышестоящий провайдер.
На сервере делаем --dev tun --topology subnet. На tap0 при этом OpenVPN повесит адрес 192.0.2.1/24 и будет выдавать IP из этой подсети клиентам.
Клиентам говорим, чтобы подсоединялись к 198.51.100.2.
Все!
Пользователь купил SIM-карту DataSIM от LeFrenchMobile и поехал с ней в Финляндию (что не является надуманным примером — роуминг дешевый по всей Европе). Итог: IP определяется как французский, NAT делается во Франции, ping отличается (из-за сотового соединения), временная зона отличается на один час. Т.е. два пункта, по которым можно сделать вывод о наличии средств анонимизации, есть.
Но вопрос, является ли SIM-ка в роуминге средством анонимизации, для меня не является однозначным. Но это точно не VPN и не прокси.
Рассматриваем для определенности случай, когда пользователь в России, VPN-провайдер в Финляндии, а проверялка в Швеции.
Случай 1: провайдер NAT'ит. Те выдает клиенту «серый» адрес. В этом случае пинги от проверялки до видимого внешнего адреса пользователя идут из Швеции в Финляндию, т.е. близко, а запрос пустой страницы от пользователя идет из России через Финляндию в Швецию, т.е. далеко. Проверка срабатывает.
Случай 2: провайдер дает клиенту белый IP. В этом случае пинги от проверялки до этого IP идут пользователю — т.е. из Швеции через Финляндию на «финский» IP в Россию. Запрос пустой страницы идет, как и раньше, из России через Финляндию в Швецию, т.е. точно так же далеко. Проверялка утверждает, что VPN по критерию с пингом обнаружить не удалось.
А еще раньше была актуальна проблема вражеской пропаганды, действующей на человека и мотивирующей вредить.
Да, есть расширение для фрагментации на уровне UDP (RFC 7383), но оно очень свежее и не поддерживается в Windows.
Собственно — как у автора вообще получилось поискать что-то в Google?
и вперед.
Нет. JACK работает с фиксированной (задаваемой при запуске) частотой дискретизации. Ну и этот автомат все равно не имел бы смысла, так как тогда бы было необходимо иметь (или генерировать на лету тем же ресемплингом) отдельный фильтр для каждой частоты дискретизации. С ресемплингом фильтра мы получили бы искажения того же толка, что и с ресемплингом фильтруемого звука, т.е. овчинка не стоит выделки.
P.S. ресивера у меня действительно нет, есть интегральный усилитель Rotel RA-1570.
Ну и на самом деле тест с таким дорогим оборудованием можно было не проводить. Любая карта, которая успешно пропускает AC3 или DTS на ресивер, является по определению BitPerfect — а ресивер у пользователя, который задается таким вопросом, скорее всего, есть.
Сам вопрос про BitPerfect считаю академическим. Мое личное мнение: он нужен только для пропуска AC3 и DTS на ресивер. Я все равно пропускаю весь звук через фильтр (цепочка: pulseaudio -> jack -> brutefir -> alsa), чтобы частично скомпенсировать объективные акустические недостатки комнаты, и вам того же буду советовать, когда появится «родная» поддержка в PulseAudio (если нет такой же функции в ресивере). Фильтр построен с помощью измерительного микрофона и drc-fir.sourceforge.net/doc/drc.html