Записки сисадмина

Делимся опытом

07.11.2011

Трансляция видеопотока с помощью vlc

автор @ 23:39. Tags: ,
Категории: Заметки

Имеется камера, которая отдает видеопоток по протоколу RTSP. Нужно ретранслировать это видео в формате FLV.

Есть сервер с установленным Debian Squeeze. Установим VLC из стандартного репозитория, без поддержки Иксов:

# aptide install vlc-nox

Сборка VLC из стандартного репозитория не содержит несвободных кодеков. Однако, видео в FLV1 кодируется кодеком H.263, который по умолчанию поддерживается.

VLC в простых случаях, можно все параметры задать из командной строки. Но можно воспользоваться VLM — это такой командный интерфейс, чтобы в рамках одного запущенного VLC манипулировать несколькими разными потоками, изменяя конфигурацию не лету.
команды VLM можно задавать через telnet интерфейс, а можно их все записать в отдельный конфигурационный файл, и все они выполнятся последовательно при старте.
Я VLM планировал использовать ради встроенного шедулера, который по расписанию будет переключать источники трансляции, но встроенный шедулер работал как-то странно, и от него пришлось отказаться в пользу старого добного системного cron`а, который запуская скрипты в нужное время, перезаписывал vlm.conf и перезапускал VLC.

init скрипт запуска VLC:

#!/bin/sh

### BEGIN INIT INFO
# Provides: vlc
# Required-Start: $all
# Required-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: starts the VLC
# Description: starts VLC using start-stop-daemon
### END INIT INFO


PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/vlc
LOG=/var/log/vlc/vlc.log
USER=vlc

OPTIONS="-I 'telnet' --daemon --loop --telnet-password Passw0rd \
         --file-logging --logmode text --logfile ${LOG} -vvv \
   	 --logo-file /home/vlc/logo.png --logo-x 3 --logo-y 3 \
	 --vlm-conf=/etc/vlc/vlm.conf --no-sout-audio"

DESC=vlc

test -x $DAEMON || exit 0

case "$1" in
start)
	echo "Starting $DESC: \n"
	su - ${USER} -c "echo $(date) > $LOG"
	su - ${USER} -c "$DAEMON $OPTIONS"
	sleep 1
;;
stop)
	echo "Stopping $DESC: \n"
	ps -U ${USER} | grep vlc | awk '{print $1}' | xargs kill
;;
restart|force-reload)
	$0 stop
	sleep 1
	$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}" >&2
exit 1
;;
esac

exit 0

файл /etc/vlc/vlm.conf

new camera_1 broadcast enabled loop
setup camera_1 input "rtsp://xx.xxx.xxx.xx:554/cam0_0"
setup camera_1 output "#transcode{vcodec=FLV1,width=720,height=576,scale=1,vb=2048,fps=16,sfilter=logo:marq{marquee=%Y-%m-%d %H:%M:%S,position=10,size=12}}:standard{access=http,dst=0.0.0.0:8080/stream.flv}"
control camera_1 play

Пи перекодировании в левом верхнем углу будет вставляться логотип из PNG файла, а в нижнем правом текущее системное время.

Лог VLC будет вести в файл /var/log/vlc/vlc.log (нужно позаботиться чтобы пользователь, под которым работат VLC, имел право на запись в этот файл)

Для истории выкладываю вариант vlm.conf с неработающим шедулером. Может в свежих версия VLC это поправили, или я где-то не докрутил…

VLC должен днем транслировать видео с камеры, а ночью показывать видео из фала video.avi

/etc/vlc/vlm.conf:

new camera_1 broadcast enabled loop
setup camera_1 input "rtsp://xx.xxx.xxx.xx:554/cam0_0"
setup camera_1 output "#transcode{vcodec=FLV1,width=720,height=576,scale=1,vb=2048,fps=16,sfilter=logo:marq{marquee=%Y-%m-%d %H:%M:%S,position=10,size=12}}:standard{access=http,dst=0.0.0.0:8090/stream.flv}"
#control camera_1 play

new some_video broadcast enabled loop
setup some_video input "/home/vlc/video.avi"
setup some_video output "#transcode{vcodec=FLV1,width=704,height=384,scale=1,vb=2816,fps=20,sfilter=logo:marq{marquee=%Y-%m-%d %H:%M:%S,position=10,size=12}}:std{access=http,dst=0.0.0.0:8090/stream.flv}"
control some_video play

# start at 08:00h
new program_day schedule date 2011/1/1-08:00:00 enabled
# repeat every day (every 24h)
setup program_day period 0/0/1-0:0:0
# stop cam1, play some_video
setup program_day append control some_video stop
setup program_day append control camera_1 play

# start at 20:00h
new program_night schedule date 2011/1/1-20:00:00 enabled
# repeat every day (every 24h)
setup program_night period 0/0/1-0:0:0
# stop some_video, play camera_1
setup program_night append control camera_1 stop
setup program_night append control some_video play

06.07.2011

ip sla, NAT и два провайдера

автор @ 11:48. Tags:
Категории: Статьи

Имеется маршрутизатор cisco 1812 с IOS 15.1(2)T1. Он подключен к двум провайдерам. Пользователи выходят в Интернет через NAT. Требуется, при падении одного провайдера, автоматически переключаться на резервного.

FastEthernet0 — подключен к первому провайдеру
FastEthernet1 — подключен ко второму провайдеру

Мы настраиваем NAT с помощью маршрутных карт, чтобы трафик, идущий по дефолтному маршруту через первого провайдера — НАТился на интерфейсе FastEthernet0, а трафик идущий через второго — НАТился на FastEthernet1.

Создадим акцесс-лист, который будет определять, какие адреса будут выходить в Интернет через NAT:

ip access-list standard iUsers
 permit 10.10.132.0 0.0.0.255
 permit 10.10.136.0 0.0.0.255
 permit 10.10.153.0 0.0.0.255
 permit 10.10.145.0 0.0.0.255

Создадим маршрутную карту для первого провайдера:

route-map ISP1 permit 10
 match ip address iUsers
 match interface FastEthernet0

Создадим маршрутную карту для второго провайдера:

route-map ISP2 permit 10
 match ip address iUsers
 match interface FastEthernet1

Теперь создадим правила трансляции для каждого провайдера в соотвествии с маршрутными картами:

ip nat inside source route-map ISP1 interface FastEthernet0 overload
ip nat inside source route-map ISP2 interface FastEthernet1 overload

Теперь нужно как-то определять, доступность Интернета через провайдеров. Поможет нам в этом механизм IP SLA. Он обладает достаточно большими возможностями, но мы будем использовать icmp-echo.
Так как трафик через второго провайдера должен идти только в случае неработоспособности первого, настроим статический дефолтовый роутинг с разными приоритетами.
Дефолтовый маршрут через второго провайдера имеет приоритет 100, через первого 10.
Дефолтовый маршрут через первого провайдера существует до тех пор, пока пингуется какой-то хост в Интернете.
Если хост перестает пинговаться, через заданное время маршрут с приоритетом 10 убирается, и трафик начинает идти через второго провайдера.

Для надежности, мы будем пинговать два хоста в Интернете, и только если недоступны одновременно оба — переключаться на резервный канал.

Создадим 2 правила SLA, которые будут пинговать два разных хоста в Интернете.
(Можно конечно пинговать и шлюз своего провайдера, но это не показатель что аплинки провайдера живые)

! здесь мы указываем идентификатор sla
! какой хост пинговать, какой IP ставить в кач-ве исходящего (адрес интерфейса FastEthernet0)
! размер icmp пакета
! threshold в данном случае не важен
! таймаут, по истечению которого считать, что ответ на пинг мы не получили
! как часто пинговать (раз в 10 секунд)

ip sla 121
 icmp-echo 213.180.193.1 source-ip xxx.xxx.xxx.82
 request-data-size 1200
 threshold 1000
 timeout 2000
 frequency 10

ip sla 122
 icmp-echo 216.239.32.10 source-ip xxx.xxx.xxx.82
 request-data-size 1200
 threshold 1000
 timeout 2000
 frequency 10

Запускаем процессы SLA:

ip sla schedule 121 life forever start-time now
ip sla schedule 122 life forever start-time now

track 11 ip sla 121 reachability
track 12 ip sla 122 reachability

Теперь создадим трек, который будет срабатывать, только если оба хоста не пингуются:

track 1 list boolean or
 object 11
 object 12
 delay down 30 up 60

Тут состояние основывается на логическом «И» и «Или».
Если указать «boolean or» — трек 1 будет в UP, если хотя бы один из заданных объектов в UP.
Если указать «boolean and» — трек 1 будет в UP, только если все заданные объекты в UP.

Так же задана задержка срабатываения трека в 30 секунд. Это нужно для того, чтобы при пропадании одного пинга, канал тут же не переключался на запасной. Для переключения, оба хоста должны не ответить на 3 пинга с интервалом в 10 секунд. И когда хосты снова начали пинговаться, переключать канал обратно только если в течении 60 секунд хосты исправно пингуются. Этим самым мы избавимся от частых переключений каналов туда-сюда.

Вместо icmp-echo можно использовать icmp-jitter, он умеет посылать серию пакетов, измерять колебания задержки. Но для этого хост, который будет опрашиваться, должен поддерживать icmp timestamp. Далеко не все хосты в Инете отвечают на этот тип icmp запроса.

Добавляем маршруты по умолчанию:

ip route 0.0.0.0 0.0.0.0 xxx.xxx.xxx.81 10 track 1
ip route 0.0.0.0 0.0.0.0 xxx.xxx.xxx.25 100

Первый маршрут исчезнет, если наш SLA будет в состоянии DOWN.

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

ip route 213.180.193.1 255.255.255.255 xxx.xxx.xxx.81
ip route 216.239.32.10 255.255.255.255 xxx.xxx.xxx.81

Посмотреть статистику работы SLA можно так:

c1812#sh track 
Track 1
  List boolean or
  Boolean OR is Up
    2 changes, last change 19:57:03
    object 11 Up
    object 12 Up
  Delay up 60 secs, down 30 secs
  Tracked by:
    STATIC-IP-ROUTING 0
Track 11
  IP SLA 121 reachability
  Reachability is Up
    7 changes, last change 02:39:03
  Latest operation return code: OK
  Latest RTT (millisecs) 4
  Tracked by:
    Track-list 1
Track 12
  IP SLA 122 reachability
  Reachability is Up
    15 changes, last change 02:58:28
  Latest operation return code: OK
  Latest RTT (millisecs) 56
  Tracked by:
    Track-list 1

05.07.2011

Заметка про hibernate

автор @ 22:20. Tags: , ,
Категории: Заметки

Заметил, что на домашнем ноутбуке не работает спящий режим (hibernation).
Установлен Debian testing. Ноут в спящий режим уходит, но при включении система грузится заново.

Оказалось, в /etc/initramfs-tools/conf.d/resume был указан неверный UUID swap`а.

