Давно замечал что при "обфускации" на большом экране все выглядит нечитаемым, но когда вставляешь скриншот - происходит магия и персональные данные начинают просачиваться.
Например в строках 24-26 угадывается Петров Сергей - отчество не понятно,
В 8-10 некий Илья Вячеславович...
vladeol,
Зачем вы так разбиваете данные:
Ну т.е. вот например вашу таблицу можно представить так:
Слева исходная таблица ваши данные "нормализованные", справа две сводных таблицы.
Накидывая в которые - получаете любой срез. Поищите на ютубе уроки по экселю.
Прослушайте те где люди делятся как делать анализ в Экселе, т.к. только вы можете понять ваши потребности, время других специалистов необходимо тоже оплачивать.
Иван Елисеев, Ваш 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. В целом, успехов.
https://www.interfacett.com/blogs/how-to-easily-de...
После входа - новый профиль создастся автоматически.