Vadim K

www.codecademy.com/en/tracks/python

Реальный DNS домен: company.ru/company.com
Домен AD: ad.company.ru/ad.company.com

"Бытующее мнение" связано с тем, что ранее, когда интернет был не столь распространён в компаниях (в начале 2000х), у компаний не было своих сайтов еще со своим корп. именем (а обычно были странички вроде isp-server.ru/~mycompany ), а выход в интернет был через прокси сервер по диалапу, админы не парились и называли свои домены company.ru. Когда же появлялся сайт company.ru, то появлялась проблема с внешним и внутренним DNS, т.к. совершенно два разных DNS сервера отвечали за эту зону, для внешних это один DNS, для внутренних другой. Получается такой Split-DNS, и всё бы ничего, но за зону внутри компании company.ru отвечает ваш контроллер домена, он и откликается на это имя, вроде бы сайт можно прописать алиасом на www.company.ru (и сказать всем в компании, что б открывали только так), но вдруг кто-то до вас завел в домен компьютер www, т.е. тут уже геморрой www.company.ru - занят.
Вот по этому добавьте перед корп. именем понятный вам префикс, и не парьтесь, примеры:
ad.company.ru, inside.company.ru, local.company.ru etc...

В отображении добавить | safe и все будет ок . Всем спасибо разходимся.

Загальна будова
{{ details.zag_bund | safe }}

Давай по-порядку. Зачем вообще юзать IPSec - для того, чтобы защитить трафик идущий по публичным (или не очень) сетям. Сделать возможность перехвата, расшифровки или компрометации трафика минимальной. Для этих целей подходят туннели типа OpenVPN и IPSec (всё остальное либо проприетарное, либо ломается на ура).
Имхо, oVPN больше подходит для приземления клиентов, а IPSec для связи сетей.

Дальше. IPSec способен работать в двух режимах, туннельном и транспортном.

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

Транспортный режим - соединяет трафик идущий между двумя точками - между двумя устройствами - без построения туннеля. Т.е. просто (де)шифрование пакетов. И для построения туннель нужно будет использовать отдельно IPIP, или L2TP или любой другой протокол Point to Point.

Нафига же нам может такой понадобиться? Например если у тебя соединяются не две отдельные сети, а несколько с каждой стороны (политик в этом случае нужно в X*Y). А может ты строишь множественную связность, когда нельзя однозначно сказать через какой Peer доступна та или иная сеть (например с ospf внутри). А может быть у тебя по туннелю гоняется не IP трафф (а телефония или мультикаст или FoIP или ATAIP). А может так же ты гоняешь l2 пакеты (например, сбриджевал два офиса и у них общая адресация - при небольшом расстоянии вполне себе решение). А ещё иногда нужно перестроить сеть без сброса всех активных туннелей (что в предыдущем случае невозможно). В целом использование транспорта IPSec - гораздо более удобнее.

Устанавливаете сервер 8.3.
В мастере установки указать "Установить сервер 1С:Предприятия как сервис Windows (рекомендуется)".

Сервер установится, но из-за конфликта портов с сервером 8.2 не запустится.

Далее в идем в реестр
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\

Ищем ветку
1C:Enterprise 8.3 Server Agent
или
1C:Enterprise 8.3 Server Agent (x86-64)

В этой ветке правим ImagePath - меняем порты
Например, было
"C:\Program Files (x86)\1cv8\8.3.4.389\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files (x86)\1cv8\srvinfo"

стало
"C:\Program Files (x86)\1cv8\8.3.4.389\bin\ragent.exe" -srvc -agent -regport 2541 -port 2540 -range 2560:2591 -d "C:\Program Files (x86)\1cv8\srvinfo"

После этого сервер можно запустить из консоли "Службы".

При добавлении новых баз 1С в качестве кластера указывать ServerName:2541

Маскардинг не работает в вашем случае. Добавляйте явное правило SNAT для таких пакетов.
В общем, всё выглядит примерно так.
1. LAN client -> Mikrotik, 192.168.0.100:4555 -> 1.2.3.4:87 (на роутере у этого пакета будет in-interface ether2, так как пакет действительно прилетел из локальной сети) - если в правиле указано сопоставление пакета по входящему интерфейсу для dst-nat (логичнее предположить, что он у вас указан как ether1), то никакого перенаправления не будет. Либо заводите два правила, либо не проверяете для перенаправляемых пакетов входящий интерфейс, а только адрес назначения, протокол и порт. Двигаемся дальше.

2. Mikrotik -> LAN server, 192.168.0.100:4555 -> 192.168.0.2:87 (output-interface ether2) - Победили перенаправление и пакеты теперь успешно улетают в локалку после замены адреса назначения (в том-то и суть dst-nat). Но что будет дальше? Локальный сервак получает перенаправленный через роутер пакет и отвечает на него напрямую в обход роутера.

3. LAN server -> LAN client, 192.168.0.2:87 -> 192.168.0.100:4555 - Это ответный пакет от сервера. Но клиент ожидает пакеты с адресом источника 1.2.3.4, а не эти, и отбрасывает их. Либо молча, либо явно с посылкой ICMP-сообщения.

Вот такие дела. Отсюда решение. Правила ната на микротике.
1. Правило для проброса портов из интернета:

chain = nat/prerouting,
  input-interface = ether1, 
  dst-ip = 1.2.3.4, 
  protocol = tcp, 
  dst-port = 87, 
  action = dst-nat, 
  dst-nat-address = 192.168.0.2, 
  dst-nat-port = 87.

2. Правило для проброса портов из локалки:

chain = nat/prerouting
  input-interface = ether2, 
  dst-ip 1.2.3.4, 
  src-ip = 192.168.0.0/24, 
  protocol = tcp, 
  dst-port = 87, 
  action = dst-nat, 
  dst-nat-address = 192.168.0.2, 
  dst-nat-port = 87.

3. Правило для source-nat, чтобы ответные пакеты сервера так же пошли через роутер:

chain = nat/postrouting,
  output-interface = ether2, 
  dst-ip = 192.168.0.2, 
  src-ip = 192.168.0.0/24, 
  protocol = tcp, 
  dst-port = 87, 
  action = src-nat, 
  src-nat-address = 192.168.0.1

Вот как-то так. Можно, кстати, пакеты из локалки в локалку метить в цепочке FORWARD и уже на основе метки делать src-nat.

Вот тут хорошо написано почему и как: dev.kafol.net/2011/09/mysql-error-1236-client-requested.html
На всякий случай приведу тут цитату:

Causes:
Master server has crashed and the binlog cache has not been flushed to disk. Slave has recieved a new position, did not recieve data, and data gets lost in a crash (however it might have been written to table, but not in binlog).

Solution:
Use this CHANGE MASTER statement on the slave.
CHANGE MASTER TO MASTER_LOG_FILE=[NEXT FILE], MASTER_LOG_POS=4;
SLAVE START;

in my case that would be

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000034', MASTER_LOG_POS=4;
SLAVE START;

I don't know why the master log position needs to be 4 for the new file.

What happens:
When the master server restarts it logs binary changes to a new binlog file, so that we minimize data loss by skipping to the next file (everything from the previous file was written already).

Prevention:
Add this line to my.cnf:

sync_binlog = 1

With this setting the master server flushes cache in the binlog after every write, so that in case of a crash you can lose one statement at most.