Исправляем:

echo RESUME=$(/sbin/blkid | grep swap | awk '{print $2}') > /etc/initramfs-tools/conf.d/resume

Пересобираем новый initrd:

update-initramfs -u -k all

Теперь работает.

22.04.2011

Простая генерация паролей в Linux и не только

автор @ 17:12. Tags:
Категории: Заметки

Конечно, есть специализированные утилиты, которые использую различные алгоритмы генерации паролей. Но нам это не нужно, поэтому я делаю проще:

добавляю в .bashrc алиас:

alias pwgen='cat /dev/urandom | tr -dc "a-zA-Z0-9-\!\^_\@\$\?" | fold -w 16 | head -8'

И когда нужно сгенерить пароль, просто пишу в терминале команду pwgen, и получаю 8 вариантов 16-символьных паролей.

Но это будет работать только в линуксе. Если нужен кроссплатформенный вариант, можно воспользоваться утилитой openssl, например команда:

for ((i=0;i<8;i++)); do openssl rand -base64 12; done;

сгенерит 8 16-символьных пароля.

09.04.2011

Site to Site VPN с динамическими крипто картами

автор @ 14:19. Tags: ,
Категории: Статьи

В этой статье мы поговорим о Hub-and-Spoke VPN с одной динамической и двумя статическими крипто-картами между маршрутизаторами cisco. Сценарий следующий: Имеется центральный головной офис, который будет выступать как хаб нашей VPN сети (смотрите схему ниже). Головной офис будет иметь динамическую крипто-карту, в то время как филиалы будут иметь статическую крипто-карту. Конфигурируя в головном офисе динамическую крипто-карту, можно в удаленном филиале иметь динамический внешний IP адрес. Филиал будет иметь статическую крипто-карту, поскольку удаленная сторона (наш головной офис) будет иметь статический внешний IP адрес.

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

