Не думаю, что риск больше чем у водителей велосипедов/мопедов/мотоциклов.
Ну и по дорогам такой всё равно будет передвигаться меньше, чем летать, это всё же летательный аппарат с функцией автотранспорта, а не наоборот. На нём должно быть удобно пролететь большую часть пути, а остаток до дверей дома/офиса проехать по дорогам минуя пересадку в аэропорту.
Пока это самый универсальный вариант летающего автомобиля, который мне попадался.
Адаптация летательных аппаратов под передвижение по дорогам уже сейчас работает. В Чехии некоторым моделям гиропланов разрешено передвигаться по ДОПам. В "Орёл и Решка" был сюжет про это: https://youtu.be/27IJmzWEBk8?t=113
Я тут почитал, и как понял, если взять IPsec с NAT-T с cipher и auth=null, то это аналог ipip-over-fou безо всякой аутентификации. С ipipou же можно настроить аутентификацию соединения на том же порту (правило nftables для передачи в nfqueue работает как своего рода демультиплексор для протокола аутентификации и fou).
Про 1-в-1 только из этого комментария понятно стало. В любом случае спасибо за информацию, даже если IPsec окажется лучшим решением стоило создать альтернативу, и написать статью, чтобы об этом узнать.
OpenVPN хоть и тормоз зато универсален, можно настроить и потюнить под очень разные задачи, впрочем как и IPsec, наверно.
Я бы не называл ipipou костылём, это скорее надстройка над ipip-over-fou.
Для решения одной задачи можно использовать множество способов, IPsec+NAT-T, тоже может подойти, как и OpenVPN, и другие.
Я бы был не прочь подробнее узнать о преимуществах IPsec+NAT-T (и остального набора непонятных мне буков), пока только вот эту статью нашёл с поверхностным описанием.
ipipou (ipip-over-fou) более нишевое решение — только для Linux, с упором на производительность и меньший оверхед, и по моим ощущениям, опередит в этом плане IPsec+NAT-T (ибо основной трафик в ядре, в накладных расходах только заголовок внутреннего IP, и лишь частично бесполезный внешний UDP). У кого есть желание может провести эксперимент. У меня личная трансцендентная неприязнь к IPsec, я с ним плохо знаком, поэтому это буду не я.
Тогда уж pwnat, как более совершенная версия, от того же автора, основана на том же методе.
Для прямого соединения между хостами за NAT ещё часто пользуются STUN, например, вот в этой статье автор тоже использовал IPIP-over-FOU вместе со STUN для туннелирования сквозь NAT.
Но это не всегда работает, например с самым непролазным Carrier-grade NAT, хотя при должном упорстве, если время позволяет, и его бывает можно пробить, если долго долбить перебирая порты. Я как-то пробовал и для простых случаев использовать pwnat, но не получилось.
Может дойдут руки добавить методы для обхода NAT в ipipou, пока же нужен хост с публичным IP.
В первом случае (20 Mbps) он раз-за разом показывал чуть меньшее время отклика даже по сравнению с основным каналом, хотя ожидается чуть большее.
В во втором (Gbps) казалось бы с гораздо более качественным соединением упёрся в 12Mbps (для TCP) при тех же параметрах. Выставлять большие --tun-mtu имеет смысл, чтоб за 200-300 Mbps разгонять openvpn, поэтому ожидаемо, что на обычных параметрах больше 200-300 не вышло, но 12 уж слишком мало. Может перепроверю в другое время. Возможно по какой-то причине именно трафик openvpn направлялся по другому сильно медленному маршруту где-то посередине. Я проверял несколько раз, в то же время другие туннели вели себя адекватно. Хотя особо с точностью измерений не заморачивался, просто общую картину хотелось получить.
Нет, ибо если функции передать пустой set (именованный), в надежде, что она его поменяет также, как не пустой, то «более идиоматичный» способ поведёт себя по-другому и оставит его неизменным.
Именно для этого случая допускаю, но пока не настолько, чтобы брать её в расчёт и делать какие-то ставки. Хотя насчёт невозможности существования вечного двигателя второго рода (читай корректности второго закона/постулата термодинамики) у меня есть сомнения, мне он видится настолько же «очевидным», как «параллельные прямые не пересекаются», или «время течёт везде одинаково».
Я допускаю (можно сказать уверен), что в мире есть ещё очень много явлений, которые наука в текущем её состоянии описывает неправильно, или не точно, или отрицает, или не в курсе их существования, или вообще возможность/способ познания некоторых вещей выходит за рамки научной парадигмы.
Поэтому чёрный маг Gryphon88 из комментария выше остался бы без моей пряди волос.
Если вернуться к топику, то уйдя из теоретической области, ответом на вопрос
каким образом пользователь может убедиться, что его персональные данные удалены/отозваны?
будет
Никаким.
с достаточной вероятностью, чтобы брать её в расчёт.
Если уйти из теоретической области, мы не можем быть уверены почти ни в чём (причём слово «почти» мне тоже кажется здесь лишним). Можно сказать: «Мы уверены в том, что на орбите не летают вечные двигатели первого и второго рода в рамках существующей теории N».
Не всегда этого достаточно. Разные провайдеры разных стран не чураются сами отвечать на не шифрованные DNS запросы на порт 53/udp по любому адресу. Так что VPN, DoH, DoT и иже с ними понадёжней будут.
+ с введением поддержки TLSv1.3 на обоих концах соединения многие блокировки поломались.
При использовании целых произвольной точности (например, как в python3) не будет переполнения разрядности, операции с большими числами как раз и упрутся в нехватку памяти (когда объём памяти, необходимый для хранения числа, близок к доступной процессу памяти).
Такой паспорт скорее всего могут признать недействительным и отказаться принимать, если в организации, в которую с ним пришли, есть такие вот мудрёные проверки на валидность.
У моего знакомого был паспорт, выданный в день 20-летия. Спустя несколько лет система одного банка отказалась принимать его по причине истёкшего срока действия (когда системы других проглатывали за милую душу). Как оказалось, в день твоего рождения по закону тебе ещё столько же лет, сколько было вчера, и только на следующий день ты законно становишься на год старше.
Интересно учитывают ли казусы с таймзонами в таких пограничных случаях. Хотя нет, не интересно — таймзоны и есть сплошной казус.
У автора была задача не выпускать ПК в интернет, и такой частичный выпуск, возможно, мог сгодиться.
А так верно замечено, что можно пользоваться соксификаторами, если удобно.
Для обхода провайдерских ограничений на раздачу трафика есть и другие способы, которые могут быть более удобными, но вариант с socks один из самых простых в настройке, не нужно никаких плясок с VPN и файерволом, не нужен рут на мобильном, работает довольно надёжно с любыми ОС.
Из возможных уязвимых мест такого подхода — нешифрованный трафик с ПК, там может быть не мобильный user-agent и другая информация, если провайдер заморочится, могут возникнуть подозрения.
Это скорее не стандарт, а обычай, и далеко не все ему следуют (взять хотя бы firefox с его многобуквенными опциями с одним дефисом). И даже по этому стандартному обычаю есть опции, которым требуется аргумент, и не дай божа случайно засунуть другую однобуквенную опцию между многобуквенной и её аргументом (чтобы уточнить поведение, например: cp -aTi /source /target).
Ну и некоторые программы могут вообще не распознать склеенные аргументы, даже если они однобуквенные безаргументные, ибо разработчику интересно прогать, а не аргументы ваши клееные парсить.
Когда-то натыкался на инфу, что некоторые файловые системы, могут не иметь этих хардлинков (помню в пример приводились фс для оптических дисков типа UDF) и, вроде, были опции для монтирования с их эмуляцией.
Вполне возможно, что это уже пережиток прошлого и такого теперь не бывает.
Не думаю, что риск больше чем у водителей велосипедов/мопедов/мотоциклов.
Ну и по дорогам такой всё равно будет передвигаться меньше, чем летать, это всё же летательный аппарат с функцией автотранспорта, а не наоборот. На нём должно быть удобно пролететь большую часть пути, а остаток до дверей дома/офиса проехать по дорогам минуя пересадку в аэропорту.
Пока это самый универсальный вариант летающего автомобиля, который мне попадался.
Адаптация летательных аппаратов под передвижение по дорогам уже сейчас работает. В Чехии некоторым моделям гиропланов разрешено передвигаться по ДОПам. В "Орёл и Решка" был сюжет про это: https://youtu.be/27IJmzWEBk8?t=113
Я тут почитал, и как понял, если взять IPsec с NAT-T с cipher и auth=null, то это аналог ipip-over-fou безо всякой аутентификации. С ipipou же можно настроить аутентификацию соединения на том же порту (правило nftables для передачи в nfqueue работает как своего рода демультиплексор для протокола аутентификации и fou).
Про 1-в-1 только из этого комментария понятно стало. В любом случае спасибо за информацию, даже если IPsec окажется лучшим решением стоило создать альтернативу, и написать статью, чтобы об этом узнать.
OpenVPN хоть и тормоз зато универсален, можно настроить и потюнить под очень разные задачи, впрочем как и IPsec, наверно.
Я бы не называл ipipou костылём, это скорее надстройка над ipip-over-fou.
Для решения одной задачи можно использовать множество способов, IPsec+NAT-T, тоже может подойти, как и OpenVPN, и другие.
Я бы был не прочь подробнее узнать о преимуществах IPsec+NAT-T (и остального набора непонятных мне буков), пока только вот эту статью нашёл с поверхностным описанием.
ipipou (ipip-over-fou) более нишевое решение — только для Linux, с упором на производительность и меньший оверхед, и по моим ощущениям, опередит в этом плане IPsec+NAT-T (ибо основной трафик в ядре, в накладных расходах только заголовок внутреннего IP, и лишь частично бесполезный внешний UDP). У кого есть желание может провести эксперимент. У меня личная трансцендентная неприязнь к IPsec, я с ним плохо знаком, поэтому это буду не я.
Тогда уж pwnat, как более совершенная версия, от того же автора, основана на том же методе.
Для прямого соединения между хостами за NAT ещё часто пользуются STUN, например, вот в этой статье автор тоже использовал IPIP-over-FOU вместе со STUN для туннелирования сквозь NAT.
Но это не всегда работает, например с самым непролазным Carrier-grade NAT, хотя при должном упорстве, если время позволяет, и его бывает можно пробить, если долго долбить перебирая порты. Я как-то пробовал и для простых случаев использовать pwnat, но не получилось.
Может дойдут руки добавить методы для обхода NAT в ipipou, пока же нужен хост с публичным IP.
В во втором (Gbps) казалось бы с гораздо более качественным соединением упёрся в 12Mbps (для TCP) при тех же параметрах. Выставлять большие --tun-mtu имеет смысл, чтоб за 200-300 Mbps разгонять openvpn, поэтому ожидаемо, что на обычных параметрах больше 200-300 не вышло, но 12 уж слишком мало. Может перепроверю в другое время. Возможно по какой-то причине именно трафик openvpn направлялся по другому сильно медленному маршруту где-то посередине. Я проверял несколько раз, в то же время другие туннели вели себя адекватно. Хотя особо с точностью измерений не заморачивался, просто общую картину хотелось получить.
Я допускаю (можно сказать уверен), что в мире есть ещё очень много явлений, которые наука в текущем её состоянии описывает неправильно, или не точно, или отрицает, или не в курсе их существования, или вообще возможность/способ познания некоторых вещей выходит за рамки научной парадигмы.
Поэтому чёрный маг Gryphon88 из комментария выше остался бы без моей пряди волос.
Если вернуться к топику, то уйдя из теоретической области, ответом на вопрос будет с достаточной вероятностью, чтобы брать её в расчёт.
+ с введением поддержки TLSv1.3 на обоих концах соединения многие блокировки поломались.
У моего знакомого был паспорт, выданный в день 20-летия. Спустя несколько лет система одного банка отказалась принимать его по причине истёкшего срока действия (когда системы других проглатывали за милую душу). Как оказалось, в день твоего рождения по закону тебе ещё столько же лет, сколько было вчера, и только на следующий день ты законно становишься на год старше.
Интересно учитывают ли казусы с таймзонами в таких пограничных случаях. Хотя нет, не интересно — таймзоны и есть сплошной казус.
А так верно замечено, что можно пользоваться соксификаторами, если удобно.
Для обхода провайдерских ограничений на раздачу трафика есть и другие способы, которые могут быть более удобными, но вариант с socks один из самых простых в настройке, не нужно никаких плясок с VPN и файерволом, не нужен рут на мобильном, работает довольно надёжно с любыми ОС.
Из возможных уязвимых мест такого подхода — нешифрованный трафик с ПК, там может быть не мобильный user-agent и другая информация, если провайдер заморочится, могут возникнуть подозрения.
Вариант, когда провайдер ограничивает раздачу, обычно можно обойти так:
Таким образом у ПК будет доступ в интернет только у программ, настроенных работать через прокси.
Это скорее не стандарт, а обычай, и далеко не все ему следуют (взять хотя бы firefox с его многобуквенными опциями с одним дефисом). И даже по этому стандартному обычаю есть опции, которым требуется аргумент, и не дай божа случайно засунуть другую однобуквенную опцию между многобуквенной и её аргументом (чтобы уточнить поведение, например:
cp -aTi /source /target).Ну и некоторые программы могут вообще не распознать склеенные аргументы, даже если они однобуквенные безаргументные, ибо разработчику интересно прогать, а не аргументы ваши клееные парсить.
Когда-то натыкался на инфу, что некоторые файловые системы, могут не иметь этих хардлинков (помню в пример приводились фс для оптических дисков типа UDF) и, вроде, были опции для монтирования с их эмуляцией.
Вполне возможно, что это уже пережиток прошлого и такого теперь не бывает.
Для
cpтак действительно короче, но бывают программы где склеивание опций приводит ксклеиванию ластнеожиданным результатам.