Вниматнельнее надо читать статью и комментарии, тогда и не будет таких глупых вопросов.
Пока вижу лишь унылые нападки в ответ, а не рассказ "как надо" с детальным описанием механик работы той или иной схемы )
Вот что не работает
NAT-соединение с хранением состояния, соответствующее внутреннему клиенту, отсутствует
Вполне себе возможная ситуация по нескольким причинам:
NAT рандомизирует номер src порта или этот же номер уже используется другим устройством(т.е. гарантировать что это будет работать в сети со множеством устройств, прямо скажем сложно). Уже упоминал это выше.
Если в качестве Алисы выступает не конечный абонент, а АТС и вызов в состоянии Session Progress (проигрывается приветствие без интерактивного IVR) - RTP-поток будет только в одну сторону, и в таком случае он гарантировано не пройдёт NAT до момента коммутации, когда активируется ответный RTP-поток.
Как называется NAT вообще не играет ни какой роли в контексте утверждения/ответа потому что ВСЕ основные типы NAT так делают.
Опять же, только при условии что:
NAT НЕ рандомизирует номер src порта или этот же номер уже НЕ используется другим устройством.
Гарантировать что у произвольного абонента и то, и другое не встретиться - нереально.
Второй абонент сам не находиться за NAT.
В этом случае проблема значительно усугубляется для обоих сторон.
Без активных механизмов определения источника RTP-потока абонентов на стороне АТС, или ухищрений в виде SIP-ALG или доп.настроек на уровне маршрутизатора каждого из абонентов - магии не случится.
Спорить о том какой тип NAT считается самым массовым в отсутствии статистики считаю бессмысленным
Но только зачем-то сами это изначально и утверждали, но да ладно.
за все это время я не видел ни одного случая когда такой сценарий работал
Что не работает? 1:1 маппинг для для клиентского устройства?
Закрепление диапазона портов за каждый из клиентских устройств(при условии, что NAT сохраняет номер src порта при трансляции и противоположенная сторона использует IP не из SDP, а src IP из SIP-пакета инициатор вызова)?
Даже SIP-ALG может работать нормально в отдельно взятом случае(если не используется TLS/WSS).
Методы упомянутые в статье вполне рабочие, но важные детали, при которых это будет работать, опущены.
Проблемы работы через NAT довольно поверхностно описаны в статье, это факт.
Из-за этого последнее утверждение, описывающее проблему пропуска RTP от Алисы, в одних условиях будет верным(если NAT по умолчанию рандомизирует порты при трансляции, либо если данный порт уже используется другим устройством), а в других не верным(NAT сохраняет исходный номер src порта и смог это сделать - порт ещё не используется другим устройством).
Это вопрос конкретных условий, в которых работает АТС и её абоненты, а не Silver Bullet решения.
Помимо NAT'ов сильно разнятся возможности как клиентских устройств, так и самой АТС относительно решения проблем работы через NAT.
Если RTP проксируется АТС(что необходимо для записи разговоров), и АТС имеет механизм определения источника RTP-потока на объявленный с её стороны IP:Port - проблема решается малой кровью, без необходимости задействовать STUN или SIP-ALG на клиентской стороне(или иных настроек на маршрутизаторе).
для тролля главное это начать придиратся к комментариям
Т.е. как раз то, чем вы сейчас занимаетесь - пытаетесь найти в моём тексте какие-то "ошибки/нестыковки", отводя внимание от исходной претензии к вашему высказыванию по поводу Symmetric NAT.
Классика демагога : )
Вы лучше копируйте wiki
Вы лучше читайте о чём речь, а то я вижу наличие ссылок на wiki триггерит у вас "он всё из wiki натаскал", что весьма потешно выглядит. Ссылки на wiki даны для тех, кто не знаком с обозначенными механизмами и кому будет интересно об этом почитать.
И под "достаточной надёжностью" подразумевается стабильность работы канала связи между SIP-сервером и SIP-клиентом через агрессивный провайдерский NAT.
Но вы в этом усмотрели лишь возможность для контратаки в мою сторону )
И вы так и не ответили
Так вы этот вопрос выше и не задавали.
Для RTP не применимо. Пример был приведён для сигнального(SIP) трафика в контексте режима работы NAT, который я оспорил в первом сообщении, и комментировать который вы так упорно избегаете.
на борльшинстве раутеров независимо от того как его назвать.
Т.е. вы уже и не настаиваете, что "на большинстве" именно Symmetric NAT ? ; )
описанный в статье сценарий совершенно неверный и не работает
Приведёте пример почему он не верный и почему не будет работать?
А то пока складывается впечатление, что "я видел что оно и так работает, а вы тут все дураки", что довольно слабый аргумент.
При том, что это равноценный элемент проблемы с NAT в работе SIP, как и проблема с (не)прохождением RTP, а также как иллюстрация к тому, почему устройства работают находясь за Port Restricted Cone NAT.
А вы так и не ответили, где это вы Symmetric NAT нашли на "большинстве встроенных в роутеры NAT" ; )
Большинство встроенных в роутеры NAT это Symmetric NAT который открывает канал в ОБЕ стороны и поэтому если послать на исходный адрес и порт, то пакет дойдет до адресата с внутренним адресом и все будет работать.
Что вы несёте?.. Большинство NAT - это Port Restricted Cone NAT. А доступность SIP-устройств для входящих вызовов обеспечивается одним из следующих механизмов: а) Банальный Keep-Alive - частая(10-30 сек) отправка "пустых(\r\n)" или SIP-пакетов типа OPTIONS или NOTIFY SIP-клиентом на SIP-сервер.
(Почти) схожий эффект может достигаться очень частой(каждые 60 секунд) перерегистрацией SIP-клиента, но на очень агрессивных CG-NAT(Carrier-grade NAT) это вряд ли прокатит. Это не может являться заменой KA и в целом порочная/не эффективная практика(тем более для "стационарных" SIP-клиентов). Обязательно для транспорта UDP. Менее критично(при условии нахождения НЕ за CG-NAT) для TCP(и соответственно TLS/WSS). Для TCP может использовать(как со стороны клиента, так и сервера) нативный TCP Keep-Alive механизм, но тут многое зависит от связки сервер <> NAT <> клиент.
б) Алгоритмы SIP-ALG(названия могут варьировать или быть просто в виде отдельной группы спец-правил), которые при детектировании SIP-взаимодействия через маршрутизатор, динамически создают правило для поддержания открытого состояния выделенного на уровне NAT порта, даже если со стороны клиента нет KA и используется UDP в качестве транспорта для SIP.
Так как никакого стандарта(насколько я знаю) не существует на реализацию SIP-ALG, все характеристики его работы произвольны и весьма часто такие решения нестабильны/функционируют некорректно, что нередко создаёт проблемы в работе тех АТС/серверных решений, которые могут без перезаписи значений(IP:Port) в SIP-заголовках клиентом(используя STUN) или маршрутизатором(SIP-ALG) корректно определять контакт(IP:Port) для сигнального(SIP) и медиа(RTP) трафика.
Очень часто SIP-ALG - это чёрный ящик, поэтому если есть иные средства для организации корректного взаимодействия между сервером и клиентом - следует отказаться от SIP-ALG. Это вывод из многолетней личной практики(не операторского, конечно, уровня, но коммерческой эксплуатации).
в) Использование Stateful протокола транспортного уровня(т.е. TCP). Но как уже упомянуло в пункте а), домашние провайдеры со своим CG-NAT плевать хотели на это, и могут также агрессивно выпилить вашу TCP-сессию через 30 секунд простоя. Поэтому если вы полностью не контролирует весь маршрут внутри сети до выходной точки в Интернет, то полагаться на это невозможно.
Поэтому лишь Keep-Alive может обеспечить достаточную надёжность "обратного канала" для обычных потребителей.
Проблема в том, что мобильный трафик намного "усердней" блокируют. Да и самих мобильных операторов всего ничего, в отличии от стационарной связи. Отсюда и проще контролировать/влиять со стороны ломателей Интернета.
но для себя не вижу смысла платить за сервис, который не противостоит блокировкам
Усилия по противостоянию блокировкам - это весьма зыбкий критерий. Как определить, это сервис "хорошо старается" или Г-сударство "плохо старается"?
Если подходить с максимально потребительской точки зрения: "должно работать само по себе и шоп я не думал", то объективной оценки точно не выйдет.
В текущих условиях в РФ, простым пользователям более перспективно ориентироваться не на готовые сервисы, а разворачивать собственные VPN-серверы на основе одного из заточенных на задачу маскировки протоколов.
Если речь исключительно про бесплатный план ProtonVPN, то тут ещё больше "но". Хотя бы из-за банального ограничения регионов подключения и количества серверов под пользователей бесплатного плана. В таком ключе обобщать "user experience" по всему сервису не вижу смысла.
Они конечно большие молодцы, что предоставляют и бесплатный доступ, но судить о качестве/надёжности всего сервиса лишь по бесплатному плану не стоит.
а сейчас работает только Stealth с долгим подключением до пары минут.
О каких сетях/провайдерах/регионах идёт речь? Если на мобильных, то это вполне возможно, так как на них обычно намного сильнее ограничения по видам "допустимого" трафика.
В Android клиенте к тому же, уже давно нет IPsec, хотя я не знаю насколько агрессивно его сейчас блокируют в целом.
В то же время на стационарных сетях, как я уже упоминал выше, как минимум на части провайдеров/регионов, IPsec работает годами без смены площадок и/или IP-адресов на стороней ProtonVPN.
Где-то полгода назад пытался таким образом обойти блокировку стандартного WG на мобильной сети(Билайн и МТС, вроде бы проверялись) до RouterOS на VPS в Казахстане. Насколько помню, собирая трафик, поведение немного различалось(по отношению к порту из динамического диапазона) по тому какое количество пакетов успевало пройти в процессе(после) хендшейка, но итог был неутешительным.
Дампы вряд ли уже найду, да и ситуация могла уже 10 раз поменяться за это время. Но это очень "топорный" способ, и сомнительно, что ТСПУ будет слепо вайтлистить UDP 443 из-за того что там ходит QUIC. Учитывая, что QUIC тоже может легко уйти в бан по велению пятки строителей сувенирного Интернета ; )
Вероятно сильно зависит от сочетания провайдера и протокола, так как я оплачиваю сервис с 2018 года и серьёзных проблем практически никогда не наблюдал при использовании через IPsec(IKE2), настроенном на маршрутизаторе(RouterOS) через домашний МТС GPON. Около 4 туннелей в разные локации постоянно работают, но работу из других сетей я не проверял, так как с других устройств я просто строю WireGuard-туннель до своего маршрутизатора, а дальше разруливается правилами куда направлять.
Некоторые друзья жаловались на проблемы с подключением к ProtonVPN через мобильные сети(при использовании любых доступных протоколов, в том числе и Stealth). После этого я просто раскидал им гостевые WireGuard конфиги до моего маршрутизатора - на том проблемы и решились.
Также без проблем функционирует(IPsec) из рабочей сети(собственная AS-ка) с транзитом через ЭР-Телеком.
Не только OpenVPN, но и IPsec и WireGuard. Впрочем это не меняет картины для господина, поднявшего вопрос. "В один клик" и "без доп. софта", увы, не бывает. Но вполне решается любым Mikrotik'ом + гайд из Интернета.
RMS ответил на отправленное мной письмо в FSF и попросил не писать на directors@fsf.org, только на info@fsf.org:
Thank you for supporting me with the FSF.
You can give me more support by joining the FSF as an
associate member. I hope you will do that.
Another thing that will help me is to post on public forums in support.
You can also encourage other people to do all these things. But they should write only to info@fsf.org, not to directors@fsf.org.
The directors have got piles of mail already, and there is no need to add
to the piles.
Thank you.
— Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Какая-то очень обрывочная статья(скорее заметка), в которой всё перемешано.
Вторая версия самого протокола DNSCrypt существует уже очень давно, а тут по факту речь о ветке 2.x dnscrypt-proxy.
Из основных возможностей новой версии, прежде всего, хочется отметить возможность коммуникации с сервером по протоколу TCP
Такая возможность присутствовала в dnscrypt-proxy уже очень давно(если не всегда), ещё до перехода на ветку 2.x. Из конфига версии 1.9.5:
## Do not send queries using UDP. Only use TCP.
## Even if some resolvers mitigate this, DNS over TCP is almost always slower
## than UDP and doesn't offer additional security.
## Only enable this option if UDP doesn't work on your network.
# TCPOnly no
И поддержка TCP транспорта является прямым требованием спецификации:
The DNSCrypt protocol can use the UDP and TCP transport protocols.
DNSCrypt Clients and resolvers should support the protocol over UDP
and must support it over TCP.
А вот действительной фичей dnscrypt-proxy 2.x является поддержка сразу нескольких серверов, автоматический выбор самых быстрых из них (из списка разрешённых), а также автоматический failover и load-balancing.
Такое поведение свойственно всем, или практически всем браузерам.
Оригинальная Opera, Firefox, Pale Moon, Chromium-like…
В оригинальной Опере это решалось нативной поддержкой системы управления сессиями(сохранения/загрузки) и наличием автосохранения предыдущей сессии(autosave.win.bak). В Firefox-like(до перевода всех нав WebExtensions) — addons.mozilla.org/en-US/firefox/addon/session-manager
Наверное и под Chromium-like подобные плагины есть.
Так что это вполне решаемая проблема.
Пока вижу лишь унылые нападки в ответ, а не рассказ "как надо" с детальным описанием механик работы той или иной схемы )
Вполне себе возможная ситуация по нескольким причинам:
NAT рандомизирует номер src порта или этот же номер уже используется другим устройством(т.е. гарантировать что это будет работать в сети со множеством устройств, прямо скажем сложно). Уже упоминал это выше.
Если в качестве Алисы выступает не конечный абонент, а АТС и вызов в состоянии Session Progress (проигрывается приветствие без интерактивного IVR) - RTP-поток будет только в одну сторону, и в таком случае он гарантировано не пройдёт NAT до момента коммутации, когда активируется ответный RTP-поток.
Опять же, только при условии что:
NAT НЕ рандомизирует номер src порта или этот же номер уже НЕ используется другим устройством.
Гарантировать что у произвольного абонента и то, и другое не встретиться - нереально.
Второй абонент сам не находиться за NAT.
В этом случае проблема значительно усугубляется для обоих сторон.
Без активных механизмов определения источника RTP-потока абонентов на стороне АТС, или ухищрений в виде SIP-ALG или доп.настроек на уровне маршрутизатора каждого из абонентов - магии не случится.
Но только зачем-то сами это изначально и утверждали, но да ладно.
Что не работает?
1:1 маппинг для для клиентского устройства?
Закрепление диапазона портов за каждый из клиентских устройств(при условии, что NAT сохраняет номер src порта при трансляции и противоположенная сторона использует IP не из SDP, а src IP из SIP-пакета инициатор вызова)?
Даже SIP-ALG может работать нормально в отдельно взятом случае(если не используется TLS/WSS).
Методы упомянутые в статье вполне рабочие, но важные детали, при которых это будет работать, опущены.
Проблемы работы через NAT довольно поверхностно описаны в статье, это факт.
Из-за этого последнее утверждение, описывающее проблему пропуска RTP от Алисы, в одних условиях будет верным(если NAT по умолчанию рандомизирует порты при трансляции, либо если данный порт уже используется другим устройством), а в других не верным(NAT сохраняет исходный номер src порта и смог это сделать - порт ещё не используется другим устройством).
Это вопрос конкретных условий, в которых работает АТС и её абоненты, а не Silver Bullet решения.
Помимо NAT'ов сильно разнятся возможности как клиентских устройств, так и самой АТС относительно решения проблем работы через NAT.
Если RTP проксируется АТС(что необходимо для записи разговоров), и АТС имеет механизм определения источника RTP-потока на объявленный с её стороны IP:Port - проблема решается малой кровью, без необходимости задействовать STUN или SIP-ALG на клиентской стороне(или иных настроек на маршрутизаторе).
Т.е. как раз то, чем вы сейчас занимаетесь - пытаетесь найти в моём тексте какие-то "ошибки/нестыковки", отводя внимание от исходной претензии к вашему высказыванию по поводу Symmetric NAT.
Классика демагога : )
Вы лучше читайте о чём речь, а то я вижу наличие ссылок на wiki триггерит у вас "он всё из wiki натаскал", что весьма потешно выглядит.
Ссылки на wiki даны для тех, кто не знаком с обозначенными механизмами и кому будет интересно об этом почитать.
И под "достаточной надёжностью" подразумевается стабильность работы канала связи между SIP-сервером и SIP-клиентом через агрессивный провайдерский NAT.
Но вы в этом усмотрели лишь возможность для контратаки в мою сторону )
Так вы этот вопрос выше и не задавали.
Для RTP не применимо. Пример был приведён для сигнального(SIP) трафика в контексте режима работы NAT, который я оспорил в первом сообщении, и комментировать который вы так упорно избегаете.
Т.е. вы уже и не настаиваете, что "на большинстве" именно Symmetric NAT ? ; )
Приведёте пример почему он не верный и почему не будет работать?
А то пока складывается впечатление, что "я видел что оно и так работает, а вы тут все дураки", что довольно слабый аргумент.
При том, что это равноценный элемент проблемы с NAT в работе SIP, как и проблема с (не)прохождением RTP, а также как иллюстрация к тому, почему устройства работают находясь за Port Restricted Cone NAT.
А вы так и не ответили, где это вы Symmetric NAT нашли на "большинстве встроенных в роутеры NAT" ; )
Что вы несёте?..
Большинство NAT - это Port Restricted Cone NAT.
А доступность SIP-устройств для входящих вызовов обеспечивается одним из следующих механизмов:
а) Банальный Keep-Alive - частая(10-30 сек) отправка "пустых(\r\n)" или SIP-пакетов типа OPTIONS или NOTIFY SIP-клиентом на SIP-сервер.
(Почти) схожий эффект может достигаться очень частой(каждые 60 секунд) перерегистрацией SIP-клиента, но на очень агрессивных CG-NAT(Carrier-grade NAT) это вряд ли прокатит. Это не может являться заменой KA и в целом порочная/не эффективная практика(тем более для "стационарных" SIP-клиентов).
Обязательно для транспорта UDP. Менее критично(при условии нахождения НЕ за CG-NAT) для TCP(и соответственно TLS/WSS). Для TCP может использовать(как со стороны клиента, так и сервера) нативный TCP Keep-Alive механизм, но тут многое зависит от связки сервер <> NAT <> клиент.
б) Алгоритмы SIP-ALG(названия могут варьировать или быть просто в виде отдельной группы спец-правил), которые при детектировании SIP-взаимодействия через маршрутизатор, динамически создают правило для поддержания открытого состояния выделенного на уровне NAT порта, даже если со стороны клиента нет KA и используется UDP в качестве транспорта для SIP.
Так как никакого стандарта(насколько я знаю) не существует на реализацию SIP-ALG, все характеристики его работы произвольны и весьма часто такие решения нестабильны/функционируют некорректно, что нередко создаёт проблемы в работе тех АТС/серверных решений, которые могут без перезаписи значений(IP:Port) в SIP-заголовках клиентом(используя STUN) или маршрутизатором(SIP-ALG) корректно определять контакт(IP:Port) для сигнального(SIP) и медиа(RTP) трафика.
Очень часто SIP-ALG - это чёрный ящик, поэтому если есть иные средства для организации корректного взаимодействия между сервером и клиентом - следует отказаться от SIP-ALG.
Это вывод из многолетней личной практики(не операторского, конечно, уровня, но коммерческой эксплуатации).
в) Использование Stateful протокола транспортного уровня(т.е. TCP). Но как уже упомянуло в пункте а), домашние провайдеры со своим CG-NAT плевать хотели на это, и могут также агрессивно выпилить вашу TCP-сессию через 30 секунд простоя.
Поэтому если вы полностью не контролирует весь маршрут внутри сети до выходной точки в Интернет, то полагаться на это невозможно.
Поэтому лишь Keep-Alive может обеспечить достаточную надёжность "обратного канала" для обычных потребителей.
Гугл-перевод что ли?..
Судя по всему под этим кроется "Encrypted Advertising Data", которое появилось в версии 5.4
Advertising в Bluetooth это оповещение, а не реклама -_-
Ни согласования, ни подключения, но спаривания... : /
Уровень подготовки и проверки статьи перед публикацией великолепный /s
Какие вводные данные - такие и предположения )
Проблема в том, что мобильный трафик намного "усердней" блокируют.
Да и самих мобильных операторов всего ничего, в отличии от стационарной связи.
Отсюда и проще контролировать/влиять со стороны ломателей Интернета.
Усилия по противостоянию блокировкам - это весьма зыбкий критерий.
Как определить, это сервис "хорошо старается" или Г-сударство "плохо старается"?
Если подходить с максимально потребительской точки зрения: "должно работать само по себе и шоп я не думал", то объективной оценки точно не выйдет.
В текущих условиях в РФ, простым пользователям более перспективно ориентироваться не на готовые сервисы, а разворачивать собственные VPN-серверы на основе одного из заточенных на задачу маскировки протоколов.
Если речь исключительно про бесплатный план ProtonVPN, то тут ещё больше "но".
Хотя бы из-за банального ограничения регионов подключения и количества серверов под пользователей бесплатного плана.
В таком ключе обобщать "user experience" по всему сервису не вижу смысла.
Они конечно большие молодцы, что предоставляют и бесплатный доступ, но судить о качестве/надёжности всего сервиса лишь по бесплатному плану не стоит.
О каких сетях/провайдерах/регионах идёт речь?
Если на мобильных, то это вполне возможно, так как на них обычно намного сильнее ограничения по видам "допустимого" трафика.
В Android клиенте к тому же, уже давно нет IPsec, хотя я не знаю насколько агрессивно его сейчас блокируют в целом.
В то же время на стационарных сетях, как я уже упоминал выше, как минимум на части провайдеров/регионов, IPsec работает годами без смены площадок и/или IP-адресов на стороней ProtonVPN.
Где-то полгода назад пытался таким образом обойти блокировку стандартного WG на мобильной сети(Билайн и МТС, вроде бы проверялись) до RouterOS на VPS в Казахстане.
Насколько помню, собирая трафик, поведение немного различалось(по отношению к порту из динамического диапазона) по тому какое количество пакетов успевало пройти в процессе(после) хендшейка, но итог был неутешительным.
Дампы вряд ли уже найду, да и ситуация могла уже 10 раз поменяться за это время.
Но это очень "топорный" способ, и сомнительно, что ТСПУ будет слепо вайтлистить UDP 443 из-за того что там ходит QUIC. Учитывая, что QUIC тоже может легко уйти в бан по велению пятки строителей сувенирного Интернета ; )
Вероятно сильно зависит от сочетания провайдера и протокола, так как я оплачиваю сервис с 2018 года и серьёзных проблем практически никогда не наблюдал при использовании через IPsec(IKE2), настроенном на маршрутизаторе(RouterOS) через домашний МТС GPON. Около 4 туннелей в разные локации постоянно работают, но работу из других сетей я не проверял, так как с других устройств я просто строю WireGuard-туннель до своего маршрутизатора, а дальше разруливается правилами куда направлять.
Некоторые друзья жаловались на проблемы с подключением к ProtonVPN через мобильные сети(при использовании любых доступных протоколов, в том числе и Stealth).
После этого я просто раскидал им гостевые WireGuard конфиги до моего маршрутизатора - на том проблемы и решились.
Также без проблем функционирует(IPsec) из рабочей сети(собственная AS-ка) с транзитом через ЭР-Телеком.
С каких это пор в стране стали считаться с "сопутствующими потерями" ? (=
Не только OpenVPN, но и IPsec и WireGuard.
Впрочем это не меняет картины для господина, поднявшего вопрос.
"В один клик" и "без доп. софта", увы, не бывает. Но вполне решается любым Mikrotik'ом + гайд из Интернета.
«Когда ты думаешь, что падать уже некуда, это безмозглое человечество пробивает очередное дно»: /
Был бы очень признателен за ссылку.
Вторая версия самого протокола DNSCrypt существует уже очень давно, а тут по факту речь о ветке 2.x dnscrypt-proxy.
Такая возможность присутствовала в dnscrypt-proxy уже очень давно(если не всегда), ещё до перехода на ветку 2.x. Из конфига версии 1.9.5:
И поддержка TCP транспорта является прямым требованием спецификации:
А вот действительной фичей dnscrypt-proxy 2.x является поддержка сразу нескольких серверов, автоматический выбор самых быстрых из них (из списка разрешённых), а также автоматический failover и load-balancing.
Весь список различий относительно ветки 1.x можно посмотреть тут:
github.com/jedisct1/dnscrypt-proxy/wiki/Differences-to-v1
Оригинальная Opera, Firefox, Pale Moon, Chromium-like…
В оригинальной Опере это решалось нативной поддержкой системы управления сессиями(сохранения/загрузки) и наличием автосохранения предыдущей сессии(autosave.win.bak). В Firefox-like(до перевода всех нав WebExtensions) — addons.mozilla.org/en-US/firefox/addon/session-manager
Наверное и под Chromium-like подобные плагины есть.
Так что это вполне решаемая проблема.