~ В случае статических крипто-карт, все пиры на VPN концентраторе (HUB) должны быть сконфигурены вручную со специфичными статическими внешними адресами. В случае динамических крипто-карт, нам не требуется конфигурить пиры один к одному на VPN концентраторе (HUB).

~ В случае динамических крипто-карт, инициатор VPN сессии будет только удаленная сторона (spoke site). Это значит, что если трафик не пришел от удаленной стороны (spoke), то динамический VPN туннель не будет установлен. Однако, когда трафик с удаленной стороны (spoke) инициирует VPN туннель, трафик по нему будет двунаправленным, между филиалом и головным офисом.

~ Простота конфигурации концентратора (HUB). Если мы добавим много удаленных сторон (spoke), конфигурацию потребуется производить только на стороне споков, изменять конфигурацию на хабе не потребуется.

Оборудование, используемое в этом примере:

Головной офис — 3725 IOS c3725-advsecurityk9-mz.124-1c
Филиалы — 2691 IOS c2691-adventerprisek9-mz.123-17a

Сценарий:

Мы имеем головной офис и два филиала, которые подключены к Интернету. Хосты филиала должны иметь безопасный доступ к серверам, расположенным в головном офисе. То есть, сети 192.168.4.0/24 и 192.168.5.0/24 должны иметь безопасный доступ в сеть 192.168.1.0/24. Это обычный сценарий, который многие организации применяют по всему миру. В этом примере используются только внутренние адреса. В настоящей конфигурации IP адрес WAN головного офиса и маршрутизаторов филиалов будут иметь реальные IP адреса.

