1. Инвентаризация до переноса

• версия FreeBSD и архитектура;
• список пакетов и сервисов;
• /etc/rc.conf, /etc/loader.conf, cron и локальные конфиги;
• сетевые интерфейсы, VLAN, маршруты и firewall;
• пулы ZFS или файловые системы UFS;
• сертификаты, SSH-ключи и данные приложений.

2. Для ZFS удобнее репликация

Если данные находятся на отдельных ZFS datasets, используйте snapshot и zfs send/zfs receive. Это сохраняет свойства datasets и хорошо подходит для полной или инкрементальной передачи.

zfs snapshot -r zroot/data@migrate
zfs send -R zroot/data@migrate | ssh newhost zfs receive -u backup/data

Для production сначала сделайте начальную передачу заранее, а перед переключением остановите изменяющие данные сервисы и отправьте финальную дельту.

3. Для UFS и обычных каталогов

Можно использовать rsync с сохранением прав, владельцев и времён. Особое внимание уделяйте ACL, extended attributes и файловым флагам — простое cp -r для системного переноса недостаточно.

4. Не копируйте сетевую конфигурацию вслепую

На новом сервере имена интерфейсов могут отличаться. До первого удалённого запуска подготовьте консольный доступ и проверьте rc.conf, default gateway, DNS, VLAN и правила PF/IPFW.

5. Проверка после переключения

• загрузка без ошибок;
• состояние ZFS и дисков;
• сеть и DNS;
• список слушающих портов;
• логи сервисов;
• права на данные;
• backup и мониторинг;
• работа приложений с реального клиента.

Итог: хороший перенос FreeBSD — это заранее протестированный план с резервной копией и возможностью вернуть старый сервер. ZFS значительно упрощает миграцию, но не отменяет проверку конфигурации и приложений.

Сообщение Перенос FreeBSD на новый сервер: ZFS, rsync, backup и проверка после миграции появились сначала на Clip-Clap.

1. Проверяем систему

freebsd-version
uname -a
ifconfig
netstat -rn
sockstat -4 -l
df -h

2. Устанавливаем Squid

pkg update
pkg install squid
squid -v
sysrc squid_enable=YES

3. Создаём резервную копию

mkdir -p /root/squid-backup
cp -a /usr/local/etc/squid/squid.conf /root/squid-backup/squid.conf.$(date +%F-%H%M)

4. Настраиваем squid.conf

cat > /usr/local/etc/squid/squid.conf <<'EOF'
http_port 192.168.1.10:3128
visible_hostname proxy-freebsd
acl localnet src 192.168.1.0/24
acl SSL_ports port 443
acl Safe_ports port 80 443
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access deny all
access_log stdio:/var/log/squid/access.log
cache_log /var/log/squid/cache.log
coredump_dir /var/squid/cache
EOF
squid -k parse

5. Готовим каталоги и запускаем сервис

service squid onestop 2>/dev/null || true
squid -z
service squid start
service squid status
sockstat -4 -l | grep 3128

6. Разрешаем порт в PF

Если PF уже используется, добавьте правило только для доверенной сети:

cp /etc/pf.conf /root/squid-backup/pf.conf.$(date +%F-%H%M)
echo 'pass in on em1 proto tcp from 192.168.1.0/24 to 192.168.1.10 port 3128' >> /etc/pf.conf
pfctl -nf /etc/pf.conf
pfctl -f /etc/pf.conf
pfctl -sr

Замените em1 на LAN-интерфейс сервера.

7. Проверяем с клиента

curl -I -x http://192.168.1.10:3128 http://example.com
curl -I -x http://192.168.1.10:3128 https://example.com

8. Проверяем журналы

tail -f /var/log/squid/access.log
tail -n 100 /var/log/squid/cache.log
grep -E 'TCP_MISS|TCP_TUNNEL|DENIED' /var/log/squid/access.log | tail -n 30

9. Перезагрузка конфигурации

squid -k parse
service squid reload
service squid status

10. Диагностика

sockstat -4 -l | grep squid
tcpdump -ni em1 tcp port 3128
service squid status
squid -k check
tail -n 200 /var/log/squid/cache.log

