Active Dirictory несколько контроллеров домена

Иногда бывает так, что два или более офисов связаны между собой VPN, и связь имеет свойство обрываться. Не будем о том, что можно настраивать резервные каналы, подключать ИБП. Так вот, в первом офисе сеть 10.10.10.0/24 а во втором 10.10.20.0/24

В первом офисе установлен на сервер свеженький Windows Server 2012R2 с ролью Active Dirictory и DNS-server (одно без другого никак не может полноценно функционировать)

Все системные администраторы рано или поздно начинают понимать, что один контроллер домена хорошо, а два еще лучше. Так вот, во второй офис закупили сервер, и надо настроить там контроллер домена с репликацией.

Для начала нужно на настроенном контроллее домена открыть "Сайты и службы", создать подсети 10.10.10.0/24  и 10.10.20.0/24 а также создать два сайта. Например, office1 и office2, после чего привязать подсети к сайтам. После привязки, нужно перетащить текущий контроллер из сайта Default-First-Site-Name в office1.

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

После сайтов переходим на наш второй сервер, который должен стать еще одним контроллером домена.

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

После перезагрузки будет синхронизация контроллера домена

Инфа взята с http://serveradmin.ru/nastroyka-kontrollerov-domena-v-raznyih-podsetyah/

MikroTik Guest WiFi

В этой чудной статейке я хочу описать как же настраивать на Микротиках гостевую точку доступа WiFi.

Что мы имеем? В наличии маршрутизатор MikroTik RoutBoard RB951Ui, и надо сделать гостевую точку, в которой будет только доступ в Интернет, и никуда более.

Казалось бы, достаточно создать еще один виртуальный тырфейс wifi, на нем поднять dhcp-сервак, добавить запрещающие правила, и все. Но тут затаилось одно большое волосатое НО! Но не работает dhcp-server на тырфейсах, которые в slave-режиме, а свежеиспеченный виртуальный тырфейс гостевого wifi как раз именно такой.

А чтобы решить эту проблему, нужно создать еще один мост, и добавить в него вирутальный тырфейс гостевой точки доступа.

в консоле создаем новый мост

/interface bridge
add name=bridge-guest

Новенький мост создан, теперь переходим к созданию виртуального интерфейса для гостевой точки

/interface wireless security-profiles
add authentication-types=wpa2-psk mode=dynamic-keys name=guest wpa2-pre-shared-key=somepassphrase

/interface wireless
add disabled=no mac-address=D6:CA:6D:8E:43:18 master-interface=wlan1 name=wlan2 security-profile=guest ssid="My Guest SSID" wds-default-bridge=bridge-guest

/interface bridge port
add bridge=bridge-guest interface=wlan2

Стоит для справочки отметить, что у гостевой точки будут такие параметры:
Имя сети: My Guest SSID
Пароль: somepasshrase
Виртуальная точка находится в мосте bridge-guest
Интерфейс виртуальной точки называется wlan2, и он в slave с интерфейсом wlan1, за счет добавления в мост wlan2, мы можем поднимать dhcp-сервер, и раздавать отдельные адреса

Для начала зададим адрес для bridge-guest, и обозначим к какой сети он принадлежит

/ip address
add address=172.16.0.1/24 interface=bridge-guest network=172.16.0.0
/ip pool
add name=guest ranges=172.16.0.100-172.16.0.254
/ip dhcp-server
add address-pool=guest disabled=no interface=bridge-guest name=guest
/ip dhcp-server network
add address=172.16.0.0/24 dns-server=172.16.0.1 gateway=172.16.0.1

Данные команды также создают еще один dhcp на роутере, который выдает адреса в диапазоне от 172.16.0.100 до 172.16.0.254

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

/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1-gateway src-address=172.16.0.0/24

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

/ip firewall filter
add action=drop chain=forward in-interface=bridge-guest out-interface=!ether1

А еще можно запретить хождения в другие подсети, если к ним есть доступ (на всякий случай)



/ip firewall filter add action=drop chain=forward comment="Guest AP" dst-address=192.168.1.0/24 src-address=172.16.0.0/24

и еще разок efault/hotspot-default target=Guest-bridge \

    total-limit-at=1M total-max-limit=1M

/ip firewall filter add action=drop chain=forward comment="Guest AP" dst-address=172.16.0.0/24 src-address=192.168.1.0/24

Ограничиваем скорость для Guest_WiFi

/queue simple

add name=HotSpot queue=hotspot-default/hotspot-default target=bridge-guest \

    total-limit-at=1M total-max-limit=1M

Инфу брал тут и там 

http://zaraev.blogspot.ru/2015/08/mikrotik-auto-12-wifi-work-wifi-free.html
https://www.geleijn.nl/2014/guest-network-mikrotik-router/
http://serverfault.com/questions/738402/mikrotik-configuration-add-a-public-wireless-router-internet-only-to-office

1С PostgreSQL Ubunntu

Когда речь идет про 1С, то лучше опустить многие моменты, о ней можно бесконечно долго спорить. Ладно, не будем и холивать на темы негрософта. В общем, фанатам Linux в частности Ubuntu данная статья может быть когда-то поможет.

Допустим, надо поднять сервер базы данных для нашей 1С. К сожалению или к счастью 1С работает только с MS SQL и PostgreSQL.  Нам нужен второй вариант, и не просто второй а с патчами для работы с библиотекой mvarchar которая нужна для работы с кодировками.  Если все нормально пропатчено, в кластере серверов 1С можно указать сервер с БД, лог/пас, и коннектится. При успешном коннекте можно пытаться создавать базу непосредственно с самой 1С, проще говоря, база почти сама создается. Так вот, если все проходит гладко, не надо переживать, и успешно работать. Если же патченный PostgreSQL выдает ошибку при создании БД

ERROR: type "mvarchar" does not exist at character 3

Тогда нужно проверить наличие библотек

ls /usr/lib/postgresql/9.4/lib/*libicu*

У меня же было целое ничего, когда я впервые пытался создать базу данных.
Но я же качал патченную прямо с сайта 1С! Как же так? И тут я решил посмотреть, есть ли вообще в системе такие либы

$ find / -name "libicudata*"

И о чудо, они лежат в /usr/lib/x86_64-linux-gnu/

Что можно сделать? Скопировать? не, можно симлинк, и все будет хорошо

 $    ln -s /usr/lib/x86_64-linux-gnu/libicudata.so.52.1 /usr/lib/postgresql/9.4/lib/libicudata.so.52
 $    ln -s /usr/lib/x86_64-linux-gnu/libicui18n.so.52.1 /usr/lib/postgresql/9.4/lib/libicui18n.so.52
 $    ln -s /usr/lib/x86_64-linux-gnu/libicuuc.so.52.1 /usr/lib/postgresql/9.4/lib/libicuuc.so.52


Перезагружаем наши сервисы с бд, и можем снова пробовать подключиться к БД через кластер серверов 1С. И теперь должна база создаться. Можно еще накатить phppgadmin, чтобы смотреть через web-тырфейс за postgresql. Но это уже дело вкусов.

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

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

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'ов начинают работать.

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 

Настройка контроллера домена 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

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