Конфигурация:

Сначала надо убедиться, что все WAN интерфейсы могут соединяться друг с другом через Интернет.

Конфигурация удаленного филиала:

! Создание isakmp политики. Если имеется несколько политик, рекомендуется наиболее строгую политику ставить первой (то есть присвоить ей наименьший номер)

crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 2

! Настройка crypto isakmp key. Этот ключ между всеми пирами должен быть одинаковым. В нашем случае филиалы должны указать IP адрес головного офиса и иметь одинаковый с ним ключ.

crypto isakmp key somestrongkey address 192.168.2.2

! Настройка алгоритмов шифрования. Это определяет, какой алгоритм шифрование и хеширования будет использоваться для шифрования VPN трафика.

crypto ipsec transform-set ts esp-aes 256 esp-sha-hmac

! Создание акцесс листа, определяющий трафик который должен проходить через VPN. В случае филиала 1 будет следующее: если источник является 192.168.4.0/24 а получатель 192.168.1.0/24, то трафик будет зашифрован. Так же для филиала 2, если источник является 192.168.5.0/24 а получатель 192.168.1.0/24, то этот трафик будет зашифрован.
ACL филиала 1:

ip access-list extended vpn
permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255

ACL филиала 2:

ip access-list extended vpn
permit ip 192.168.5.0 0.0.0.255 192.168.1.0 0.0.0.255