11. Rollback

service squid stop
cp /root/squid-backup/squid.conf.TIMESTAMP /usr/local/etc/squid/squid.conf
squid -k parse
service squid start
cp /root/squid-backup/pf.conf.TIMESTAMP /etc/pf.conf
pfctl -f /etc/pf.conf

Критерий успеха: Squid слушает только LAN-адрес на TCP 3128, HTTP и HTTPS через CONNECT открываются с клиента, запросы видны в access.log, а обращения не из доверенной сети получают отказ.

Сообщение Squid на FreeBSD: установка, ACL, HTTPS CONNECT и проверка работы появились сначала на Clip-Clap.

Пример рассчитан на следующую схему: внешний интерфейс em0 получает адрес от провайдера, внутренний em1 обслуживает сеть 192.168.10.0/24, а сам шлюз имеет LAN-адрес 192.168.10.1. Имена интерфейсов обязательно замените на свои.

1. Проверяем интерфейсы и маршруты

Сначала важно убедиться, что FreeBSD сама видит интернет и оба сетевых адаптера определились корректно. NAT не починит отсутствующий маршрут или неправильно назначенный адрес.

freebsd-version
ifconfig -a
netstat -rn
ping -c 3 1.1.1.1
fetch -qo- https://example.com | head

В таблице маршрутов должен быть маршрут default через WAN. Успешный ping по IP показывает, что связь есть; успешный fetch дополнительно подтверждает работу DNS и HTTPS.

2. Делаем резервную копию

Перед изменением сети сохраняем конфигурацию. Это особенно важно при удалённой работе: одна ошибка в PF может отрезать SSH.

mkdir -p /root/router-backup
cp /etc/rc.conf /root/router-backup/rc.conf.before
cp /etc/pf.conf /root/router-backup/pf.conf.before 2>/dev/null || true
sysrc -a > /root/router-backup/sysrc-before.txt
ifconfig -a > /root/router-backup/ifconfig-before.txt
netstat -rn > /root/router-backup/routes-before.txt

3. Назначаем адрес LAN-интерфейсу

Адрес 192.168.10.1 станет основным шлюзом для компьютеров внутри сети. Он должен быть статическим: если адрес шлюза изменится, клиенты потеряют доступ наружу.

sysrc ifconfig_em1="inet 192.168.10.1 netmask 255.255.255.0"
service netif restart em1
ifconfig em1

После применения интерфейс должен показывать адрес 192.168.10.1/24. Если вы подключены через этот интерфейс по SSH, перезапуск сети выполняйте только при наличии консоли или второго канала доступа.

4. Включаем маршрутизацию

По умолчанию FreeBSD принимает пакеты только для себя. Параметр gateway_enable разрешает пересылать их между LAN и WAN — именно это превращает сервер в роутер.

sysrc gateway_enable="YES"
sysctl net.inet.ip.forwarding=1
sysctl net.inet.ip.forwarding

Ожидаемый результат — net.inet.ip.forwarding: 1. Команда sysrc сохранит настройку после перезагрузки, а sysctl включает её сразу.

5. Создаём правила PF и NAT

PF выполняет две задачи. Первая — фильтрация: разрешить клиентам выходить наружу и запретить случайные входящие соединения. Вторая — NAT: подменить внутренние адреса одним адресом WAN-интерфейса.

cat > /etc/pf.conf <<'EOF'
wan = "em0"
lan = "em1"
lan_net = "192.168.10.0/24"

set skip on lo0
scrub in all

nat on $wan from $lan_net to any -> ($wan)

block all
pass out on $wan inet from ($wan) to any keep state
pass in on $lan from $lan_net to any keep state
pass in on $wan proto tcp from any to ($wan) port 22 keep state
EOF
pfctl -nf /etc/pf.conf

Команда pfctl -nf только проверяет синтаксис и ничего не применяет. Отсутствие вывода означает, что файл разобран успешно. SSH на WAN оставлен открытым в примере; лучше ограничить его своим административным IP.

6. Включаем PF

После успешной проверки включаем автозапуск и загружаем правила. Делайте это из консоли или держите открытой вторую SSH-сессию.

