Jump to content
Калькуляторы

lugoblin

Пользователи
  • Content Count

    89
  • Joined

  • Last visited

About lugoblin

  • Rank
    Абитуриент

Информация

  • Пол
    Мужчина

Город

  • Город
    Mexico
  1. Какая у вас замечательная картинка, сразу всё понятно. Скорее всего, это происходит потому что "остальные PC" используют Mikrotik 1 в качестве маршрута по умолчанию. А Mikrotik 1, в свою очередь, знает маршрут до Филиала. Скорее всего, это происходит потому что Почтовик использует в качестве маршрута по умолчанию Шлюз №1, а тот, в свою очередь, использует шлюз провайдера. Таким образом, пакеты предназначенные для Филиала не попадаят на Mikrotik 1, а через интернет им дороги нет. Проверять эту гипотезу надо так: Поставить сниффер на Mikrotik 1 и на Шлюз №1. Попинговать Почтовик из Филиала. В сниффере вы увидите как echo request пойдут через Mikrotik 1 во внуренюю сеть, а ответы echo replay попытаются пойти в Интернет через Шлюз №1, где благополучно потеряются. Чинить костылём надо, скорее всего, так: Проиписать на Почтовике и на Шлюзе №1 статический маршрут до 192.168.99.0/24 через 192.168.55.9. Можно только на Шлюзе №1, но это замусорит вашу сеть пакетами ICMP Redirect и не факт что сработает. Можно только на Почтовике, если доступ из Филиала к Шлюзу №1 в принципе не нужен. Чтобы починить не костылём, а как следует, придётся несколько поменять топологию сети.
  2. Не совсем понятна топология L3. У вас весь L3 в датацентре? (до которого, как вы сказали, 2x 10G в LACP) В том числе и аплинк с "белыми" адресами? Или ваш аплинк это и есть белая сеть, а весь "серый" L3 предполагается рутить локально? В любом случае, независимо от контекста: - В одном и том-же сегменте (VLAN) можно использовать серые и белые адреса. Дадим хосту серый адрес и пропшишем серый шлюз, будет ходить в Интернет через NAT. Дадим белый адрес и пропишем белый шлюз, будет ходить напрямую. Это работает, но слишком велик соблазн развести там грязь. Особенно, если несколько людей этим рулит и принимает решения. Рекомендую разнести по разным VLAN-ам публичную сеть с белыми адресами, и приватную с серыми. - Функцию NAT, как и вообще коммутацию L3, не стоит отдавать на откуп устройству в роли "свич доступа", потому что это превратит его в монолитный god-box с огромным риском наслоений всяких legacy, над которум вы очень быстро потеряете контроль. На первых порах, функцию L3 можно сделать на виртуалке x86 с чем угодно, от Линукса общего назначения со скриптом nftables, до аплаянсов FotriGate, Wyatta или Mikrotik. По мере надобности, когда захлёбываться начнёт, либо рулить станет слишком неудобно, заменить на специальную железку или интегрировать функцию в вашу платформу виртуализации по моде Software Defined Network. Из этого правила есть много ислючений, их можно обсудить, но это отклонит нас от темы. - Адреса для нод, IPMI и т.д., однозначно надо спрятать за NAT, независимо от избытка или недостатка белых адресов. Кроме того, их следует закрыть файерволом (который != NAT), запретить бесконтрольно шлятся в инет и подключаться к ним откуда попало. - Мотивация "использовать весь потенциал этого свитча" несколько порочна, т.к. можно легко и незаметно перешагнуть грань, за которой использование некого ресурса будет нецелесообразно. Используйте то что требуется когда это уместно, и не печальтесь за простаивающий потенциал. Рекомендую расписать требования к сети, например в форме списка use-cases, и нарисовать топологию (L2 и L3 отдельно) в соответствии с требованиями. Пoказать на "поругать" дружественному специалисту. Потом внедрять. Например: - Вычислительной ноде требуется физический порт для MGMT, с приватным адресом и серьёзными ограничениями по связности. Решаем выделением порта на MGMT свиче, с конфигурацией untagged в специальном VLAN-е. - Вычислительной ноде требуется 2-4 физическийх портов для связности общего назначения с остальной сетью, с поддержкой агрегации. Решаем выделением портов с ЛАЦП на Access свиче, в mode trunk, с доступом в VLAN отданную под MGMT для руления гипервизором. - Виртуальной машине с обратным прокси требуется прямой доступ в Инет и в приватную сеть A. Решаем выделением этой машине двух VIF, одной в VLAN-е с белыми адресами, другой в VLAN-е где живёт сеть A.
  3. Хорошо, но мало. Ну вот, допустим, потеряли мы файл, нашли грепом в логах rsync-а как его стирание ушло на реплику, которав вроде как бэкап. Нам от того лучше стало? Инкрементальный tar, при всех его недостатках, этот кейс покрывает. потому и написал про снапшоты на приёмнике. они практически ничего не стоят, и отлично решают эту проблему. Согласен, но просветите, почему на приёмнике? Я бы это интерпретировал как рекомендацию st_re, паралельно с бэкапами подумать в сторону снапшотов, которые и на основном хранилище не зазорно сделать, тем более если они ничего не стоят. А н априёмнике пусть будет бэкап, простой как кирпич, который и в оффлайн унести можно, и на NAS по CIFS скинуть.
  4. VPNserver в подсети mikrotik

    Решение в принципе достижимо тем способом который вы описываете, с dstnat и srcnat, но граблей там много и траблшутить это дело будет грустно. Лучше сделайте так, чтобы те кто снаружи коннектились на 89.х.х.34, а те кто внутри непосредственно на 192.168.1.16. Конкретные меры: Оставьте только dstnat, для подключений извне, и уберите srcnat. Подключения изнутри не пойдут через Mikrotik. Сделайте так чтобы клиенты OpenVPN коннектились к серверу по hostname а не по IP адресу, например vpn.example.com. Таким образом вы будете контролировать, кому в какой IP резольвить имя OpenVPN сервера. Создайте запись "vpn.example.com A 89.х.х.34" в зоне example.com, которую, предположительно, вы контролируете. Создайте запись "vpn.example.com A 192.168.1.16" среди статичных DNS записей на вашем Mikrotik-е. Удостоверьтесь что адресация сети внутри VPN не конфликтует с адресацией в локальной сети. Или пересмотрите задачу. Зачем вам VPN в локальной сети?
  5. Заметка не о том, что блокируют и серфить трудно, а о том, что вводится законодательный запрет на использование этих способов. Это проблема в 21 веке.
  6. Предположу, что подводные камни, даже в готовом решении, будут спецефичны для конкретно вашего use-кейса. Судя по тому что вы расказали, ИМХО rsync вполне подходит, с оговоркой что придётся как-то следить за реплицированием delete и перезаписи файлов. Иначе будет риск в один прекрасный момент догнать изменение типа "стёрто всё". Tar, в хорошей мере, от этого защищает.
  7. Зависит от того, в какой ситуации предполагается это воссатанавивать. Одно дело "хранилка сгорела синим пламенем, через 15 минут надо быть обратно в онлайне", а другое "сдуру перезаписали файло, оно понадобится через пару дней, восстановите плз, с меня пиво". По дефолту, можно работать с техзаданием "ХЗ, но хотелось бы не остаться совсем без штанов если всё накроется". "большие объемы" - в общем случае, чем примитивнее инструмент, тем лучше. Меньше тормозить будет и более предсказуемо. Я бы начал тупо с tar. "мало изменяющихся, в основном добавляющихся больших файлов" - полная копия, допустим, раз в месяц, и инкрементальная ежеденвно. Хранить текущий и предыдущий месяц со всеми инкременталами, из более ранних месяцев только полную копию. "видео и прочее фото и pdf" - если уже пожато, то можно tar-ом без сжатия. Надо попробовать так и так, посмотреть как дополнительное сжатие влияет на размер и время. "никто не помнит в каком веке он появился и где точно лежал" - помогает, кроме бакапа, проводить частую инвентаризацию. Банально "find /wherever -type f -print | sort | gzip > inventory_wherever_$(date +%FT%H%M%S).txt.gz". В инвентаре искать grep-ом. Если вычислительных ресурсов хватает, то по тому-же инвентарю можно генерировать и хранить контрольнные суммы для каждого файла. Ещё инвентарь помагает как-то независимо отслеживать, что там вообще происходит. Ответственное лицо может периодически пробегать глазами diff между самым свежим инвентарём и предыдущим просмотренным, по ходу делая пометки кому дать по рукам. Если предполагается что перезапись и удаление файлов это исключительно редкая операция, то можно как-то автоматизировать генерацию лога о подобных событиях. Я так делал, правда, на на бэкапах а в пофайловой репликации с помощью unison. При репликации удаления, на второй копии файл не удалялся а перемещался в специальное место, которое время от времени вручную просматривал специально обученный человек. Я кратко наметил некоторые меры "вручную". На моей практике, зачастую оказывается что наколхозить что-то минимально будет не только быстрее, но и надёжнее внедрения полоценного решения резервного копирования. В перспективе, опыт эксплоатации колхоза сильно помогает формализировать требования для "взрослой" системы, если до её внедрения дойдёт дело.
  8. Прошу прощения если создал впечатление что это я качу бочку, на самом деле совсем нет. Я просто не понял, вы собираетесь менять адреса в корпоративной сети абонента, или во внутренней сети провайдера?
  9. Просто на всякий случай. Вы в этой ситуации находитесь на месте провайдера, правда?
  10. Нужны скоростные VDSL модемы

    Почему не Ethernet over UTP? По условиям, новых кабелей тянуть совсем нельзя? Если есть вариант "обойти" стену, то бывает такое: https://mikrotik.com/product/wireless_wire
  11. Механика более или менее понятна. Гражданский иск -> нудный танец по взысканию, с разнообразными мотиваторами и лазейками. Спасибо.
  12. Сорри за возможную тривиальность вопроса, я несколько вне контекста. А кроме лишения свободы или штрафа, возмешение ущерба в таких случаях злоумышленнику грозит? В смысле, не столько по УК сколько по практике.
  13. Сообщение интересно (с моей колокольни праздночитающего Наг), но это не совем новость, обсуждать особо нечего. Вот если бы они наоборот, в ответ на беспорядки запустили бы 5G досточно и выдали бы населению безлимит на какой-нибудь Netflix, это да, была бы новость. А так, всё в рамках ожиданий.
  14. Статья интересная, но мотивация персонажей непонятна. Почему оказалось так сложно выяснить, откуда идёт кривая геолокации адресов? Пробивать какие-то координаты... Можно было брать за пуговицу любого более или менее вменяемого визитёра, первым делом убедить его что он пришёл не туда, а потом с пристрастием допрашивать, с чего он вдруг решил искать что бы то ни было именно на этих координатах. Думаю, что уши MaxMind вылезли бы сразу. Или это крепость заднего ума?