! Создаем крипто-карту и привязываем к уже созданному transform-set и акцесс листу. Так же указываем VPN пир и включаем Reverse-route. reverse-route необходим чтобы при поднятии VPN туннеля, в статическую таблицу маршрутизации добавлялся маршрут к сети получателя, описанного в акцесс листе. В нашем случае это сеть назначения 192.168.1.0/24 и акцесс лист «vpn».

crypto map vpn 10 ipsec-isakmp
set peer 192.168.2.2
set transform-set ts
match address vpn
reverse-route

! Назначаем крипто-карту на внешний интерфейс. В нашем случае Fa0/0. После этого ISAKMP будет включен.

interface FastEthernet0/0
crypto map vpn

Настройки филиалов завершены. Приступим к настройке головного офиса.

Конфигурация головного офиса:
! crypto isakmp политика не изменяется

crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 2

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

crypto isakmp key somestrongkey address 0.0.0.0 0.0.0.0

! IPSec Transform-set не меняется

crypto ipsec transform-set ts esp-aes 256 esp-sha-hmac

! Акцесс лист, описывающий какой трафик будет в него попадать, будет изменен. Отправитель будет 192.168.1.0/24 а получатель 192.168.4.0/24 и 192.168.5.0/24.

ip access-list extended vpn
permit ip 192.168.1.0 0.0.0.255 192.168.5.0 0.0.0.255
permit ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255

! Настройка динамической крипто-карты. Определим теже параметры, за исключением назначения пиров.

crypto dynamic-map vpndynamic 10
set transform-set ts
match address vpn
reverse-route

!Создание крипто-карты и привязка к ней уже созданной динамической крипто-карты.

crypto map dynmap 10 ipsec-isakmp dynamic vpndynamic

!Назначим крипто-карту на внешний интерфейс. В нашем случае Fa0/0. После этого ISAKMP будет включен.

interface FastEthernet0/0
crypto map dynmap

Проверка работоспособности:

Теперь, когда настройка завершена, проверим ее работоспособность. Прежде всего пропингуем SRV с host1. Проверим следующее: устанавливается ли VPN туннель, увеличиваются ли счетчики decaps/encaps, добавляется ли маршрут RRI (reverse-route injection) в таблицу маршрутизации branche1 и hq, изменяются ли счетчики попаданий в акцесс лист или нет.

!Мы видим, что первые несколько ping пакетов теряются, посколько установка VPN туннеля занимает некоторе время.

host1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 40/96/164 ms

host1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/62/124 ms

!Теперь проверим состояние ISAKMP

hq#show crypto isakmp sa
dst             src             state          conn-id slot status
192.168.2.2     192.168.3.2     QM_IDLE              1    0 ACTIVE

branch1#show crypto isakmp sa
dst             src             state          conn-id slot
192.168.2.2     192.168.3.2     QM_IDLE              1    0

!Давайте посмотрим еще раз, увеличиются ли encaps/decaps. Если нет, а хосты пингуют друг друга, значит трафик идет не через VPN туннель.