sysrc pf_enable="YES"
sysrc pf_rules="/etc/pf.conf"
service pf start
pfctl -f /etc/pf.conf
pfctl -sr
pfctl -sn
pfctl -si

pfctl -sr показывает правила фильтрации, -sn — NAT, а -si — общее состояние PF. Так мы проверяем не просто запуск службы, а фактическую загрузку нужной политики.

7. Раздаём клиентам адреса через DHCP

DHCP не обязателен для работы маршрутизации, но избавляет от ручной настройки каждого компьютера. Клиенты получат адрес, шлюз и DNS автоматически.

pkg install -y isc-dhcp44-server
sysrc dhcpd_enable="YES"
sysrc dhcpd_ifaces="em1"
cat > /usr/local/etc/dhcpd.conf <<'EOF'
authoritative;
subnet 192.168.10.0 netmask 255.255.255.0 {
  range 192.168.10.100 192.168.10.200;
  option routers 192.168.10.1;
  option domain-name-servers 1.1.1.1, 8.8.8.8;
  default-lease-time 3600;
  max-lease-time 86400;
}
EOF
service isc-dhcpd start
service isc-dhcpd status

8. Проверяем с клиентского компьютера

Проверку выполняем по уровням. Так сразу понятно, где именно проблема: адрес, шлюз, NAT или DNS.

ip addr
ip route
ping -c 3 192.168.10.1
ping -c 3 1.1.1.1
getent hosts example.com
curl -I https://example.com

Если шлюз пингуется, а 1.1.1.1 нет — проверяйте forwarding и PF. Если IP работает, но имя сайта не открывается — проблема почти наверняка в DNS, а не в NAT.

9. Смотрим трафик и счётчики

Когда «вроде всё настроено», но интернет не работает, пакеты лучше увидеть своими глазами. Сниффер покажет, доходят ли запросы до шлюза и выходят ли через WAN.

tcpdump -ni em1 host 192.168.10.100
tcpdump -ni em0 icmp
pfctl -vvs rules
pfctl -ss
service isc-dhcpd status
tail -f /var/log/messages

10. Безопасный rollback

Откат возвращает предыдущие файлы и отключает новые службы. Выполняйте его с локальной консоли, если доступ по сети уже потерян.

service isc-dhcpd stop 2>/dev/null || true
service pf stop
cp /root/router-backup/rc.conf.before /etc/rc.conf
cp /root/router-backup/pf.conf.before /etc/pf.conf 2>/dev/null || true
service netif restart
service routing restart

Критерий успеха: клиент получает адрес из диапазона 192.168.10.100–200, видит шлюз 192.168.10.1, пингует внешний IP, разрешает DNS-имена и открывает сайты. PF при этом показывает активные states и счётчики проходящего трафика.

Сообщение Роутер на FreeBSD: настраиваем NAT и PF с понятной проверкой каждого шага появились сначала на Clip-Clap.

Что получим в итоге

• две локальные сети будут обмениваться трафиком через зашифрованный туннель;
• межофисный трафик не попадёт под обычный NAT в интернет;
• firewall будет пропускать только нужные направления;
• появится понятный порядок диагностики;
• будет готов сценарий быстрого отката.

1. Рисуем схему

Офис A LAN: 192.168.10.0/24
Офис A WAN: 203.0.113.10
Офис B LAN: 192.168.20.0/24
Офис B WAN: 198.51.100.20
Тестовый сервер A: 192.168.10.10
Тестовый сервер B: 192.168.20.10

Подсети не должны пересекаться. Если обе стороны используют, например, 192.168.1.0/24, маршрутизатор не сможет понять, где находится адрес назначения.

2. Проверяем базовую доступность

ping 198.51.100.20
traceroute 198.51.100.20
nslookup vpn-office-b.example.ru

До настройки туннеля обе стороны должны видеть внешние адреса друг друга. Если один офис находится за CGNAT, обычный входящий IPsec может не подняться без дополнительной схемы.

3. Настраиваем IKE

