Пара полезных ссылок про лицензирование: MS: Клиентские лицензии и лицензии на управление(с рабочего интернета у меня почему-то страница не нашлась, а через европейский прокис - доступна. Чудеса :).
Тут конечно лучше проконсультироваться с дилером. Я понимаю так - обычные CAL требуются при использовании любых ресурсов Windows Server(кроме сервера терминалов, так отдельное лицензирование). Поэтому если этот сервер будет авторизовывать пользователей домена, или предоставлять другие ресурсы(общие папки, принтеры и пр.) - нужно докупать "Microsoft Windows Server CAL". Тип CAL надо выбирать исходя из ваших обстоятельств. Для себя мы выбрали на устройство.
Число Microsoft Windows Server CAL покупается на "сеть". Т.е., к примеру, у нас 4 сервера(с общими ресурсами) и 100 пользователей/компьютеров, обращающихся к ресурсам. В этом случае нам требуется 100 Windows Server CAL. При этом если взять 2019-ые CAL-ы, они покроют доступ ко всем более старым версиям. А вот как быть если у нас 3 сервера 2008, мы докупаем 2019, но кроме как "запасным" КД 2019-ый работать не будет, у меня понимания нет. Когда мы докупались 2012-ым, то решили не рисковать, и докупили CAL-ы на всех, хотя у нас имелись ранее приобретённые CAL-ы от 2008-го.
Для доступа админа в консоль сервера RDS CAL не требуется, без него RDP будет доступен в "режиме администрирования"(если не ошибаюсь, 3 одновременных сессии).
Максим Сохряков, спасибо что отписались о решении, помогло(поставил RMS, потом зашёл через него и переустановил тимвьюер).
P.S. Тоже 2008-ой сервер, расположен далеко. Ставил там тим по рдп с компа одного из сотрудников того офиса, и попал на такую засаду. Более точные симптомы - пока есть залогиненая сессия, тим серверный отображается онлайн. Стоит сделать логофф, как ID в адресной книге переходит в офлайн, и не подключается. При этом напрямую(по IP) тимвьюер подключается.
В консоли это выглядит так(netstat дёргал через cmd-консоль RMS), что в отсутствии открытой сессии служба тима только слушает, но на сервера не цепляется.
Если открыта сессия(рдп) на сервере:
TCP 0.0.0.0:5938 0.0.0.0:0 LISTENING [TeamViewer_Service.exe]
TCP 10.10.10.3:58983 217.146.13.133:5938 ESTABLISHED
[TeamViewer_Service.exe]
TCP 127.0.0.1:5650 127.0.0.1:58982 TIME_WAIT
TCP 127.0.0.1:5650 127.0.0.1:58986 TIME_WAIT
TCP 127.0.0.1:5650 127.0.0.1:58987 TIME_WAIT
TCP 127.0.0.1:5939 0.0.0.0:0 LISTENING
[TeamViewer_Service.exe]
TCP 127.0.0.1:58977 127.0.0.1:5939 ESTABLISHED
[TeamViewer.exe]
TCP 127.0.0.1:58979 127.0.0.1:58980 ESTABLISHED
[TeamViewer.exe]
TCP 127.0.0.1:58980 127.0.0.1:58979 ESTABLISHED
[TeamViewer.exe]
Если на сервере нет открытых сессий:
TCP 0.0.0.0:5938 0.0.0.0:0 LISTENING
[TeamViewer_Service.exe]
TCP 127.0.0.1:5650 127.0.0.1:58968 TIME_WAIT
TCP 127.0.0.1:5939 0.0.0.0:0 LISTENING
[TeamViewer_Service.exe]
P.P.S. Забыл упомянуть - ставился 11-ый тим. Раньше стоял 7-ой(ставился аналогично, по рдп), но с ним такой проблемы не было. А потом на его поддержку положили болт :).
Ок, надеюсь вам удастся найти ответ - в выходные я ещё попробую повоевать сам, но так как я далеко не сетевик, то могу пропустить очевидное, даже если оно будет у меня перед глазами(как ошибка с адресом).
В любом случае, спасибо за всё вышеизложенное.
192.168.42.0 - домашняя локальная сеть. Для устройств в домашней сети микротик основной шлюз. 192.168.44.0 - сеть офиса. Подключение к офисной сети выполняется самим микротиком(IPSec, конфиг на пастбин - всё что дал export, только реальные адреса и пароли заменил). Когда к удалённой сети обращается компьютер из локалки, микротик знает куда послать. Когда я пробую пинговаться с самого микротика - без "паразитного маршрута" он пытается достичь удалённой сети не через тонель, а через шлюз провайдера. Не знаю как это объяснить ещё нагляднее. IPSec настраивал по документации микротика(Site_to_Site_IpSec_Tunnel), но возможно опять упустил какой-то нюанс.
Спасибо за подробное разъяснение. Ссылку давал на раздел "Routes with interface as a gateway".
Пункт 2(и предложение отключить маршрут) относится к маршруту add distance=1 dst-address=192.168.44.0/24 gateway=br_lan ?
При его отключении с самого микротика перестаёт пинговаться удалённая сеть, а трейс уходит на шлюз провайдера. При этом с компьютеров в сети микротика доступ к 44-ой сети остаётся. Почему при отсутствии этого маршрута микротик спокойно заворачивает в тонель трафик из сети, но не трафик инициированный самим микротиком я понять не могу. Если подскажете в каком направлении копать, буду весьма благодарен - работающий костыль хоть работает, но костылём остаётся, и если есть способ сделать всё правильно, то я конечно предпочту его костыльному решению.
В микротике я нуб, не буду спорить верно или не верно указывать шлюзом интерфейс. Тем не менее:
1. Именно такой маршрут создаёт сам микротик при правильном указании адреса, править динамические правила Winbox не позволяет.
2. wiki.mikrotik.com/index.php?title=Manual:IP/Route&... - в данном разделе я не вижу почему неверно указывать шлюзом интерфейс(множественного или не множественного доступа) вместо IP, может быть поясните почему можно указать несколько инерфейсов в качестве шлюза, но неправильно указывать в качестве шлюза "интерфейс с множественным доступом"? Если вы имеете в виду "routes with interface nexthops are not used for nexthop lookup", то подскажите чем это грозит в данном конкретном частном случае - маршрут до локальной сети роутера, и маршрут до удалённой сети, доступной через поднятой на самом роутере VPN подключение(или просто "так не принято"? )? Что именно не будет работать? В данный момент у меня всё работает. Если указать шлюзом для доступа к 44-ой сети сам микротик(192.168.44.1), то маршрут получается неактивный(unreachable). Есть простые способы объяснить микротику где находится 44-ая подсеть(IPSec VPN к которой на нём же самом и поднят)? Если нет, то меня устроит не каноничный, но работающий вариант с маршрутом на бридж.
Повторюсь. Доступ к pfSense из локалки никак не ограничен(изначально проблема на втором микротике, получающем настройки по DHCP, и хостах локалки, отсутствовала), трафик с микротика в локалку тоже не ограничен. После исправления адреса роутера, и появления динамического маршрута, дубль созданный мною вручную я отключил - всё заработало.
Т.о. ошибка крылась в неверной интерпретации мною интерфейса Winbox, и отсутствием проверки на этот счёт вводимых данных со стороны Winbox - роутер получил адрес с маской /32, и это мешало ему использовать адрес шлюза который не попадал в "подсеть" /32.
P.S. Отключение маршрута к 44-ой сети приводит к недоступности хостов 44-ой сети с микротика(но не из локалки в сети микротика) - т.е. отсутствие, а не наличие этого маршрута мешают достичь нужной сети(с микротика - не критично, но предпочитаю чтобы пинги с микротика так же ходили нормально).
Правило не то чтобы конфликтующее, просто оно должно было создаваться автоматически - как и произошло после того как я исправил ошибку в адресе роутера, на которую мне указал Ilya Demyanov в комментариях к вопросу. Третье правило нужно чтобы с самого роутера пинговались ресурсы 44-ой сети(подключается на микротике по IPSec). По крайней мере если это правило погасить, то хосты удалённой сети с роутера не доступны, хотя с компьютеров в сети микротика к удалённой сети доступ есть. Для меня это странно, но микротик мне вообще очень непревычен после продукции ZyXel, D-Link, Asus, Cisco - такое впечатление что многое из, что того на других роутерах делается автоматически(спрятано "под капотом"), в MikroTik нужно делать самому.
Невероятно, но факт.
Указывал в Winbox 192.168.42.1 в качестве адреса, 255.255.255.0 в качестве сети(сказалась многолетняя привычка к маскам, и микротик не ругался что я вместо адреса сети маску сети указал). Поменял в Winbox адрес на 192.168.42.1/24 - сеть стала 192.168.42.0, добавился автоматический маршрут на локалку(старый, добавленный вручную, безболезненно погасил), и правило маршрутизации стало видеть шлюз!
Огромное спасибо, вы спасли мой рассудок!
Распечатка маршрутов полная(подключаюсь через putty, после выполнения команды сразу возвращается в командную строку), все 6 маршрутов отображаемых в Winbox на месте.
Пардон, одну из реальных подсетей таки засветил(паранойя заставила максимально поменять сети в конфиге перед публикацией, а не только пароли) :(
В контексте описания проблемы правильно читать так:
[user@RB951G-2HnD] > ip address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 192.168.42.1/32 255.255.255.0 br_lan
1 D 95.27.142.111/21 95.27.136.0 WAN
Winbox в одной сети с микротиком, я в той 192.168.44.0(я на работе, микротик дома). Так что не летальные действия(которые не нарушат моё подключение к домашней сети) могу произвести сейчас, летальные - только вечером.
[user@RB951G-2HnD] > ip address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 10.103.42.1/32 255.255.255.0 br_lan
1 D 95.27.142.111/21 95.27.136.0 WAN
Если отключаю этот маршрут, то отваливается Winbox(по IP), только что ещё раз проверил(полезная кнопка Safe Mode :). В какой момент это правило появилось сказать затрудняюсь(экспериментировал много, железка для меня непривычная). Если я правильно понял, этот маршрут должен создаваться автоматом(динамически) на основании IP -> Addresses?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
MS: Клиентские лицензии и лицензии на управление(с рабочего интернета у меня почему-то страница не нашлась, а через европейский прокис - доступна. Чудеса :).
FAQ по лицензиям MS от Инфострат-а