Иван Елисеев, Ваш IIS не поддерживает digest-authentication (модуль не установлен) - стало быть не нужно ничего отключать... Он ее просто не поддерживает, следовательно нечего отключать..
Максим Гришин, понимаете в чем дело, в текущий момент все работает так как мне нужно, 10.10.0.0/16 ходит через туннель, трафик с интерфейса X.X.X.X ходит тоже как нужно мне.
Вопрос только один, когда я пытаюсь достучаться с 192.168.101.100 (ну в целом вообще с любого девайса за микротиком) до X.X.X.X (т.е. к виртуальным машинам через внешний интерфейс) - тут фейл. Т.е.
telnet x.x.x.x 25 с машины 192.168.101.100 (хостовой) никогда не может установится через внешний интерфейс, т.к. подключение идет от внешнего айпи y.y.y.y
т.е. при попытке установить TCP сессию - все пакеты терминируются на микротике т.к. он имеет адрес y.y.y.y.
Я понял что вопрос не самый простой, пока я подозреваю придется воротить суровый костыль - вроде двойного ната (или оставить всё как есть).
Машины из 10.10.0.0/16 исходящий трафик тоже должны гонять через VPS, извиняюсь не уточнил это в задаче. Т.е. mangle нужен. Задача в другом (выше другому отвечающему я отписал в комментарии уточнение).
Возможно я плохой объясняльщик.
Еще раз попробую пояснить:
Если попытаться подключится к внешнему IP адресу VPS с хостовой машины 192.168.101.100 например на smtp:25:
telnet x.x.x.x 25
(допустим на VPS iptables делает dst-nat на 10.10.13.111:25 )
то для этой машин 10.10.13.111 выглядит так что пакет пришел с адреса y.y.y.y (но прошёл он через туннель openvpn с VPS) т.е. моего маршрутизатора (это его статика) - и TCP сессии не устанавливается.
Всё работает как мне нужно если запросы приходят не из-за mikrotik (из вне), основная проблема только обращение к сервисам из-за того же маршрутизатора. В целом то работать можно, как смог пояснил.
попробуйте посмотреть в ip->routes, может кто-то прописал статический маршрут на 212.90.165.230 - на шлюз или интерфейс которого нет.
Посмотрите в таблице Firewall->Forward - нет ли там какого явного запрета на этот айпи.
Попробуйте сделать /export file=config.txt в консоли в файл и поискать вхождения либо IP либо medoc.ua (например открыв файл в блокноте).
Дел не в этом, сделайте "ping joyukasonos.pw", станет понятно что работать это не будет. Автор вопроса имеет ввиду что даже тот же самый ресурс не открывается. Причина отсутствие записи А в днс для домена joyukasonos.pw.
программисты гугл негодуют. уже в ошибке зафиксирована причина ошибки на их родном языке, но человеки существа коварные, раньше они обращались за помощью к богу и молились что бы не гневался и не посылал гром и молнии, теперь им в их мирских вопросах помогает замбога. :-)
Сергей Бровко, я вам и объяснил ситуацию. Почему и привел ссылку с объяснением как правильно именовать домен и избежать ошибок. Еще раз:
Ваш контроллер домена, точнее служба ДНС на вашем контроллере домена обслуживает ДНС зону site.ru. Все ваши локальные клиенты используют ваш внутренний ДНС и по любым запросам к хостам *.site.ru обращаются в локальный ДНС - в локальном ДНС нет записи dev.site.ru - с какой стати DNS с контроллера должен форвардить запрос на внешний DNS если он является авторитативным за эту зону.
Т.е. у вас неверный дизайн, точнее допустимый, он называется Split DNS (можете почитать про него подробно).
Исправить ситуацию можно дублируя DNS записи в обоих DNS(внешний, внутренний). Но делать это придется вручную, всегда. Ну либо скриптами. Вот почему важно правильно спланировать имя AD домена.
Сдаётся мне что при покупке домена в Godaddy было подтверждено лицензионное соглашение что пользователь не имеет право переносить домен к другому регистратору в течении скольких то лет. Но это только моё предположение. И пунктик наверняка есть: в случае переноса домена - оплатить стоимость домена полностью.
Думаю не стоит недооценивать буржуев, они про все эти схемы знают. (сейчас местные интернет провайдеры так же заключают договоры, вы не имеете права разрывать договор)
sinij, не совсем понял тему с банером "helo". EDGE subscription создает безопасный канал общения между EDGE и HUB-MBX, если нужно поменять банер на EDGE для внешних подключений, то это необходимо делать на Receive Connectors самих EDGE серверов.
Но в целом если все устраивает и работает, то и хорошо.
sinij, имейте ввиду что EDGE'ы начнут отбивать входящую почту если вы удалите подписку совсем. В вашем случае я бы закрыл портом порт 25ый в ночь - тогда серера отправителей будут думать что сервер не доступен и подключатся позже. После всех работ - порт 25 откроете - почта с задержкой но придет на эджи и отправится по майлбоксам.
По поводу вопроса о двух эджей - выходит что у вас сделано для High Avalability, в таком случае у вас должно быть только два коннектора (у вас 3), оба сервера должны быть в Source Servers. В целом, успехов.
sinij, Вот это смущает в коннекторе "EdgeSync - Inbound to domain":
HomeMTA : DOMAIN.local/Configuration/Deleted Objects/Microsoft MTA
DEL:6b7bc2eb-6f28-4b87-ac20-18c04e4ad1e7
HomeMtaServerId : DOMAIN.local/Configuration/Deleted Objects/Microsoft MTA
DEL:6b7bc2eb-6f28-4b87-ac20-18c04e4ad1e7
Т.е. аттрибуты ссылаются на удалённый объект. Наверное имеет смысл переподписать оба эджа (либо удалить все подписки и создать новые - но тут входящая почта начнет генерить NDR).
Еще вопрос - для чего нужно 2 эджа, для высокой доступности или они обслуживают два разных МХ?
sinij, а что у вас в "Source Servers" send-connectors смотрящих на эджи?
Вообще сколько их у вас и посмотреть вывод:
get-sendconnector Ed* | ft Identity, SourceTransportServers
Dmitry, делайте csv как вам говорит Лентяй - первая строка заголовки полей через точку с запятой (или запятой, зависит от локали) - можно вообще первой строкой сделать "sep=;" что бы это исключить и дальше вторая строка заголовки полей через точку с запятой, следующие строки данные через точку с запятой.
Test-ServiceHealth на новом эдже - точно запущены все службы?
Почему приняли решение поднять EDGE новый на CU18, если старый на CU15 - и какой уровень CU на МБХ?
RJ94, всё я понял. Невнимательно прочитал что вы именно хотели через Exchange это сделать. Просто я имел ввиду часто так бывает, по доброму сделаешь, там autoreply настроишь или правило удалишь - и это аккуратно ложится на плечи администратора, т.к. если пользователь узнал что это можно делать на серверной стороне - все следующие схожие реквесты будут роутиться по этому маршруту.
