pfg21, сотни тысяч сетевых инженеров в Яндексе, Гугле, Клаудфлере, AWS, да в любой другой организации от мала до велика, а так же тысячи преподавателей курсов по Циске, Микротику, Джуниперу или любому другому сетевому вендору, а так же преподаватели вузов - с вами не согласятся.
Почему - я не смогу вам это объяснить в двух словах в ответе на комментарий. Да и вам по всей видимости эти объяснения и не требуются, вы всё и так знаете :)
pfg21, камон, а что мешает для защиты от скана сделать нормально закрытый фаерволл? Как и для IPv4.
Вот есть у меня закрытый фаер. На компах белые адреса (не важно, IPv4 или IPv6, для упрощения мышления предположим IPv4). То есть NAT здесь отсутствует. Каким образом кто-то снаружи за фаером должен несанкционированно увидеть, что у меня самба открыта, и попасть на неё? (Даже зная логин и пароль от самбы).
Про ошибки в настройке фаера сейчас не говорим, предполагаем, что настроен корректно. Для простоты - возьмём дефолтный фаер микротика, который изнутри наружу выпускает свободно, а снаружи внутрь впускает только ответы на запросы отправленные изнутри.
Sanes, подсети известно для чего нужны. Но скорее всего вы имеете ввиду серые адреса, которые принято использовать в компаниях. Но вот есть нюанс - использование серых адресов было придумано только потому, что белый адресов IPv4 весьма мало. Но ничего не мешает использовать для локальной сети белые IPv4 адреса. Арендуйте их у провайдера, и работайте на здоровье.
У IPv6 проблема недостатка адресов отсутствует принципиально, потому там совсем не обязательно использование серых сетей. Предупрежу вопрос про безопасность - нет, NAT =/= безопасность. Нат просто прячет серый адрес на белым, не более. А за безопасность должен отвечать фильтр файрволла. Если на компе белый адрес, но на роутере (к слову, не всегда именно на роутере, есть и другие варианты) настроен фаер правильно, то извне на этот адрес никто лишний не постучится, точно так же как и в случае с IPv4. Невозможность добраться до компа обеспечивает не NAT, а корректно настроенный фильтр.
Да, в IPv6 тоже есть NAT, и им тоже можно пользоваться. Но в 99,9% случаев смысла в этом нет. Ну можно его использовать по привычке, если нет чёткого понимания работы сетей и IPv6 в частности, то есть настроить сетевое железо похожим образом как для работы с привычным IPv4. Но тогда в IPv6 действительно теряется тот смысл, который был заложен изначально (чтобы всем хватило адресов без использования NAT).
Технически, NAT есть смысл воспринимать как хорошо прижившийся костыль, без которого невозможно было жить при IPv4, но который оказывается совершенно ненужным при использовании IPv6.
John Smith, тогда спасёт Mikrotik Audience. Дорогой, как крыло от самолёта :)
Но нужно настраивать вручную (может и можно по кнопке, но я привык делать так, как нужно мне). Одна радиокарта в 5 ГГц с 4 чейнами для связи между точками, и две карты - 2,4 и 5 ГГц с 2 чейнами на каждую - для подключения клиентов.
Соединяем их все между собой через WDS, а дальше коммутируем WDS-линки либо через их mesh-протокол (настраивается почти аналогично бриджу, либо в бридж с включённым rstp). А радиоинтерфейсы заводим в CAPsMAN. Работает на ура.
Зависит от потребностей. OVPN до сих пор работает на одном ядре (и в RouterOS 7 также пока), да ещё и не умеет в UDP (в RouterOS 7 умеет уже). Если офисов немного, то может хватить и одного ядра достаточно производительного роутера (3011, 4011, CCR). Но с большим количеством объектов будет проседать скорость.
Алексей, по всей видимости Вы меня неправильно поняли. Я имел ввиду сугубо SSTP. На нём нет поддержки IPsec в принципе, но у него своё шифрование весьма неплохое. И это шифрование не разгружается аппаратно. Но SSTP на Микротике хотя бы использует все ядра процессора, в отличие от OpenVPN.
Шифрованный sstp, увы, медленный весьма. И аппаратной разгрузки нет принципиально. Хоть и размазывается нагрузка на все ядра. В этом контексте sstp - часто это то крайний вариант, где ничего другого применить нельзя. Именно потому что этот пролезет вообще везде :)
EoIP не всегда лучшее решение. Его есть смысл ставить там, где нужно пробросить L2 через L3, что случается нечасто, в большинстве случаев задачу можно решить с помощью маршрутизации. Тем не менее я сам ранее был фанатом EoIP. :) По факту - мы получаем дополнительнкю инкапсуляцию в туннеле IpIp. В целом EoIP хорош, у него есть мак-адреса с обоих концов туннеля, и порой это очень выручает. Но, как и всё остальное, его есть смысл пихать туда, где он реально нужен.
Тут же IpIp вполне справится, а в большинстве случаев достаточно L2TP/IPsec.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Почему - я не смогу вам это объяснить в двух словах в ответе на комментарий. Да и вам по всей видимости эти объяснения и не требуются, вы всё и так знаете :)