Перевод: Сгибнев Михаил Примечание: оригинал документа находится здесь: http://www.netbsd.org/Documentation/network/pppoe/, в документе очень много лишнего, что и было убрано. Поддержка в ядре Необходимо убедиться, что PPPoE поддерживается ядром. Для этого выполните команду: -bash-3.00$ ifconfig -C bridge vlan gif gre tun tap strip sl pppoe ppp lo Если в строке вывода не…
Continue reading: Настройка клиента PPPoE в NetBSDРубрика: Статьи
- Принцип работы CARP
- Конфигурирование CARP
- Включение поддержки CARP
- Пример CARP
- Расширенная конфигурация CARP
- Принудительное понижение роли
Аббревиатура CARP расшифровывается как Common Address Redundancy Protocol. Основной целью этого протокола является использование одного IP адреса в пределах одного сегмента сети несколькими машинами. CARP является свободной, безопасной альтернативой протоколам Virtual Router Redundancy Protocol и Hot Standby Router Protocol.
CARP позволяет выделить группу хостов в сегменте сети и назначить ей один IP адрес. Такая группа называется «redundancy group» (группа избыточности). В пределах этой группы, один из хостов становится «главным», а остальные обозначаются как «резервные». В каждый момент времени мастер-хост отвечает на ARP-запросы к назначенному IP адресу и обрабатывает трафик, идущий к этому адресу. Каждый хост одновременно может принадлежать к нескольким группам.
Одним распространенным случаем использования CARP является создание избыточности на брандмауэрах. Виртуальный IP, который назначен на группу избыточности, указан на клиентских машинах в качестве шлюза по умолчанию. В случае отказа брандмауэра, выполняющего роль мастера, резервный брандмауэр возмет этот IP адрес и продолжит обслуживание клиентов.
При использовании CARP снижаются требования к аппаратному обеспечению отказоустойчивых систем. Дорогое оборудование окажется бессильным к выдернутому шнуру питания или перед администратором, случайно отправившим сервер в перезагрузку. CARP также облегчает процесс обновления программного обеспечения, так цикл обновления и перезагрузки прозрачен для пользователей, становится проще и процесс тестирования программного или аппаратного обеспечения — вы всегда можете положиться на резерв, пока не устраните проблему.
Однако, есть ситуации, когда CARP не может помочь. Дизайн CARP требует, чтобы члены одной группы физически находились в одной подсети с одним статическим IP адресом, хотя с введением директивы carpdev необходимости назначать адрес на физический интерфейс нет. Сервисы, требующие постоянного соединения с сервером (такие как SSH и IRC) не могут быть прозрачно переброшены в случае отказа и потребуют переподключения. CARP не может синхронизировать данные между приложениями.
CARP поддерживает IPv4 и IPv6.
Continue reading: Введение в Common Address Redundancy Protocol
Архитектура i386 содержит в себе массу функций, призваных обеспечить совместимость со старыми машинами, вплоть до серии 8086. С технической точки зрения, в этом нет необходимости, так как любой современный компьютер, основанный на этой архитектуре использует полностью 32-разрядную операционную систему, которая могла работать и без кода, обеспечивающего обратную совместимость. К сожалению, требования к совместимости остаются и тормозят развитие нового программного обеспечения.
Одной из деталей, которая не изменялась в течение многих лет является процесс загрузки i386. Спроектирован он был в дни, когда компьютеры имели накопители на гибких магнитных дисках и небольшое firmware. С тех пор процедура не перенесла никакого изменения, что делает некоторые задачи очень сложными. Одна из них — загрузка нескольких операционных систем на одной машине.
Новое firmware для Intel-based машин, Extensible Firmware Interface (EFI) решает эту проблему, обеспечивая более универсальный процесс загрузки. Другие архитектуры уже предоставляют улучшенные firmware с более хорошими механизмами загрузки, включая, например, способность загрузки и выполнения ELF обряза прямо из кода инициализации машины. Так обстоит дело с OpenFirmware в Macintosh PowerPC.
Continue reading: Обзорная статья, посвященная поддержке технологии Multiboot в NetBSD 4Давно известно, что в сетях некоторых провайдеров, есть проблемы с поднятием VPN из под FreeBSD.
Пару лет назад наткнулся на эту проблему в своей сети, не стал долго думать и поставил железный роутер и был доволен. Но, как известно, человек предполагает, а инет располагает. В общем назрела эта проблема вновь. Гугление выдает великое множество ссылок на различные рецепты шаманских танцев с бубном и без оного, но мне не удалось найти ни одного нормального описания приводящего к желаемому результату. Однако поднять VPN-туннель у меня получилось 🙂
На самом деле, все элементарно.
На FeeBSD 6.2 с mpd4-4.0b4 все поднимается на ура.
Ниже рецепт на примере одной сети:
Continue reading: VPN тунель под FreeBSD