пятница, 11 декабря 2015 г.

Mikrotik, PPTP

Как-то на хабре прочитал, что важные моменты по работе лучше всего записывать. Вот и я так решил сделать. Ладно, все это лирика.

На работе есть главный офис, и есть куча маленьких офисов. В виду того, что главный офис иногда остается без основного канала Интернета и света, Интернет соответственно не работает. Со светом проблема решаема через UPS, да и с Интернетом тоже. Есть резервный канал с другим ip, а другие офисы не могут переподключаться самостоятельно на другой ip. Благо везде православный Mikrotik, в котором функционал просто огромен. Так вот, все работает через PPTP. Все мы знаем, что соединение идет с определенным ip, и в смене подключаемого ip нам помогает netwatch+scripts.

Заходим через winbox или web-тырфейс (кому как лучше)

System - Scripts, создаем новый с именем change-to-main
с содержимым:

/interface pptp-client set  pptp-office connect-to=8.8.8.8

и еще один change-to-reserv
с примерно таким же содержимым, только с ip резервного канала

/interface pptp-client set  pptp-office connect-to=9.9.9.9

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

Теперь идем Tools - Netwatch

Создаем новый, и вписываем ip основного офисного канала, т.е. 8.8.8.8

в поле On Up вписываем change-to-main
в поле On Down вписываем change-to-reserv

Вот собственно и все. После потери связи с основным каналом, идет переподключение на резервный. Если восстанавливается связь, идет переключение на основной канал.



среда, 25 ноября 2015 г.

OpenvSwitch, ubuntu 14.04 qemu-kvm

... Велосипед на костыльной тяге (c) admin Linux

Сия статья написана в виде заметки по созданию виртуальных локальных сетей. Суть её в том, чтобы создать изолированные локальные сети второго уровня без необходимости подключения физического интерфейса. Т.е. все виртуально, и выход в Интернет осуществляется посредством маршрутизации. Операции проводятся на хосте с предустановленной Ubuntu Server  14.04.03 и с предустановленной системой виртуализации qemu-kvm с библиотекой управления Libvirt

 Первым делом надо поставить пакет для работы с openvswitch
# apt-get install openvswitch-switch
После установки, нам доступны различные команды для создания и конфигурирования виртуальных коммутаторов


# ovs-vsctl add-br ovs-br0
Это команда создает виртуальный коммутатор с названием ovs-br0, но он пока никакой смысловой нагрузки не несет.

Теперь нам надо добавить порт в наш новый коммутатор


# ovs-vsctl add-port ovs-br0 bond0

Этот порт у нас будет транковым. В целом он никакой особенной нагрузки не несет. Да и вообще он предназначен для соединения двух или более коммутаторов. Зачем он, будет объяснение чуть ниже.

После добавление порта bond0 в коммутатор, необходимо его сделать транковым.


# ovs-vsctl set port bond0 trunks=7,10,20,1010,1020,30,1030

В каких vlan'ах этот порт будет, решать каждому. Т.е. можно заменить 7,10,20... на другие значения. Теперь можно задать адрес коммутатору

# ifconfig ovs-br0 10.6.6.6/24 up

Приятной особенностью OpenVswitch является сохранением настроек внутри себя. Т.е. чтобы наш коммутатор после перезапуска был готов к работе с нужными конфигурациями, достаточно в /etc/network/interfaces добавить строчки

auto ovs-br0
iface ovs-br0 inet static
 address 10.6.6.6
 netmask 255.255.255.0
 network 10.6.6.0
 broadcast 10.6.6.255
 #gateway 10.6.6.254
 # dns-* options are implemented by the resolvconf package, if installed
 dns-nameservers 10.6.6.254
Коммутатор в принципе готов к работе, но можно воспользоваться еще одной интересной возможностью для масштабирования фермы виртуальных машин. Т.е. создадим порт-группы, которые позволят прямо из GUI virt-manager'a добавлять виртуальные машины прямо в группы. Довольно-таки удобно.

Для начала создадим файлик /tmp/ovs-network.xml

И вставим в него следующий текст:

<network>
  <name>ovs-network</name>
  <forward mode='bridge'/>
  <bridge name='ovs-br0'/>
  <virtualport type='openvswitch'/>
  <portgroup name='vlan-10'>
    <vlan>
      <tag id='10'/>
    </vlan>
  </portgroup>
  <portgroup name='vlan-20'>
    <vlan>
      <tag id='20'/>
    </vlan>
  </portgroup>
  <portgroup name='vlan-1010'>
    <vlan>
      <tag id='1010'/>
    </vlan>
  </portgroup>
  <portgroup name='vlan-1020'>
    <vlan>
      <tag id='1020'/>
    </vlan>
  </portgroup>
  <portgroup name='trunkPortGroup'>
    <vlan trunk='yes'>
      <tag id='30'/>
      <tag id='1030'/>
    </vlan>
  </portgroup>
</network>

Далее выполняем команды:


virsh net-define /tmp/ovs-network.xml
virsh net-start ovs-network
virsh net-autostart ovs-network

фы Теперь вернемся к интерфейсу bond0. Если его не создавать, то все виртуальные машины в этом коммутаторе будут в одном vlan'е. Но при наличии транкового порта, группы vlan'ов начинают работать.

суббота, 29 августа 2015 г.

KVM + Ubuntu = love

Вообще виртуализация - это затертая до дыр тема, но кое-что я для себя помечу.

Допустим, у нас имеется компьютер/сервер с предустановленной Бубунтой. И мы хотим его использовать в качестве гипервизора. Есстно ОС гипервизора должна работать только с виртуальными машинами, т.е. своего рода ферма. ОС гипервизора у нас будет Ubuntu 14.04.3
Задача такая. На гипервизоре есть виртуальная машины, и мы хотим через виртуалку гонять трафик в Сеть. Т.е. проще говоря, шлюз. Так же на гипервизоре даны два сетевых интерфейса, один смотрит в Интернет, другой в нашу локалку. Нужно прокинуть оба интерфейса в вирутальную машину. Как лучше это сделать? Вариантом много, но я поступил следующим образом.

на гипервизоре в настройке /etc/network/interfaces вот такое вот

auto lo
iface lo inet loopback

auto p2p1
iface p2p1 inet manual

auto br0
iface br0 inet static
        address 192.168.13.20
        network 192.168.13.0
        netmask 255.255.255.0
        dns-nameservers 192.168.13.1
        gateway 192.168.13.1
        broadcast 192.168.13.255
        bridge_ports p3p1
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_sftp off


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

Следующий интерфейс, который смотрит локальную сеть, я перевел в режим моста. Для чего это нужно? Это очень удобно, так как в режиме моста, данный интерфейс работает как обычный switch. Т.е. последующие создаваемые виртуальные машины, также можно направлять в нашу локальную машину. Стоит также отметить, что гипервизор - обычный клиент сети с ip-адресом 192.168.13.20, а у шлюза 192.168.13.1
Теперь через virt-manager (ubuntu), нужно создать два сетевых интерфейса в виртуальной машине шлюза.
Один завести подключить через созданный мост (br0), а второй Hostdivace p2p1 macvtap, device model: virtio, source mode: Privat

Вот так прокинуты интерфейсы в виртуалку. Ну и в виртуалке эти интерфейсы будут как eth0 и eth1 

пятница, 24 апреля 2015 г.

Настройка контроллера домена Active Directory с помощью Samba 4 на Ubuntu 14.04

Идея создания контроллера домена на базе Samba, не нова. Но опять же, в предыдущих версиях Samba контроллер был неполноценный. На вендовых машинах надо было добавлять файлы в реестрах, настраивать локальные политики, и менять тип шифрования. Что же изменилось в контроллере домена на Samba 4? Все лишние телодвижения отпали сами по себе.
Для начала предположим, что у нас уже предустановлена ubuntu 14.04, и с голой сосолькой ждет, пока её потеребят. Еще надо взять на заметку, что шлюз у нас отдельно (но это несущественно). Вообще, что из себя представляет контроллер домена? Это по сути связки мощных тлуз: Kerberos+LDAP+Samba. Более детально читайте в Интернетах.
Теперь к делу.


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





Имя хоста: DC1


AD DNS Domain Name: torg.com


Kerberos Realm: torg.com


NT4 Domain Name/NetBIOS Name: torg


IP адрес: 192.168.0.20


Server Role: Domain Controller (DC)


Forwarder DNS Server: 192.168.0.1




Всегда всё лучше начинать с обновления системы


Обновляем базу данных со сведениями из репозиториев:


$ sudo apt-get update


Обновляем пакетики


$ sudo apt-get upgrade


Накатываем Kerberos


$ sudo apt-get install attr build-essential libacl1-dev libattr1-dev \


libblkid-dev libgnutls-dev libreadline-dev python-dev libpam0g-dev \