На обеих сторонах должны совпадать версия IKE, алгоритмы шифрования, хэш, группа Диффи—Хеллмана, время жизни и способ аутентификации. Для нового туннеля разумно использовать IKEv2, AES-GCM или AES-CBC с SHA-256 и современную DH-группу.

• тип: site-to-site;
• IKE: IKEv2;
• аутентификация: общий PSK или сертификаты;
• локальный peer: внешний адрес офиса A;
• удалённый peer: внешний адрес офиса B;
• DPD: включён;
• NAT-T: включён.

PSK должен быть длинным и уникальным. Не используйте пароль от администратора или название компании.

4. Настраиваем локальные и удалённые сети

На стороне A локальная сеть — 192.168.10.0/24, удалённая — 192.168.20.0/24. На стороне B эти значения меняются местами. Именно эти selectors определяют, какой трафик попадёт в Child SA.

5. Исключаем VPN-трафик из NAT

Общий masquerade для выхода в интернет не должен менять адреса пакетов между офисами. В ИКС создайте правило исключения выше общего NAT: источник 192.168.10.0/24, назначение 192.168.20.0/24, действие — не выполнять NAT. На второй стороне сделайте зеркальное правило.

Если исключение стоит ниже общего masquerade, туннель может подняться, но пакет уйдёт с неправильным исходным адресом.

6. Настраиваем firewall

• разрешите UDP 500 между внешними адресами;
• разрешите UDP 4500 для NAT-T;
• разрешите ESP, если он используется напрямую;
• разрешите транзит из 192.168.10.0/24 в 192.168.20.0/24;
• создайте зеркальное правило на второй стороне.

Для первого теста можно разрешить ICMP и один конкретный сервис, например TCP 22 или 443. Не открывайте всю удалённую сеть навсегда только ради удобства.

7. Проверяем установление туннеля

В интерфейсе ИКС проверьте IKE SA и Child SA. В рабочем состоянии должны быть видны внешний peer, согласованные алгоритмы, локальная и удалённая сети, время жизни и счётчики переданных байтов.

ping -c 3 192.168.20.10
traceroute 192.168.20.10
nc -vz 192.168.20.10 443

Проверяйте с реального хоста внутри LAN, а не только со шлюза. Трафик со шлюза может идти с другим исходным адресом и не попадать под нужный selector.

8. Проверяем обратный маршрут

Если запрос доходит до удалённого сервера, но ответа нет, проверьте его шлюз по умолчанию. Ответ должен вернуться через ИКС удалённого офиса, а не через другой маршрутизатор.

ip route
route print
traceroute 192.168.10.10

9. DNS между офисами

Если доступ по IP работает, а по имени нет, сам IPsec уже исправен. Настройте forwarding нужной внутренней DNS-зоны или выдайте клиентам DNS-сервер, который знает записи второго офиса.

nslookup server-b.corp.local
dig server-b.corp.local A
nslookup server-b.corp.local 192.168.20.2

10. MTU и зависающие соединения

IPsec добавляет служебные заголовки. Поэтому маленький ping может работать, а RDP, HTTPS или передача файлов — зависать. Проверьте путь пакетами с запретом фрагментации.

ping -M do -s 1400 192.168.20.10
ping -M do -s 1360 192.168.20.10

Если меньший пакет проходит, а больший нет, уменьшите MTU/MSS на туннеле или устраните блокировку ICMP Fragmentation Needed.

11. Что означают типовые ошибки

• no proposal chosen — не совпадают алгоритмы;
• authentication failed — неверный PSK или сертификат;
• traffic selectors unacceptable — не совпадают локальные и удалённые сети;
• SA поднята, байты не растут — трафик не попадает в selector, мешает NAT или маршрут;
• работает только в одну сторону — firewall или обратный маршрут.

12. Откат

Перед изменениями экспортируйте конфигурацию ИКС и сделайте скриншоты текущих NAT и firewall правил. Для отката отключите новый туннель, удалите только созданные для него исключения NAT и правила доступа, затем восстановите прежнюю конфигурацию.

Критерий успеха: Child SA установлена, счётчики растут, тестовые хосты видят друг друга в обе стороны, внутренние имена разрешаются, крупные соединения не зависают, а межофисный трафик не маскируется внешним адресом.

