Я могу себе представить только один особый случай, когда это может быть потенциально возможно сделать, и то это будет не точная инфа, а "круги на воде", и те без всякого представления о "connection specific". А в норме - никак.
VasyaID, ай, при чём тут провайдерский нат вообще? Маршрутизировать трафик надо куда-то. Кто-то должен этим заниматься. Занимается этим, как правило, коробочка, именуемая роутером. Да, конечно, можно без него, и маршруты прибить гвоздями на каждой машине с указанием на, в нынешних реалиях, adsl-модем в сети. Но это какой-то отдельный вид извращений по нынешним временам. И всё равно это уже будет не одноранговая сеть, поскольку у вас появляется некий центральный элемент, который выполняет совершенно конкретную роль, которую не могут выполнять прочие участники сети - роль шлюза. Не может у вас быть никакой одноранговости на L2 и L3 МЕЖДУ сетями. Выше - может, запросто.
My_Second_Nickname, там выше в комментариях показал Andrey Barbolin как CID формируется, за что ему спасибо, и, таким образом, в поле CALLERID(num) у вас оказывается попросту пусто. Манго, всё же, видимо, поменяли формирование заголовка from.
Чуйка вела меня в правильном направлении, но не довела)
>И там используется та же конструкция с переводом (num) в (name).
У вас не num в name переводится, а наоборот. В поле num пишется значение name.
У меня на астере в CALLERID(num) корректно без всяких приключений пишется номер, хотя у меня, конечно, не манго и не зебра.
Если манго всё-таки что-то поменял, и в name стало попадать что-то кроме цифр, то в num это значение может просто не передаваться корректно, или не обрабатываться корректно в дальнейшем (хотя это не точно)
Поэтому я и предложил вам посмотреть значение этих полей до вашей обработки. Возможно, стоит смотреть и после.
My_Second_Nickname, вообще нет, я сам по стольку по скольку с астером знаком, и сам изначально не понял о чём речь.
RDNIS, на сколько я понял, тут ни при чём. Вам, я так понимаю, переадресовываются вызовы, и RDNIS - это номер, С которого происходит переадресация.
Что там с CID - из представленного неясно. Повышайте уровень логирования и смотрите ещё.
Попробуйте в самом начале обработки вывести в лог значение переменной Callerid num и name, чтобы посмотреть что в них содержится: ~
exten => 1001,1,Verbose(2,Callerid num is ${CALLERID(num)})
exten => 1001,n,Verbose(2,Callerid name is ${CALLERID(name)})
и дальше уже основную обработку
exten => 1001,n,Set(CALLERID(num)=${CALLERID(name)})
и т.д.
И делайте бэкапы, а то я ща насоветую...
Обратите внимание, опять же, что обработка у вас устанавливает значение CALLERID(num) в CALLERID(name) - зачем? Надо разбираться
MrFlatman, вы можете ручками настроить нужные шары, прописать к ним маршруты и пути непосредственно на каждой рабочей станции, причём на машинах с шарами придётся прописать статические адреса, скорее всего, при этом не придётся трогать сетевое оборудование вообще (без гарантии, но скорее всего; могут быть нюансы с arp, могут быть нюансы с ipsec, с фаерволом между подсетями, ещё с чем-то, о чём я не помню или не знаю - но едва ли это всё касается вашей сети). Но оно вам надо?
Akina,
>опять же VPN через NAT требует внешнего узла - а у соседа доступа в Инет не подвезли...
Ну дело то не в этом, между автором и соседом ната то нет. А вот что ничего кроме ICMP может не ходить - это да.
Akina, ну, во-первых, под локалкой он имеет в виду, очевидно, локалку провайдера, а сегментация у провайдера одному ему известна, и пинговаться всё вполне прекрасно может. TVCON , а, во-вторых, вполне допустима конфигурация, в которой шлюз находится не в вашей подсети, но, при этом, так или иначе должен быть указан маршрут до шлюза. Надо понимать, что шлюз - это просто указание на то, куда должен отправляться весь трафик, для которого маршрут не задан как-либо иначе. В вашей ситуации неправильно настроенная маршрутизация положит вашему соседу как доступ к провайдерской локалке, так и к интернету. В-третьих, вам придётся настроить фаервол на своём wan интерфейсе и что-то думать с nat. В-четвёртых, если провайдер спалит эти манипуляции - а он может - по головке не погладит. В-пятых, то, что пинги проходят - не означает, что на пути между вами и вашим соседом нет никакой фильтрации трафика или множества других подводных камней, о которых может быть известно только вашему провайдеру, так что в любом случае без каких-либо гарантий. Учитывая разные сегменты - всё же, скорее НЕ будет работать, чем будет.
В-шестых, лучше всего и правда поднимите vpn между вами и соседом, если уж так хотите этим заниматься, и если это вообще получится.
Адресная книга выглядит таким вот образом:
Имена компьютеров и групп произвольные, параметры подключения (кодек, блокировка ввода по-умолчанию, звук, и т.д.) могут быть сохранены как индивидуально для каждого компьютера, так и наследоваться от параметров группы; ID выдаются маршрутизатором - серверной частью, но могут быть сохранены и непосредственно ip - тогда маршрутизатор не нужен
Протокол свой, порты настраиваются
Для подключения без одноразового пароля на каждом клиенте должна быть задана пара логин/пароль; с одной стороны при массовой установке это неудобно, с другой стороны пара может быть задана через json при установке или импорте конфигурации.
shurshur, не знаю, меня более-менее устраивает то положение, в котором винда - для десктопа, серверная винда - для AD, для прочего - никсы. Больше меня не устраивает то, что майкрософт ломает то, что и так работало много лет - с вин11.
shurshur, клиентская винда просто не предназначена вообще в роли роутера существовать, так то; а там, hyper-v нетворк манагер, к примеру, вполне себе реализует уже программные вланы, в том числе с поддержкой транков, но только для проброса в vm.
Akina, ну, не вполне; аппаратная поддержка 802.11q - хорошо, но не обязательно
>на дебиане придётся мастерить два виртуальных интерфейса с адресами из показанных подсетей, привязанных к сетевой карте, и маршрутизировать между этими (и остальными) интерфейсами.
Ну да