python-dnspython gdb pkg-config libpopt-dev libldap2-dev \


dnsutils libbsd-dev attr krb5-user docbook-xsl libcups2-dev acl ntp


Во время установки Kerberos, запустится скрипт с просьбой ввести данные

в первом окошке вводим


TORG.COM


DC1.TORG.COM


DC1.TORG.COM


Если во время обновлении системы было обновлено ядро, то лучше ребутнуться.

После загрузки с новым ядром, необходимо откорректировать следующие параметры в /etc/network/interfaces


#


iface eth0 inet static


address 192.168.0.20


netmask 255.255.255.0


gateway 192.168.0.1


dns-nameservers 192.168.0.20 192.168.0.1


dns-search torg.com


По сути нужно установить статику. Можно и не устанавливать, но для надежности надо.

Надо проверить hostname в файле /etc/hostname

Там должна быть единственная строчка такого содержания


dc1


Далее самое интересное, нужно монтировать файловую систему так, чтобы


## /etc/fstab






UUID=xyzxyzxy-xyzx-xyzx-xyzx-xyzxyzxyzxyzxy / ext4 user_xattr,acl,barrier=1,errors=remount-ro 0 1

В общем, надо чтобы корень монтировался с параметрами

user_xattr,acl,barrier=1,errors=remount-ro эта очень важный момент.

Теперь нужно отредактировать файл /etc/hosts



127.0.1.1 dc1.torg.com dc1




В общем, там вот такая строчка должна быть. Это необходимо, чтобы по адресу 127.0.1.1 мы сразу могли без DNS обратиться по имени к dc1.torg.com

Одним из самых важных моментов в работе подобных сетевых ресурсов - это точная временная синхронизация.






#


#stop the ntp service


$ sudo service ntp stop


#sync ntp


$ sudo ntpdate -B 0.ubuntu.pool.ntp.org



#start the ntp service


$ sudo service ntp start




Теперь надо еще раз перезагрузиться, чтобы применить изменения, и все работало как надо.

$sudo shutdown




После перезагрузки можно сразу устанавливать Samba

$ sudo apt-get install samba smbclient





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






$ sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.orig


#Собственно создание контроллера домена


$ sudo samba-tool domain provision --use-rfc2307 --interactive


#Появятся строчки, и в квадратных скобках предлагается вариант по умолчанию. В общем, можно нажимать Enter до самого ввода пароля


Realm [TORG.COM]:
Domain [TORG]:
Server Role (dc, member, standalone) [dc]:
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]:
DNS forwarder IP address (write 'none' to disable forwarding) [192.168.0.1]:
Administrator password:
Retype password:


После ввода скрипт начнет создание контроллера домена.



Самое интересное то, что в Samba 4 теперь свой DNS, который довольно-таки неплохо работает. Можно сделать форвардинг на DNS который имеется в системе, а можно указать DNS-сервер провайдера.

Ранее было указано два DNS в файле /etc/network/interfaces, а теперь можно использовать локальные. В общем, надо удалить строчку 192.168.0.1 и привести к такому виду


dns-nameservers 192.168.0.20 192.168.0.
1


Опять священный ребут

$ sudo shutdown -r 0



Теперь можно протестировать работу DNS


#Тест DNS записи для ldap по протоколу TCP


$ host -t SRV _ldap._tcp.torg.com


_ldap._tcp.torg.com has SRV record 0 100 389 dc1.torg.com.


#Тест DNS-записи для kerberos по протоколу UDP


$ host -t SRV _kerberos._udp.torg.com


_kerberos._udp.torg.com has SRV record 0 100 88 dc1.torg.com


#test name resolution of our host


$ host -t A dc1.torg.com


dc1.torg.com has address 192.168.0.20




Собственно вот если все проходит в таком порядке, то DNS от Samba работает как надо. Теперь можно попробовать залогиниться.

$ kinit administrator@TORG.COM

если все ок, покажет, что пассворд действителен месяц.

понедельник, 9 февраля 2015 г.

Самопальный файрвол на базе Ubuntu

Допустим, имеется ПК с предустановленной ubuntu server 14.04 и надо настроить связку dns+dhcp.
Дано:
Имя хоста: dc1
Домен: dc1.torg.com
Сеть: 192.167.13.0/24
Сетевки: eth0 - подключен тырнет, eth1 - смотрит в локалку

Первым делом надо привести к такому виду /etc/hosts
127.0.0.1   localhost
127.0.0.1   dc1.torg.com   dc1

