velosipedist, wireshark и tcpdump используют один и тот же системный интфейс к пакетам.
Про мак я поспешил, в бридже же будет виден мак исходного устройства, а спуфить на другом устрйостве даже хуже будет. Хотя если провайдер мак не смотрит, то ну и ладно. Но в любом случае, он в теории может спалить наличие на порту других маков, даже если они не будут светиться по IP. В некоторых случаях провайдеры следят, чтобы на порту больше одного мака не было.
velosipedist, да, кстати, если провайдер проверяет мак-адрес клиента на порту, то ещё надо будет показывать на интерфейсе в сторону провайдера такой же мак...
velosipedist, собираем тестовый стенд и пробуем tcpdump. Ну в целом я и так скажу, что слушать bridge, хотя на обоих интерфейсах будет ловиться всё то же самое...
montarano, например, настоящие пацаны читают документацию по Flask на тему того, как его завести в WSGI. Даже ключевые слова, по которым искать, вполне себе очевидны...
Лично не видел, но во время "провайдерских войн" внутри общаги одного вуза 20 дет назд аффилированный с одним из "провайдеров" товарищ вставил свой "сервер" в разрез магистрали другого провайдера и рандомно дроппал чуть-чуть пакетов... Был жостко наказан неблагодарными студентами, когда это вскрылось :)
Конечно можно, делаешь bridge между интерфейсами и ловишь всё что надо. Главное чтобы производительности хватило на весь трафик, шоб не спалиться на том, что гигабитный тариф не выдерживается...
Лучше не все порты, а только нужные. Как минимум, имеет смысл оставить порт для ssh, чтобы на внешний сервак можно было бы зайти в случае чего. И порт для VPN-сервера, конечно же, не надо пробрасывать.
А дальше поднять VPN по любой технологии и сделать nat, например:
Для трафика со стороны домашнего сервера сделать nat на выход:
iptables -t nat -A POSTROUTING -s <IP-домашнего-в-VPN> -j MASQURADE
Не забыть включить маршрутизацию (net.ipv4.ip_forward=1 в sysctl, файл /etc/sysctl.conf).
Со стороны домашнего сервера надо будет сделать policy routing (source routing), если надо только отвечать на запросы снаружи. Либо (что намного проще) сделать default route внутрь VPN, а также сделать отдельно роут до внешнего сервера мимо VPN, чтобы он не пытался трафик до VPN заворачивать внутрь VPN. В последнем случае исходящий трафик тоже будет ходить через внешний сервер поверх VPN.
Это общие сведения, дальше учиться, тренироваться, набивать шишки, изменять ТЗ по ситуации...
К блокировкам это не имеет отношения. Транзитный провайдер может блокировать всё равно.
А вот что с таким имуществом придётся получить дорогую лицензию оператора, поставить СОРМ или как-то убедить регулятора что никому не оказываешь услуг...
Да и LIR не может просто так выдать сетку, по крайней мере IPv4. Нужны обоснования, что сетка прям нужна.
В любом случае, содержание файловой системы будет в состоянии как если бы системе рубануть питание. Так что подобным образом нормальные бэкапы не очень хорошо делать.
Если внутри виртуалки используется система с возможностью снапшотов (zfs, btrfs), то можно внутри сделать снапшот и его сбэкапить.
Но правильнее выбирать инструмент под конкретные условия, сразу же думая о том, как этот бэкап использовать. Просто делать бэкапы бинарных данных не имеет смысла. Например, у меня был случай, когда наличие бинарного бэкапа mysql не помогло. Потому что данные в ibdata очень капризны, чуть что не сойдётся - и всё, приехали... Даже медитация со строго такой же версией mysql и таким же конфигом не спасает. Для баз данных есть свои специальные средства для бэкапа. А чтобы исключить влияние - делается репликация базы и бэкап снимается с реплики. Опять же, если бэкап делается с целью восстановить состояние базы на любой момент, то надо иметь регулярные бэкапы плюс бинлоги в качестве инкрементов. Мне приходилось такое восстанавливать для убитой базы, которой неприемлемо было откатиться на сутки.
Для файлов имеет смысл делать файловые бэкапы, код лучше держать в git, ну а вместо (и/или помимо!) бэкапа всей системы надо наладиться над автоматизацией разворачивания (automated install, ansible итд). Чтобы если с сервером что-то случилось - можно было бы быстро поднять такой же, а не страдать полночи.
#, я и 9 и 15 пробовал ковырять, но у меня так ни одного законченного приложения полезного не было.
Зато я написал на батниках (ndos) загрузчик, который умел бутять или Linux в loadlin, или один из разных DOS через файл их бутсектора... Загрузчик имитировал горячую перезагрузку, которую я дизассемблировал из novel dos (в ms dos и pc dos обработчик ctrl-alt-del был слишком сложный).
#, дело не в опасениях, int9 это аппаратное прерывание (IRQ1) и от операционной системы оно не зависит, а другие прерывания это API BIOS или операционной системы. У IRQ1 просто есть стандартный обработчик. А все переопределяющие приложения, как правило, запоминали текущее значение, выполняли свои действия и при необходимости вызывали предыдущий обработчик. Поэтому потенциально могло быть несколько разных приложений, которые клавиатуру обслуживали. Например, была популярная программа killer.com, которая по Ctrl-Alt-Del показывала менюшку, в которой текущую прогу можно было прибить (не всегда это было гарантированно безопасно, но для приложений без выкрутасов работало хорошо).
Может быть проблема даже на клиентской стороне. Недавно на довольно новом баребоне с WiFi от intel тестил под Linux - оно постоянно в dmesg фигачило что-то типа wifi reset при подключении к Microtik по 5GHz, на 2.4 всё ок. Не стал разбираться, ибо там у его пользователя всё равно винда есть, в которой всё ок. Думаю апгрейд со стокового ядра 5.15 из Ubuntu 22.04 до более нового помог бы.
Подобное может и на винде случиться, если дрова старые или глючные.
NikitaTim123, если там убунту то apt install firefox, если Centos то yum install firefox итд итп. Это же штатная операция - "поставить что-то из пакетов".
#, в DOS довольно распространённой практикой у подобных приложений было вешаться прям на int9 и дальше уже непонятно как действовать. Может, оно под частоту процессора адаптировалось и крутило какой-то цикл для управления скорости, но частоту таких "супербыстрых" процессоров определяло неправильно? Не знаю. Когда у меня появился Sound Blaster и Impulse Tracker, играть музыку на спикере стало совсем неинтересно.
mayton2019, было много проограмм на Pascal с модулем crt, в которых происходило на 0 на процессарах с частотой от 200 МГц. Ещё мне попадалась прога для исполнения музыки на PC Speaker с полифонией, в которой высота ноты регулировалась левым и правым Shift, она даже на Pentium 1 так быстро реагировала на Shift, что попасть в нужную высоту было очень тяжело...
