Вам прямо с цитатами из этой самой википедии показать чем именно она мне не нравится? :) -- Но если коротко, по ней очень сложно понять, как жить когда микротик ни хрена не основная часть сети, а очень даже вторичная.
Вот я не готов мыслить пространствами и полями. Я как раз привык мыслить на уровне тэгов, поэтому и не заходит мне родная документация. Ну и собственно я думаю, что такой не один, поэтому и попытался перевести на привычную мне терминологию обычные описания.
Ну, тэг как виртуальное свойство пакета работает ровно как я написал, а тэг как набор бит в заголовке я честно говоря не представляю как проверить когда по факту пропадает потому, что из самой таблицы маршрутизации пакет для анализа не выдернуть. А с точки зрения поведения оборудования нет никакой разницы между "тэг 3 прописан в пакете, идущем в коммунаторе с другими пакетами" или "тэг 3 прописан в виртуальном коммутаторе, в котором идут только пакеты для этого тэга".
Ну вот есть у нас бридж, в нём два VLAN, номера 1 и 2. В свойствах бриджа прописан тэг 1, тэг 2 создан через создание влана в бридже.
В бридж добавляем один интерфейс VLAN с тэгом 2, ставим туда айпишник и еще на сам интерфейс бриджа ставим айпишник. И в довершение добавляем туда же физический порт, например 1, при этом в свойствах моста ставим тэг 1 опять же.
Снаружи с 1 порта в такой конфигурации можно снимать нетегированный 1 влан и тегированный второй и пинговать соответствующие адреса.
И в принципе можно считать, что это по факту два разных виртуальных коммутатора, один для 1 влана, второй для 2. И что пакеты, входящие без тэга отправляются в одну таблицу коммутации, а с тэгом 2 -- в другую.
Но если мы считаем, что мост всё-таки один, то логика нисколько не меняется: пакет приходит без тэга на внешний порт, попадает в мост без тэга (потому что тэг порта и моста совпадают) и идёт на интерфейс с адресом.
Или второй пакет приходит с тэгом 2, идёт в тот же мост, тэг с него не снимается потому, что в свойствах порта указан другой тэг, в единой таблице коммутации тэг присутствует, по нему пакет идёт к интерфейсу VLAN, где с него снимается тэг постольку, поскольку в свойствах этого порта тэг 2 указан. И дальше идёт на обработку кому он там пологается без тэга.
Или если говорить ближе к программированию, с точки зрения поведения, нет разницы между цифрой в столбце таблицы и цифрой-номером таблицы. А это же гайд для пользователей, а не для разработчиков микротов.
Кроме того на wlan интерфейсах вне капсмана есть фича VLAN mode + VLAN ID позволяющая интерфейсу "забирать" в бридже нужный VLAN с тегом и передавать дальше снимая тег.
Так это на всех интерфейсах, не только wlan: стоит где-то в свойствах интерфейса вписать номер тэга, этот тэг снимается после интерфейса. И я об этом написал в пункте 2.
Про капсман лично мне конкретно эта ссылка и не помогла (как и вагон еще всяких) потому что она как раз и даёт типовое решение вместо понимания вопроса. Мне нужно было заворачивать трафик из капсмана вместо микротика на другой узел через тегированный порт и прочитав статью я тогда не понял, как именно это реализовать. Вроде готовая конфигурация работает, а как ей "доработать напильником" не понятно.
Остальные ссылки добавил в статью, хотя на мой взгляд в материале, помеченном как tutorial обсуждать такие тонкости как "на этом чипе оно будет работать, но возможно будет тормозить из-за программной реализации" не совсем верно и я действительно считаю, что это должно быть в другой статье, которую всё ещё прошу написать Вас :).
Оба-на, вот про меню switch спасибо, реально не сталкивался. Покурю маны на эту тему с интересом.
Но не будет с ним работать по L3 и соответственно влан интерфейсы на этом бридже с вланом которого нет этого бриджа как tagged в меню bridge VLANs работать не будут
А что тогда останется? -- Я не вижу практической разницы между своим высказыванием и Вашим.
VLAN-порт как раз и занимается тем, что снимает тэг, указанный в его свойствах. То есть, судя по тому, что я вижу, у Вас есть тегированный трафик, который приходит в таки VLAN-порт, где тэг снимается и дальше в логику сервера идёт уже нетегированным. Вот именно эта -- одна из тех особенностей, которые я и пытался показать. Пунктом 2, если быть более точным.
Вот честно, я очень рад, что в комментариях так много людей, знающих вопрос лучше меня. И я буду еще больше рад, если скажем Вы (или кто угодно другой) напишите статью, где распишите подробнее те моменты, которые я упустил, включая разницу настройки тех же VLAN на разном оборудовании, сам с удовольствием её почитаю и скажу искреннее спасибо. Я сам всегда придерживаюсь позиции "критикуя -- предлагай" и другим советую действовать также. Лично мне вот того объёма информации, который я здесь привёл, не хватало на протяжении нескольких месяцев. И привёл тут я его с единственной целью -- помочь тем людям, которые попали в такую же ситуацию, как я раньше. И да, по нему лично я несколько железок от CRS до cAP ac. Перешитый свитч мы в этой конфигурации тоже смотрели, но на демо-стенде, где производительность конечно же было объективно не оценить.
И я буду еще больше рад, если из-за моей статьи начнётся холивар, по результатам которого подобных статей появится несколько, от разных авторов, дополняющих друг друга. :)
Ну, хорошо, добавил описание более стандартного механизма. На мой взгляд он не такой удобный, но это дело вкуса. И заодно ссылку на совсем официальную документацию.
Так конфигураций разных бывает много. Та, которую описываете Вы мне вот ни разу не пригождалась. Между двумя аппаратными портами может быть разница в том, что к одному порту влан должен быть подцеплен с тэгом, а к другому -- без, опять же, обычно речь идёт не про работу с одним портом, а про работу с разными... Короче, я описываю то, как можно начать понимать логику работы вланов, а не реализацию отдельно взятого случая.
Это всё отлично применимо ко всему, где есть Router OS, даже к тем свичам, которые перешиваются из Switch OS в Router OS, вне зависимости от аппаратной платформы.
fail2ban штука конечно хорошая, но вот случай, где он реально был нужен лично у меня был один за всю жизнь. :) Работал на государя и обслуживал сервис, аудитория которого была несколько миллионов человек, сервис был кривой «шо пипец», встроенных защит никаких… При этом он был веб естественно. И вот защищать систему от перебора паролей китайскими хакерами не было вообще никаких других вариантов. При чем благодаря fail2ban'у удалось реально снизить трафик через интерфейс. Прям чуть ли не в 2 раза. При этом интересно было то, что логи для анализа брались с другого сервера, находящегося в DMZ по SMB.
Во всех остальных случаях анализ пост-фактум показывал, что никакой полезной функции fail2ban не несёт. Ибо атака захлебывается еще на этапе подбора логина (root-то не имеет права доступа по ssh вообще), до подбора пароля ни разу не доходило.
Поэтому хотя я его по привычке обычно и ставлю, могу сказать, что на мой взгляд он не нужен 99% пользователей.
Да, отменно. Как скажем и ext4, что также проверено неоднократно. :)
Вы путаете изменение размера раздела и изменение размера файловой системы. Если на разделе есть LVM, то файловой системы там просто нет. Никакой. Только сам lvm.
А так, можно скажем виртуальный увеличить диск, который на машине имеет обозначение xvdc, после этого можно увеличить например раздел xvdc1, после этого можно увеличить файловую систему на разделе.
Геометрия устройства, раздела и файловой системы это 3 разные вещи.
И я пишу про то, что при работе с LVM удобнее избегать последних двух сущностей. Потому что несмотря на то, что изменять область диска, занятую файловой системой, удобно, не удобно перед этим расширять размер раздела.
А конкретно про сравнение lvm и xfs могу сказать, что на одном устройстве может быть скажем 10 разделов. И если понадобилось расширить скажем третий по счёту, то делать это с помощью расширения файловой системы не выйдет просто потому, что после конца раздела с этой файловой системой находится следующая область с данными и расширять раздел некуда. А с помощью lvm — легко и непринужденно, так что lvm всё-таки мощнее. Не зря же у гипервизоров внутри именно lvm.
Если есть отдельная СХД, то можно положить и туда. Но во-первых не у всех она есть: скажем, все облачные сервисы предоставляют устройство целиком, т.е. сервер с дисками без отдельной хранилки. А во-вторых, даже если СХД есть, во многих случаях это оптика и FC либо iSCSI, прикрепленный как раздел к гипервизору, куски которого уже потом раздаются виртуальным машинам как обычные диски.
Но даже если это будет именно nfs-шара, она будет не на том же разделе, где система. Да, она будет не в LVM'е на сервере, но я говорил что данные обязательно отделять. Если кому-то удобнее делать это по NFS, то пускай так, лишь бы рядом не лежали. :)
Вообще-то веб-сервер должен работать под отдельным непривелегированным пользователем, у которого даже shell в свойствах пользователя не прописан. И естественно доступ к файловой системе у него очень ограничен даже на чтение.
Конфиг апача (в котором указано всё, что апач реально может) взломщик сможет увидеть как при выключенном SELinux, так и при включенном.
Дернуть интерпретатор php — тоже. Получить доступ к телу сайта — опять же. Найти там логин-пароль от базы данных и получить к ней доступ через php — снова.
В итоге, что с SeLinux, что без него, злоумышленник скомпрометировав веб-сервер сможет поломать кусок базы данных (не всю, потому что сайт ходит к базе не под рутом естественно и права сильно урезаны) и всё.
Да, еще он сможет увидеть список сервисов, запущенных на сервере так, как будто фаерволла нет. Что при правильной настройке безопасности внутри самих сервисов (т.е. без использования безопасности через запутывание) ничем ему не поможет.
Удивительно. У меня вот более 60 линуксовых серверов в парке, потери данных на XFS были раза 2, раза 2 было, что при разбивке в XFS система просто отказывается ставиться через кикстарт (CentOS7)… Вручную-то переразбивал в ext4 и всё ставилось, а кикстарт просто обламывался. Пару раз было, что попадал на необходимость восстановления системы с первого попавшегося LiveCD, а он просто не умел xfs (флешка с живой системой, лежащая под рукой "внезапно" оказывалась старой), поэтому приходилось увозить с объекта диск в офис и разбираться там, а потом везти обратно… А проблем с ext4 лично у меня не было ни разу. Но спасибо за комментарии, учту, что такая статистика тоже есть.
P.S. С ext2 в лохматые годы такое было, да. И с ext3 тоже, но её тогда только выпустили и официально еще не рекомендовали в продакшн.
Вам прямо с цитатами из этой самой википедии показать чем именно она мне не нравится? :) -- Но если коротко, по ней очень сложно понять, как жить когда микротик ни хрена не основная часть сети, а очень даже вторичная.
Добавил подписку, буду ждать. :)
Вот я не готов мыслить пространствами и полями. Я как раз привык мыслить на уровне тэгов, поэтому и не заходит мне родная документация. Ну и собственно я думаю, что такой не один, поэтому и попытался перевести на привычную мне терминологию обычные описания.
Ну, тэг как виртуальное свойство пакета работает ровно как я написал, а тэг как набор бит в заголовке я честно говоря не представляю как проверить когда по факту пропадает потому, что из самой таблицы маршрутизации пакет для анализа не выдернуть. А с точки зрения поведения оборудования нет никакой разницы между "тэг 3 прописан в пакете, идущем в коммунаторе с другими пакетами" или "тэг 3 прописан в виртуальном коммутаторе, в котором идут только пакеты для этого тэга".
Ну вот есть у нас бридж, в нём два VLAN, номера 1 и 2. В свойствах бриджа прописан тэг 1, тэг 2 создан через создание влана в бридже.
В бридж добавляем один интерфейс VLAN с тэгом 2, ставим туда айпишник и еще на сам интерфейс бриджа ставим айпишник. И в довершение добавляем туда же физический порт, например 1, при этом в свойствах моста ставим тэг 1 опять же.
Снаружи с 1 порта в такой конфигурации можно снимать нетегированный 1 влан и тегированный второй и пинговать соответствующие адреса.
И в принципе можно считать, что это по факту два разных виртуальных коммутатора, один для 1 влана, второй для 2. И что пакеты, входящие без тэга отправляются в одну таблицу коммутации, а с тэгом 2 -- в другую.
Но если мы считаем, что мост всё-таки один, то логика нисколько не меняется: пакет приходит без тэга на внешний порт, попадает в мост без тэга (потому что тэг порта и моста совпадают) и идёт на интерфейс с адресом.
Или второй пакет приходит с тэгом 2, идёт в тот же мост, тэг с него не снимается потому, что в свойствах порта указан другой тэг, в единой таблице коммутации тэг присутствует, по нему пакет идёт к интерфейсу VLAN, где с него снимается тэг постольку, поскольку в свойствах этого порта тэг 2 указан. И дальше идёт на обработку кому он там пологается без тэга.
Или если говорить ближе к программированию, с точки зрения поведения, нет разницы между цифрой в столбце таблицы и цифрой-номером таблицы. А это же гайд для пользователей, а не для разработчиков микротов.
Ах да, еще не ответил на это:
Так это на всех интерфейсах, не только wlan: стоит где-то в свойствах интерфейса вписать номер тэга, этот тэг снимается после интерфейса. И я об этом написал в пункте 2.
Про капсман лично мне конкретно эта ссылка и не помогла (как и вагон еще всяких) потому что она как раз и даёт типовое решение вместо понимания вопроса. Мне нужно было заворачивать трафик из капсмана вместо микротика на другой узел через тегированный порт и прочитав статью я тогда не понял, как именно это реализовать. Вроде готовая конфигурация работает, а как ей "доработать напильником" не понятно.
Остальные ссылки добавил в статью, хотя на мой взгляд в материале, помеченном как tutorial обсуждать такие тонкости как "на этом чипе оно будет работать, но возможно будет тормозить из-за программной реализации" не совсем верно и я действительно считаю, что это должно быть в другой статье, которую всё ещё прошу написать Вас :).
Оба-на, вот про меню switch спасибо, реально не сталкивался. Покурю маны на эту тему с интересом.
А что тогда останется? -- Я не вижу практической разницы между своим высказыванием и Вашим.
Если Вы считаете, что надо было указать дополнительную ссылку -- кидайте её сюда, если она стоящая, я поправлю статью.
VLAN-порт как раз и занимается тем, что снимает тэг, указанный в его свойствах. То есть, судя по тому, что я вижу, у Вас есть тегированный трафик, который приходит в таки VLAN-порт, где тэг снимается и дальше в логику сервера идёт уже нетегированным. Вот именно эта -- одна из тех особенностей, которые я и пытался показать. Пунктом 2, если быть более точным.
Вот честно, я очень рад, что в комментариях так много людей, знающих вопрос лучше меня. И я буду еще больше рад, если скажем Вы (или кто угодно другой) напишите статью, где распишите подробнее те моменты, которые я упустил, включая разницу настройки тех же VLAN на разном оборудовании, сам с удовольствием её почитаю и скажу искреннее спасибо. Я сам всегда придерживаюсь позиции "критикуя -- предлагай" и другим советую действовать также. Лично мне вот того объёма информации, который я здесь привёл, не хватало на протяжении нескольких месяцев. И привёл тут я его с единственной целью -- помочь тем людям, которые попали в такую же ситуацию, как я раньше. И да, по нему лично я несколько железок от CRS до cAP ac. Перешитый свитч мы в этой конфигурации тоже смотрели, но на демо-стенде, где производительность конечно же было объективно не оценить.
И я буду еще больше рад, если из-за моей статьи начнётся холивар, по результатам которого подобных статей появится несколько, от разных авторов, дополняющих друг друга. :)
Ну, хорошо, добавил описание более стандартного механизма. На мой взгляд он не такой удобный, но это дело вкуса. И заодно ссылку на совсем официальную документацию.
Так конфигураций разных бывает много. Та, которую описываете Вы мне вот ни разу не пригождалась. Между двумя аппаратными портами может быть разница в том, что к одному порту влан должен быть подцеплен с тэгом, а к другому -- без, опять же, обычно речь идёт не про работу с одним портом, а про работу с разными... Короче, я описываю то, как можно начать понимать логику работы вланов, а не реализацию отдельно взятого случая.
Это всё отлично применимо ко всему, где есть Router OS, даже к тем свичам, которые перешиваются из Switch OS в Router OS, вне зависимости от аппаратной платформы.
Во всех остальных случаях анализ пост-фактум показывал, что никакой полезной функции fail2ban не несёт. Ибо атака захлебывается еще на этапе подбора логина (root-то не имеет права доступа по ssh вообще), до подбора пароля ни разу не доходило.
Поэтому хотя я его по привычке обычно и ставлю, могу сказать, что на мой взгляд он не нужен 99% пользователей.
Вы путаете изменение размера раздела и изменение размера файловой системы. Если на разделе есть LVM, то файловой системы там просто нет. Никакой. Только сам lvm.
А так, можно скажем виртуальный увеличить диск, который на машине имеет обозначение xvdc, после этого можно увеличить например раздел xvdc1, после этого можно увеличить файловую систему на разделе.
Геометрия устройства, раздела и файловой системы это 3 разные вещи.
И я пишу про то, что при работе с LVM удобнее избегать последних двух сущностей. Потому что несмотря на то, что изменять область диска, занятую файловой системой, удобно, не удобно перед этим расширять размер раздела.
А конкретно про сравнение lvm и xfs могу сказать, что на одном устройстве может быть скажем 10 разделов. И если понадобилось расширить скажем третий по счёту, то делать это с помощью расширения файловой системы не выйдет просто потому, что после конца раздела с этой файловой системой находится следующая область с данными и расширять раздел некуда. А с помощью lvm — легко и непринужденно, так что lvm всё-таки мощнее. Не зря же у гипервизоров внутри именно lvm.
Если есть отдельная СХД, то можно положить и туда. Но во-первых не у всех она есть: скажем, все облачные сервисы предоставляют устройство целиком, т.е. сервер с дисками без отдельной хранилки. А во-вторых, даже если СХД есть, во многих случаях это оптика и FC либо iSCSI, прикрепленный как раздел к гипервизору, куски которого уже потом раздаются виртуальным машинам как обычные диски.
Но даже если это будет именно nfs-шара, она будет не на том же разделе, где система. Да, она будет не в LVM'е на сервере, но я говорил что данные обязательно отделять. Если кому-то удобнее делать это по NFS, то пускай так, лишь бы рядом не лежали. :)
Вообще-то веб-сервер должен работать под отдельным непривелегированным пользователем, у которого даже shell в свойствах пользователя не прописан. И естественно доступ к файловой системе у него очень ограничен даже на чтение.
Конфиг апача (в котором указано всё, что апач реально может) взломщик сможет увидеть как при выключенном SELinux, так и при включенном.
Дернуть интерпретатор php — тоже. Получить доступ к телу сайта — опять же. Найти там логин-пароль от базы данных и получить к ней доступ через php — снова.
В итоге, что с SeLinux, что без него, злоумышленник скомпрометировав веб-сервер сможет поломать кусок базы данных (не всю, потому что сайт ходит к базе не под рутом естественно и права сильно урезаны) и всё.
Да, еще он сможет увидеть список сервисов, запущенных на сервере так, как будто фаерволла нет. Что при правильной настройке безопасности внутри самих сервисов (т.е. без использования безопасности через запутывание) ничем ему не поможет.
Удивительно. У меня вот более 60 линуксовых серверов в парке, потери данных на XFS были раза 2, раза 2 было, что при разбивке в XFS система просто отказывается ставиться через кикстарт (CentOS7)… Вручную-то переразбивал в ext4 и всё ставилось, а кикстарт просто обламывался. Пару раз было, что попадал на необходимость восстановления системы с первого попавшегося LiveCD, а он просто не умел xfs (флешка с живой системой, лежащая под рукой "внезапно" оказывалась старой), поэтому приходилось увозить с объекта диск в офис и разбираться там, а потом везти обратно… А проблем с ext4 лично у меня не было ни разу. Но спасибо за комментарии, учту, что такая статистика тоже есть.
P.S. С ext2 в лохматые годы такое было, да. И с ext3 тоже, но её тогда только выпустили и официально еще не рекомендовали в продакшн.