branch1#show crypto ipsec sa
interface: FastEthernet0/0
crypto map tag: vpn, local addr. 192.168.3.2
protected vrf:
local  ident (addr/mask/prot/port): (192.168.4.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
current_peer: 192.168.2.2:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 13, #pkts encrypto: 13, #pkts digest 13
#pkts decaps: 12, #pkts decrypto: 12, #pkts verify 12
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

!Проверим что RRI в порядке и акцесс листы совпадают.

hq#show ip route static
S    192.168.4.0/24 [1/0] via 192.168.3.2

branch1#show ip route static
S    192.168.1.0/24 [1/0] via 192.168.2.2

hq#show access-lists vpn
Extended IP access list vpn
10 permit ip 192.168.1.0 0.0.0.255 192.168.5.0 0.0.0.255
20 permit ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255 (25 matches)

branch1#show access-lists vpn
Extended IP access list vpn
10 permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255 (26 matches)

Все указывает на то, что все в порядке и VPN работает корректно. Так же помните, что мы не прописываем пиров в конфигурации головного офиса, и это делает конфигурацию простой (когда мы имеем 20 филиалов, то не требуется прописывать статические пиры филиалов в головном офисе).
Еще одно большое преимущество динамических крипто-карт в головном офисе, это когда провайдер выдает филиалам динамические реальные IP адреса.

Этот текст мой вольный перевод статьи Site to Site VPN with Dynamic Crypto Map

02.12.2010

dd на удаленный хост с «прогрессбаром»

автор @ 16:31. Tags:
Категории: Заметки

По умолчанию утилита dd статистику копирования выводит только в конце своей работы.
Требуется, чтобы процесс работы dd был виден в реальном времени.
Заставить dd вывести текущую статистику можно — послав ему сигнал -USR1.
Вот такой командой копирую блочные устройства через утилиту dd по ssh с локальной машины на удаленную, выводя статистику каждые 5 секунд:

while pkill -USR1 ^dd$; do sleep 5; done & dd if=/dev/sda bs=1M | ssh user@hostname.ru dd of=/dev/sdb

08.09.2010

Базовая конфигурация маршрутизатора Cisco 800 для доступа в Интернет

автор @ 13:51. Tags:
Категории: Статьи

Маршрутизаторы серии Cisco 800 используются в основном для SOHO, или для подключения удаленных филиалов к центральной площадке. Это оборудование с встроенной аппаратной конфигурацией, то есть они не имеют аппаратных слотов расширения для установки дополнительных интерфейсов.

Все модели 800 серии имеют 4-х портовый (10/100) управляемый коммутатор, используемый для подключения компьютеров в локальной сети и программное обеспечение IOS с функциями обеспечения безопасности, включая встроенный файрволл.
Главное различие всех этих моделей заключается в типе WAN интерфейса. Все модели, номера которых заканчиваются цифрой «1» в номере модели (например 851, 861, 871, 881, 891) имеют 10/100 Fast Ethernet интерфейс в качестве WAN порта. Другие модели имеют xDSL тип WAN порта (например ADSL, G.SHDL, VDSL2). Так же, имеются модели с WiFi радио интерфейсом, их номера заканчиваются на букву «W» (например 851W, 857W, 861W).

В этой заметке я опишу сценарий базовой конфигурации маршрутизатора Cisco 800 для доступа в Интернет. Я буду использовать модель с Ethernet WAN интерфейсом (типа 851, 861, 871), так как эти модели самые популярные.

У маршрутизаторов 800-й серии 4 LAN интерфейса (с FE0 по FE3) являются интерфейсами L2 коммутатора, которые по умолчанию объединены в Vlan1. Это значит, что вы не можете назначать IP адреса этим интерфейсам напрямую. IP адреса внутреннему (LAN) интерфейсу маршрутизатора назначаются на «interface Vlan1«. WAN интерфейс (FE4) это нормальный L3 интерфейс, которому вы можете напрямую назначать IP адрес на «interface FastEthernet4«.

Я покажу три базовых сценария, наиболее часто встречающиеся в реальных сетях.

Сценарий 1: WAN IP адрес маршрутизатору назначается динамически от Интернет провайдера. В локальной сети IP адреса назначаются компьютерам динамически от маршрутизатора.
Сценарий 2: WAN IP адрес маршрутизатор статический. В локальной сети IP адреса назначаются динамически от маршрутизатора.
Сценарий 3: WAN IP адрес маршрутизатор статический. Внутри локальной сети имеется WEB сервер. Маршрутизатор выполняет статический Port NAT (перенаправление порта) для передачи трафика из Интернета к внутреннему WEB серверу.

Сценарий 1:

Конфигурация:

Следующая базовая конфигурация необходима для вышеприведенного сценария:

configure terminal

enable secret somesecretpassword

! Настройка DHCP пула для назначения адресов внутренним хостам
ip dhcp pool vlan1pool
   network 192.168.1.0 255.255.255.0
   default-router 192.168.1.1
   dns-server 100.100.100.36

! Не назначать адреса с 1 по 30
ip dhcp excluded-address 192.168.1.1 192.168.1.30

! Это интерфейс со стороны LAN 800-го маршрутизатора. Является шлюзом для компьютеров
interface vlan 1
   ip address 192.168.1.1 255.255.255.0
   ip nat inside
   no shut

! Интерфейсы с FE0 по FE3 являются L2 интерфейсами
interface FastEthernet0
   no shut
interface FastEthernet1
   no shut
interface FastEthernet2
   no shut
interface FastEthernet3
   no shut

! Этот WAN интерфейс получает адрес через DHCP от Интернет провайдера
interface FastEthernet 4
   no shut
   ip address dhcp
   ip nat outside

! Настрока NAT. Все внутренние хосты будут NAT-иться в WAN интерфейс
ip nat inside source list 1 interface fastethernet4 overload
access-list 1 permit 192.168.1.0 255.255.255.0

ip route 0.0.0.0 0.0.0.0 fastethernet4

line vty 0 4
password somestrongpassword

Сценарий 2:

Конфигурация:

Это такая же конфигурация как и в сценарии 1 за исключением того, что WAN IP адрес статический, а так же известен адрес шлюза по умолчанию Интернет провайдера.

Отличие от вышеприведенной конфигурации в WAN интерфейсе и шлюзе по умолчанию:

! Этот WAN интерфейс имеет статический IP

interface FastEthernet 4
   no shut
   ip address 100.100.100.1 255.255.255.0
   ip nat outside

ip route 0.0.0.0 0.0.0.0 100.100.100.2

Сценарий 3:

Конфигурация:

Здесь адрес WAN интерфейса статический, и мы так же имеем внутренний WEB сервер, который должен быть доступен по HTTP из Интернета. Для этого мы должны настроить статический NAT с перенаправлением портов. Трафик, который приходит на наш реальный адрес WAN интерфейса 100.100.100.1 на 80 порт, будет перенаправлен маршрутизатором на внутренний WEN сервер по адресу 192.168.1.10 на 80 порт.

configure terminal

enable secret somesecretpassword

! Настройка DHCP пула для назначения адресов внутренним хостам
ip dhcp pool vlan1pool
   network 192.168.1.0 255.255.255.0
   default-router 192.168.1.1
   dns-server 100.100.100.36

! Не назначать адреса с 1 по 30
ip dhcp excluded-address 192.168.1.1 192.168.1.30

! Это интерфейс со стороны LAN 800-го маршрутизатора. Является шлюзом для компьютеров
interface vlan 1
   ip address 192.168.1.1 255.255.255.0
   ip nat inside
   no shut

! Интерфейсы с FE0 по FE3 являются L2 интерфейсами
interface FastEthernet0
   no shut
interface FastEthernet1
   no shut
interface FastEthernet2
   no shut
interface FastEthernet3
   no shut

! Этот WAN интерфейс имеет статический IP
interface FastEthernet 4
   no shut
   ip address 100.100.100.1 255.255.255.0
   ip nat outside

! Настрока NAT. Все внутренние хосты будут NAT-иться в WAN интерфейс
ip nat inside source list 1 interface fastethernet4 overload
access-list 1 permit 192.168.1.0 255.255.255.0

! Настройка статического NAT для перенаправления портов
ip nat inside source static tcp 192.168.1.10 80 100.100.100.1 80 extendable

ip route 0.0.0.0 0.0.0.0 100.100.100.2

line vty 0 4
   password somestrongpassword

Этот текст мой вольный перевод статьи Basic Cisco 800 Router Configuration for Internet Access

18.08.2010

Перенос виртуальной машины из XEN в OpenVZ

автор @ 13:05. Tags: ,
Категории: Заметки

Понадобилось перенести пару виртуальных машин (с установленными в них CentOS 5.x) с XEN DomU в контейнеры OpenVZ.
Пришлось совершать различные манипуляции, и я решил задокументировать их на память.

Итак, на XEN хосте (Dom0, имя mars.hq.domain.ru) исходная виртуалка смонтирована в /mnt/temp/. На OpenVZ хосте (имя mercury.hq.domain.ru) создан контейнер, и его корень находится в /var/lib/vz/private/105/.

Скопируем содержимое виртуалки в новое место:

mercury:~# rsync -arvpz --numeric-ids --exclude dev --exclude proc -e ssh root@mars.hq.domain.ru:/mnt/temp/ /var/lib/vz/private/105/

После того, как все скопируется, вносим нужные измения и настройки:

mercury:~# sed -i -e '/getty/d' /var/lib/vz/private/105/etc/inittab
mercury:~# rm -f /var/lib/vz/private/105/etc/mtab
mercury:~# ln -s /proc/mounts /var/lib/vz/private/105/etc/mtab
mercury:~# cp /var/lib/vz/private/105/etc/fstab /var/lib/vz/private/105/etc/fstab.old

mercury:~# cat >/var/lib/vz/private/105/etc/fstab<<EOF
proc  /proc       proc    defaults    0    0
none  /dev/pts    devpts  rw          0    0
EOF

mercury:~# mkdir /var/lib/vz/private/105/dev
mercury:~# mknod --mode 666 /var/lib/vz/private/105/dev/ptmx c 5 2
mercury:~# mkdir /var/lib/vz/private/105/dev/pts
mercury:~# cp -a /dev/ttyp* /dev/ptyp* /var/lib/vz/private/105/dev/
mercury:~# mknod --mode 666 /var/lib/vz/private/105/dev/null c 1 3
mercury:~# mknod --mode 444 /var/lib/vz/private/105/dev/urandom c 1 9
mercury:~# mkdir /var/lib/vz/private/105/proc

Стартуем наш OpenVZ контейнер.

Теперь пробуем войти в него:

mercury:~# vzctl enter 105

Если получили ошибку: «Unable to open pty: No such file or directory», выполняем:

mercury:~# vzctl exec 105 /sbin/MAKEDEV tty
mercury:~# vzctl exec 105 /sbin/MAKEDEV pty

Заходим в виртуалку:

mercury:~# vzctl enter 105

Сносим udev:

v105# rpm -qf /etc/udev/makedev.d/50-udev.nodes
v105# rpm -e udev-095-14.20.el5_3 --nodeps

Перезапускаем контейнер.

Если по прежнему возникают какие-то проблемы — можно в виртуалке, в файле /etc/rc.sysinit закомментировать строку:

/sbin/start_udev

После того как OpenVZ контейнер запущен и все заработало, скорее всего будет наблюдаться проблема с отображением свободного места в виртуалке командой df.
Дело в том, что операции записи файлов в виртуалку мы производили напрямую в ее каталог на хост сервере. Поэтому механизм квотирования изменения не учитывал.
Необхрдимо сбросить квоты, чтобы все пересчиталось заново.
Останавливаем виртуалку, и выполняем:

mercury:~# vzquota drop 105

После запуска виртуалки, размер свободного дискового пространства должен отображаться правильно.