Комментарии 7
Конечно, мы понимаем, что для многих эта статья не станет открытием. Но, поскольку на Habr время от времени появляются статьи для начинающих администраторов, а также ввиду того, что эта статья появилась из реального письма реальному клиенту, мы всё же поделимся этой информацией и здесь.
О, да. Я помню те дни, когда впервые начал играться с маршрутами, таблицами и NATом. Примеры — это наглядно и хорошо, особенно, если тот кто читает, напечатает ту картинку из статьи и проходя по пунктам на ней будет делать пометки об мутации пакета и маршрутов, но пока сам не начнёшь руками строить сеть, пусть и виртуальную, пока не получишь первое своё кольцо или блэкхол — как говорится отличие теории и практики. Ну а после вдумчивого чтения мана на файерволл (для меня это был ipfw в FreeBSD) уже практически белых пятен не остаётся. Хорошая статья, особенно для тех, кто только встал на путь сетевого администрирования.
PS Но начинать всё же лучше без привлечения облака, там такая магия иногда происходит — просто туши свет кидай гранату. У меня есть много личных примеров, что трассировка между 2мя хостами у разных провайдеров в одном городе. Если трассировать из пункта А в Б, то всего 6 хопов, все логичные. Если обратно, то почти 12, половина вообще не понятно чьи. Начинающим лучше построить цепочку из 3х — 4х сетей, где крайние сети не видят напрямую друг друга и маршрутизируются через другую сеть. Пусть статичными маршрутами, зато будет понятна сама логика как это работает. Ну а после поднятия определенного уровня можно уже подключать NAT и облако.
В наш век виртуализации можно вообще наплодить кучу виртуальных машин и соединять их в самые причудливые сети. 20 годков назад я о таком и не мечтал. Правда, самая первая vmware как раз где-то в это время и появилась, я даже смог найти ей некоторое применение, но на несколько виртуальных машин мне тогда точно не хватило бы ресурсов, работал я тогда в очень скромном в плане ресурсов месте. :-)
— В.М.
— В.М.
О мой всевышний! Может можно было как-то проще, через Ethernet-over-IP поверх туннеля и в нем МАК-бриджинг?
Я, честно говоря, не вижу тут ничего сложного, хотя при необходимости в самом деле можно было объединить их в одну IP-сеть. Только тут именно должны быть разные IP-сети, поскольку, когда таких офисов будет подключаться несколько, объединять их всех в одну широковещательную сеть было бы, мягко говоря, не очень разумно. =)
— В.М.
— В.М.
Я помню реальную историю объединения двух корпусов одного учреждения через радиомост на основе Cisco BR350 лет 16 назад. Так вот, пока сети были разрознены и почта ходила через MDaemon путём прямого прозвона модемом обе сети предыдущий админ настроил в одной подсети. Когда встал вопрос объединения для повышения качества хождения почты и не только уже тогда я изменил подсеть одного корпуса специально, чтобы исключить ненужный флуд в радиосети, т.к. она же полудуплексная. Яркий пример, почему не следует объединять 2 сети через TAP. Однако, бывают исключения, ну или когда подключается только 1 клиент, тогда TAP самое подходящее, чтобы заработало сразу и из коробки, без вникания в тонкости всяких маршрутизаций и фильтраций.
Насколько я помню, в микротиках можно было как-то настраивать фильтрацию по мак-адресам? Т.е. всё что приходит с определенного порта (eoip1) маркировать определенным образом и не пропускать эти фрэймы на какие-то ресурсы внутри ether1?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что происходит при соединениях внутри и вне VPN-туннеля