В /etc/hostname должно быть:
dc1
Сколько не лазил в тырнетах, раз 20 находил команду SUDO SU
Сказать, что у меня пошла кровь из глаз, наверное ничего не сказать. ПАЦАНЫ, ИСПОЛЬЗУЙТЕ SUDO -S И НЕ БУДЬТЕ МУДАКАМИ
Есстно команду маленькими буквами, один хрен все операции от рута делать.

Можно не заморачиваться сильно по поводу iptables, и использовать надстройку типа ufw (тот же iptables, только для самых маленьких)

Для начала надо его включить:
ufw enable 
Если нужен ssh на нестандартном порту, например 1200, достаточно его разрешить:
ufw allow 1200
Ну и соответственно указать нужный порт в /etc/ssh/sshd.conf
Теперь надо разрешить хождения трафика по локалке через шлюз:
ufw allow from 192.168.13.0/24
А еще надо разрешить форфардинг пакетов в Интернеты. Все просто, нужно добавить следующее в /etc/ufw/before.rules
# NAT table rules
*nat :POSTROUTING ACCEPT [0:0] 
# Forward traffic through eth0 - Change to match you out-interface 
-A POSTROUTING -s 192.168.13.0/24 -o eth0 -j MASQUERADE 
# don't delete the 'COMMIT' line or these nat table rules won't
# be processed 
COMMIT
Вот именно от закоменченой строчки, до самого Коммита. Скопировать и вставить.

И на десерт надо разрешить в ядре форфардинг. Да, это очень удобно, когда интернеты выключаются в трех местах, а включить нужно в 4-х. Так вот, надо добавить или раскоментировать строчку в /etc/sysctl.conf
net.ipv4.ip_forward=1
И желательно ребутнутся. Или же выполнить:
sysctl -p
В выхлопе должно отобразиться добавленное правило.
А еще надо разрешить форвардинг на уровне самого ufw. Для этого необходимо изменить строчку в /etc/default/ufw
Там одна одна. Изменить с DROP на ACCEPT. Короч вот как надо
DEFAULT_FORWARD_POLICY="ACCEPT
Если выдача ip адреса у провайдера автоматическая, то надо отредактировать /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet static
address 192.168.13.1
netmask 255.255.255.0
network 192.168.13.0
broadcast 192.168.13.255
Еще надо временно отредактировать /etc/resolv.conf в такой вид
domain torg.com
search torg.com
nameserver 192.168.13.1

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

Теперь самое важное. DHPC и DNS-сервера. В качестве DHCP-сервера я выбрал isc-dhcp-server, а в качестве DNS - bind9
Сервера легковесны и доступны из официальных репозиториев.
Короч, ставим их.
apt-get install isc-dhcp-server bind9
После установки, надо добавить isc-dhcp-server в автозагрузку
update-rc.d isc-dhcp-server defaults
Иначе после каждой перезагрузки надо его запускать вручную. Что можно сказать поэтому поводу? УДОБНО! Благо bind9 после установки сам в автозапуск прописывается.

Начнем со сложного, а именно с DNS-сервера. Вообще эта замудреная штука не такая и сложная, особенно если перерыл первые 5 страниц гугла вдоль и поперек.  Суть в чем, надо сделать форвардинг на dns гугла или провайдера, и создать кэширующую локальную зону. Ну, чтобы имена компьютеров преобразовывались в ip и наоборот. И тут у нас DNS становится DDNS-мать его сервер! 

Конфигурирование DNS-сервера начинается с файла 
/etc/bind/named.conf.options  и туда надо запихнуть эти строки:

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        listen-on {
                127.0.0.1;
                192.168.13.1;
        };

Вообще, я читал ман по настройке на help.бубунту.лажа и есстно dns не взлетел. Максимум что он смог, так это перенаправлять трафик на DNS-гугла, но локальная зона не взлетела. Ладно, теперь о ней более детально. Рекомендуется файлы настроек локальной зоны хранить в /var/lib/bind и лучше не пренебрегать рекомендацией. Поэтому создаем файл /var/lib/bind/forward.bind
и запихиваем в него следующее
;
; BIND data file for torg.com
;
$TTL    604800
@       IN      SOA     torg.com. root.torg.com. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
        IN      A       192.168.13.1
;
@       IN      NS      dc1.torg.com.
@       IN      A       192.168.13.1
@       IN      AAAA    ::1
dc1      IN      A       192.168.13.1