Сообщение IPsec site-to-site на ИКС: как связать две сети и не запутаться в NAT появились сначала на Clip-Clap.

Nginx или Apache

Nginx удобен как лёгкий веб-сервер и reverse proxy. Apache остаётся хорошим выбором для проектов, которые зависят от его модулей и конфигурационной модели. Не ставьте оба «на всякий случай»: сначала определите, кто слушает 80/443 и какую роль выполняет второй компонент, если он вообще нужен.

Установка через pkg

На обычном сервере проще использовать бинарные пакеты FreeBSD. После установки включите нужную службу через rc-систему и проверьте её запуск после reboot. Не ограничивайтесь ручным стартом daemon в текущей сессии.

PHP лучше запускать отдельно

Для Nginx обычно используют PHP-FPM. Для Apache также имеет смысл отделять PHP-процессы там, где это упрощает управление ресурсами и обновления. Сокет или TCP-порт PHP-FPM не должен быть без необходимости доступен извне.

Сначала минимальный сайт

До установки CMS поднимите простой статический virtual host и убедитесь, что HTTP работает. Затем добавляйте PHP, базу данных, reverse proxy и TLS по одному слою. Такая последовательность сильно упрощает диагностику 403, 404, 502 и проблем с правами.

TLS и сертификаты

Для публичного сайта используйте HTTPS. Сертификат можно получать автоматически через ACME-клиент. Важно не только получить сертификат один раз, но и проверить автоматическое продление и безопасный reload веб-сервера после обновления файлов.

Проверка конфигурации перед reload

Перед применением изменений используйте штатную проверку синтаксиса выбранного веб-сервера. Только после успешного теста выполняйте reload. Это простое правило спасает от ситуации, когда одна опечатка одновременно кладёт все виртуальные хосты.

Firewall и права

Снаружи обычно нужны только 80/443, а SSH лучше ограничить административной сетью или VPN. Каталоги сайта не должны быть без причины доступны на запись пользователю веб-сервера. Отдельно защищайте файлы конфигурации приложения с паролями и ключами.

Логи и резервное копирование

Собирайте access/error logs, настройте rotation и следите за свободным местом. В backup должны входить не только файлы сайта, но и база данных, конфигурация веб-сервера, TLS/ACME-настройки и инструкция восстановления. Проверяйте restore на отдельной машине.

После обновлений

После обновления пакетов проверьте конфигурацию, версии PHP-модулей, доступ к базе и ключевые URL сайта. Для production-сервера полезно сначала обновлять копию или staging, особенно если меняется major-версия PHP или базы данных.

Итог: веб-сервер на FreeBSD лучше собирать как набор простых слоёв: ОС → сеть → веб-сервер → приложение → TLS → мониторинг → backup. Тогда проблема в одном компоненте не превращается в загадку на весь вечер.

Сообщение Веб-сервер на FreeBSD: Nginx или Apache, PHP, TLS и безопасный запуск появились сначала на Clip-Clap.

Проверьте версию и обновления

Начните с проверки версии системы и убедитесь, что она ещё поддерживается. Для бинарно установленной FreeBSD системные обновления ставятся штатными средствами FreeBSD, а сторонние приложения обновляются отдельно через pkg. Не смешивайте обновление base system и пакетов в одну непрозрачную команду из старой статьи.

Настройте имя хоста и сеть

Постоянные сетевые настройки обычно хранятся в /etc/rc.conf. Для сервера задайте понятный hostname, статический адрес либо осознанно оставьте DHCP. После изменений отдельно проверяйте IP, default route и DNS — рабочий ping по IP ещё не означает, что разрешение имён настроено правильно.

Установите пакеты через pkg

Для большинства серверных задач удобнее использовать готовые бинарные пакеты. Ports Collection полезна, когда нужны особые compile-time опции, но она усложняет сопровождение. На обычном сервере держите способ установки максимально единообразным.

Не работайте постоянно под root

Создайте отдельного пользователя администратора и выдайте ему только необходимые привилегии через sudo или doas. Root оставьте для аварийного доступа и локальной консоли. Это снижает цену случайной ошибки и упрощает аудит действий.

SSH: сначала доступ, потом ужесточение

Добавьте SSH-ключ администратора, проверьте вход в отдельной сессии и только после этого отключайте ненужные методы аутентификации. Не закрывайте текущую рабочую сессию до проверки нового доступа. Для публичного сервера ограничьте доступ firewall и не публикуйте лишние службы наружу.

Службы и rc.conf

FreeBSD запускает сервисы через rc-систему. После установки пакета недостаточно просто один раз стартовать daemon: нужная служба должна быть явно включена для следующей загрузки. Проверяйте статус после reboot, а не только сразу после ручного запуска.

Время, логи и резервные копии

Правильное время критично для TLS, журналов, Kerberos и многих распределённых сервисов. Проверьте NTP и часовой пояс. Затем определите, какие каталоги и конфиги входят в backup, где хранится копия и как выглядит реальный restore-test.

Короткий чек-лист готовности

• система находится на поддерживаемой ветке;
• IP, gateway и DNS переживают reboot;
• администратор входит по SSH-ключу;
• root не используется для повседневной работы;
• обновления base и packages понятны и контролируются;
• лишние сервисы не слушают внешние интерфейсы;
• backup не только создаётся, но и восстанавливается.

Итог: базовая настройка FreeBSD — это не набор твиков, а создание системы, которую можно безопасно обновить, перезагрузить и восстановить без сюрпризов.

Сообщение Настройка FreeBSD после установки: сеть, pkg, SSH, обновления и сервисы появились сначала на Clip-Clap.

Что подготовить до установки

• резервную копию данных, если диск уже использовался;
• актуальный образ для вашей архитектуры;
• доступ к консоли сервера или виртуальной машине;
• IP-адрес, шлюз и DNS, если будет статическая сеть;
• понимание, нужен ли вам ZFS или достаточно UFS.

Какой образ выбрать

Для обычной установки на физический сервер или VM подходит установочный ISO/USB-образ. Для облака и некоторых гипервизоров удобнее готовые виртуальные диски. FreeBSD также публикует отдельные SD-card images для поддерживаемых ARM-платформ.

ZFS или UFS

ZFS удобна для серверов: контрольные суммы, snapshots, datasets, compression и гибкое управление пулом. Но зеркало или RAID-Z не заменяют резервную копию. Для небольших VM и максимально простой системы UFS всё ещё может быть достаточным вариантом.

Установка через bsdinstall

Загрузитесь с установочного носителя и выберите Install. Дальше мастер предложит раскладку клавиатуры, имя хоста, компоненты системы, разметку диска, пароль root, сеть, часовой пояс, создание пользователя и службы автозапуска. Перед подтверждением записи разметки внимательно проверьте выбранный диск: после commit данные на нём будут перезаписаны.

Сеть и DNS

На первом запуске проверьте адрес интерфейса, маршрут по умолчанию и DNS. Для сервера со статическим IP лучше сразу зафиксировать настройки в rc.conf, а не оставлять временную конфигурацию из консоли. После этого проверьте доступ к шлюзу и разрешение DNS-имён отдельно.

Что сделать сразу после установки

• установить обновления безопасности;
• создать обычного администратора и не работать постоянно из root;
• настроить SSH-ключи и ограничить удалённый вход;
• проверить время и NTP;
• установить нужные пакеты через pkg;
• настроить резервное копирование до ввода сервера в эксплуатацию.

Минимальная проверка после первого reboot

Проверьте, что система загружается без ошибок, пул или файловая система доступны, сеть поднимается автоматически, SSH работает только так, как задумано, а обновления устанавливаются без конфликтов. Только после этого имеет смысл ставить веб-сервер, базы данных и прикладные сервисы.

Итог: хороший сценарий установки FreeBSD начинается не с копирования старых команд, а с выбора поддерживаемой ветки, понятной схемы хранения и минимальной защиты. Чем меньше ручных «магических» настроек на первом этапе, тем проще потом обновлять и восстанавливать сервер.

Сообщение Установка FreeBSD: выбор версии, ZFS, сеть и базовая защита появились сначала на Clip-Clap.