Теперь надо создать файл обратной зоны, из ip в имена преобразует /var/lib/bind/reverse.bind 
;
; BIND reverse data file for local 192.168.13.XXX net
;
$TTL    604800
@       IN      SOA     dc1.torg.com. root.torg.com. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      dc1.
1      IN      PTR     dc1.torg.com.
Финальная стадия настройки вот-вот начнется. Но нам нужен секретный ключ, который будет делать перезапись супер-секретных имен компьютеров в сети и ip.
И где его взять? А негде, в Linux все как в совке, открываешь книгу "Сделай сам", и делаешь. В совке было сурово, но нам проще, и делается это одной командой:
dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DHCP_UPDATER
Генерируется он в текущий каталог, там где ты был. Обычно в  ~/
Так вот, теперь надо забрать его из полученного файла
cat Kdhcp_updater.*.private|grep Key
И он должен быть в выхлопе в виде что-то такого 
YboDJAiXA8lhFMOaxG49rw==
Вот теперь все готово для создания локальной зоны. Настройки хранятся в файле /etc/bind/name.conf.local и обычно там почти ничего нет, поэтому надо внести следующее:


key DHCP_UPDATER {
        algorithm HMAC-MD5.SIG-ALG.REG.INT;
        secret "YboDJAiXA8lhFM0axG49rw==" ;
};

zone "torg.com" IN {
        type master;
        file "/var/lib/bind/forward.bind";
        allow-update { key DHCP_UPDATER; };
};

zone "13.168.192.in-addr.arpa" IN {
        type master;
        file "/var/lib/bind/reverse.bind";
        allow-update { key DHCP_UPDATER; };
};

И теперь пришло время перезапустиь bind9
sudo service bind9 restart
Если удачно перезапустился, это не факт, что все нормально. Пришло время тестировать локальную зону!! Она себя не затестирует. Так вот, чтобы ее тестировать, надо просто проверить три команды. 
dig dc1
В выхлопе должно быть что-то вроде 
; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> dc1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52459
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dc1.    IN A

;; AUTHORITY SECTION:
.   1598 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2015020901 1800 900 604800 86400

;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 10 17:58:58 SAKT 2015
;; MSG SIZE  rcvd: 107
Но это мелочь, по-моему просто проверка тырнета, не вникал. Теперь же делаем преобразование имени в ip-адресс
host dc1
Выхлоп должен содержать что-то вроде: 
dc1.torg.com has address 192.168.13.1
Если ошибка, то надо смотреть /var/lib/bind/forward.bind
Если все ок, идем дальше:
host 192.168.13.1
И опять-таки, если все нормально (а по-идее нормально), то выхлоп должен быть таким
1.13.168.192.in-addr.arpa domain name pointer dc1.torg.com.
Самое страшное позади. Настроить dhcp - как два перста оросить. 
Просто сохраняем на всякий случай старый конфиг
mv /etc/dhcp/dhcp.con /etc/dhcp/dhcp.conf.orig
И создаем новый с таким содержанием


ddns-update-style interim;
authoritative;
log-facility local7;

key DHCP_UPDATER {
algorithm hmac-md5;
secret "YboDJAiXA8lhFMOaxG49rw==";
}

zone torg.com. {
primary 127.0.0.1;
key DHCP_UPDATER;
}

zone 13.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}

subnet 192.168.13.0 netmask 255.255.255.0 {
range 192.168.13.2 192.168.13.254;
option domain-name "torg.com";
option domain-name-servers 192.168.13.1;
option routers 192.168.13.1;
option broadcast-address 192.168.13.255;
default-lease-time 43200;
max-lease-time 86400;
}

Можно еще запихнуть в dhcp.conf такие строки, чтобы резервировать ip-адреса машин в сети, и вести ip-лист
 host buhgaltery {
                hardware ethernet 08:00:27:e9:fd:82;
                fixed-address 192.162.13.10;
        }
Вроде все. Но не все! Логи же надо смотреть кто-чего просит, да и вообще это полезно. Так вот, в /etc/rsyslog.d/50-default.conf
Надо добавить в самый конец строчку
local7.* /var/log/dhcpd.log
И перезапускаем службы по порядку
service rsyslog restart
service isc-dhcp-server restart
И теперь логи видны при помощи команды
tail -f /var/log/dhcpd.log
Теперь можно отслеживать, кто когда запрашивает адреса. Вообще у dhcp-server куча много настроек, но это необходимый минимум для работы.