Почему заблокирован Хабр?

Ну тогда wireshark'ом убедиться, что HTTP запросы на IP адрес и на хостнейм улетают в одну и ту же сторону (то, что резолвит правильно, еще ничего не значит), и связаться с провайдером.
Ах да — настроек прокси случаем нет?

Подключить к сети компьютеры с одинаковыми mac адресами?

Так пусть обе будут активными. Во вторую, которая с идентичным маком, можно воткнуть джек, у которого RX соединен с TX (чтобы линк поднялся), и назначить основной шлюз с высокой метрикой (если это проверяется). А для первой сделать прописать основной шлюз с низкой метрикой, чтобы только он и использовался. Или пачку статических маршрутов, в сумме охватывающих все маршрутизируемое пространство.
Не будет же софт считать пакеты? Да и более внимательно смотреть на таблицу маршрутизации — вряд ли.

Пляски с mac-ами?

Предлагаю попробовать сменить мак на gi0/2 на другой. Это не должно вызвать заметных проблем — роутер сразу выплюнет GARP. Может, и банальный reload поможет, если что-то в памяти заклинило.

Пляски с mac-ами?

RouterG (и сеть за ним) прекрасно обращаются к соседям по DMZ, и LAN интерфейсу Циски. При обращении же в интернет, тишина

То есть, если я правильно понял, RouterG всегда может обращаться к цискиному gi0/2. NAT поднят? Его дебаг что скажет? И capture увидит отправляемые наружу пакеты?
Какая модель ISR, и какой софт на нем?

Реально ли осуществить такой хитрый тип доступа?

Забыл. Без proxy arp на внутреннем интерфейсе внешнего роутера ничего скорее всего не заработает.

Реально ли осуществить такой хитрый тип доступа?

На здоровье.
(мне не без интереса узнать результат траблшутинга по итогам настройки)

Реально ли осуществить такой хитрый тип доступа?

На самом деле, описанная выше схема с рикошетом пакета от внешнего роутера работает. У нее есть недостаток: неоптимальный путь следования трафика. Является ли это проблемой? Не факт, зависит от объемов трафика. Особых костылей нет, у большинства такая схема уже работает «нечаянно», никакой отдельной конфигурации обычно не требуется.
Но да, если системы должны постоянно обмениваться трафиком, правильнее научить их видеть друг друга по внутренним адресам. Только это тоже может потребовать множества костылей…

Реально ли осуществить такой хитрый тип доступа?

Нужно:
1) Логи соединений.
2) Результат capture. www.cisco.com/en/US/products/ps6120/products_tech_note09186a0080a9edd6.shtml.
Ключевых вопросов два: улетает ли пакет наружу, и возвращается ли он обратно.

Может ли влиять на схему то, что у самой АСы на outside интерфейсе стоит 66.66.66.1 к примеру (в общем из того же диапазона)?

У меня аналогично. Работает успешно.

Реально ли осуществить такой хитрый тип доступа?

У меня к собственному интерфейсу (из inside в outside) последний шаг:
Phase: 7
Type: ROUTE-LOOKUP
Subtype: output and adjacency
Result: ALLOW
Config:
Additional Information:
found next-hop 0.0.0.0 using egress ifc identity
adjacency Active
next-hop mac address 0000.0000.0000 hits 31771172

К соседнему адресу:
Phase: 10
Type: ROUTE-LOOKUP
Subtype: output and adjacency
Result: ALLOW
Config:
Additional Information:
found next-hop 9.9.9.9 using egress ifc outside
adjacency Active
next-hop mac address 001b.54с1.5203 hits 1

Реально ли осуществить такой хитрый тип доступа?

А трансляция на outside идет в адрес интерфейса? С такой схемой не пробовал, но криминала не вижу.
В любом случае, имеет смысл сделать capture на outside и посмотреть, уходят ли пакеты наружу. Может, packet-tracer глючит? Ну и логи посмотреть — создаются ли коннекты.

Реально ли осуществить такой хитрый тип доступа?

Ну и так как я не в курсе радиуса кривизны ваших рук — обязан предложить проверить в packet-tracer доступность любого другого хоста в outside, связь с которым заведомо разрешена и работает. Например, ввести ту же команду, заменив второй адрес на 1.1.1.1 (если ACL разрешает выход в any). Если и тут будет ошибка, то надо правильно вызвать packet-tracer…

Реально ли осуществить такой хитрый тип доступа?

то есть получается что в описанной схеме всё должно работать по умолчанию?

Ключевой момент выделен жирным.

Единственное что нужно чтобы ASA однозначно знала что пакеты например с dest 66.66.66.66 нужно отправлять в сторону роутера.

Чтобы маршрут на что-либо включающее эту сеть смотрел в сторону outside.

По ошибке:

Slowpath security checks failed:
This counter is incremented and packet is dropped when the security appliance is:
1) In routed mode receives a through-the-box:
— L2 broadcast packet
— IPv4 packet with destination IP address equal to 0.0.0.0
— IPv4 packet with source IP address equal to 0.0.0.0
2) In routed or transparent mode and receives a through-the-box IPv4 packet with:
— first octet of the source IP address equal to zero
— source IP address equal to the loopback IP address
— network part of source IP address equal to all 0's
— network part of the source IP address equal to all 1's
— source IP address host part equal to all 0's or all 1's
3) In routed or transparent mode and receives an IPv4 or IPv6 packet with same source
and destination IP addresses

Нет ли ошибки в конфигурации NAT? Можно ли увидеть полный вывод packet-tracer detail (включая его вызов)?

Реально ли осуществить такой хитрый тип доступа?

Другая безумная идея. Статические маршруты на асашке для 6.6.6.6/32 и 7.7.7.7/32 в соответствующие интерфейсы DMZ1 и DMZ2, а также прописать вторичные адреса на адаптерах серверов. Это взаимодействие записать в nat0, чтобы не натило. Навскидку — может сработать, но надо тестировать.

Ну а самое простое — /etc/hosts…

И все таки что же лучше для мобильных устройств TCP или UDP?

Не уверен, что «хрен с ней». Трек получится дырявый.

Важно понимать, что в случае UDP контроль доставки переносится на уровень приложения. То есть все решаемо.

IP-телефония в офисе?

Почему? Вообще не понимаю.

Потому что десяток точек администрирования для одной системы — это кошмар. Будь то SMB или ентерпрайз — неважно.

Нам не нужна куча серверов тут.

Конечно. Два сервера (резервирование), и всё. А не десяток устройств.
Тот пример касался вашего подхода «гора ATAшек», каждую из которых можно назвать мини-сервером со своим интеллектом и своей конфигурацией. Т.е. безусловное зло, особенно в небольшой компании.

логин и пароль. В этом что-то есть плохого?

Очевидно — то, что это не годится для корпоративной сети. Слишком большие сложности. Зачем вбивать массу уникальных данных, когда можно просто воткнуть устройство — и оно само заработает? Особенно это касается SMB, где в последнее время принято использовать труд аутсорсеров, в основном удаленный труд. В этом случае следует свести к минимуму любые действия, которые нельзя выполнить удаленно (задействовав руки человека, который не понимает, что он делает, и не обладает никакой квалификацией в области IT), или которые просто требуют избыточного времени для своего выполнения.

Сценарии «телефония сервис-провайдера для домашних пользователей» и «корпоративная телефония» не имеют практически ничего общего кроме «передают голос». А вы их почему-то приравниваете.

IP-телефония в офисе?

не понимаю чем эта ситауция отличается от SPA + 2 аналоговых телефона от SPA + 1 аналоговый телефон. Можно по-подробнее?

Ситуация — телефонов 10. Сначала. Потом 20. Потом 100. Вы предложили принципиально немасштабируемое решение.

Настройки в SPA2102 ничем не отличаются от настройки IP телефона: пара логин+пароль и адрес сервера.

Мы говорим про корпоративную телефонию. Какие еще логин, пароль и адрес сервера? О чем вы?

SPA может поднимать дополнительно vpn канал и эту железку можно ставить удаленно: для сотрудников вне офиса.

Многие IP телефоны то же самое умеют. Можно вообще wi-fi трубку дать такому сотруднику.

Честно не понимаю в чем у нас заключается спор

Просто вы предлагаете заведомо негодное решение, при виде которого любой администратор сразу повесится. Грубо говоря: организовать ЦОД на сотню физических серверов на базе цепочек 5-портовых неуправляемых свитчей на том основании, что тех, кто имеет ровно один сервер, такое решение устраивает :)

IP-телефония в офисе?

Провайдер дает телефонию через IP и оконечное оборудование: SPA2102 + аналоговый телефон.

Именно так. Одному клиенту с одним телефонным аппаратом. То есть радикально иная ситуация.

Ничем не отличается от 2102

То есть 2102 достаточно вынуть из коробки, воткнуть в сеть (ethernet и 220v), к нему подключить аналоговый телефон — и сразу можно совершать и принимать вызовы (не трогая вообще никаких настроек нигде и не имея никакой информации о самом линксисе и телефоне)? Серьезно? :) А между тем, это, как я уже говорил, является обязательным для любой приличной корпоративной телефонной системы.
Я просто помню, как я мудохался, чтобы мой SPA3102 регистрировался на Cisco CUCM и выполнял роли как FXO шлюза, так и ATA (дома само собой, не на работе). Желательно — без эха при звонке в FXO. Последний пункт так и не удалось победить.

Руководиетелю, секретарю и персоналу, которому необходим функционал, предоставляемый IP телефоном, то IP ставим.
Бухгалтеру и персоналу, кто не активно пользуется телефонией — ставится более бюджетный вариант.

А что мелочиться? Ставим дисковые аппараты.
Сейчас функционал «две линии» — это абсолютный минимум. Даже не обсуждается. Иначе придется рассматривать тот самый отказ от кнопок на телефоне.
И все равно ни копейки не экономится…

Для менеджеров продаж, к примеру, удобнее всего ставить связку: софтфон и беспроводная гарнитура, что позволяет рукам быть свободным и не ограничиваться длиной провода.

Для контакт-центра гарнитура и софтофон — вполне стандартное решение. Остальным удобнее (привычнее) с железным аппаратом. Впрочем, вы совершенно правильно подметили решение, которое также используют в мелких фирмах. Это не ночной кошмар «десятки линксисов».

IP-телефония в офисе?

Мне известен крупнейший региональный провайдер, который всем своим клиентам ставит подобные железки — и все даже очень хорошо работает

Он ставит это под клиента, у которого один телефонный аппарат без возможности перехода на IP, верно?
И нет, тот факт, что аппарат снят с производства — абсолютный стоп-фактор, сильнее которого нет ничего на свете.

Если сравнивать с покупкой IP телефона с администрированием под каждого нового сотрудника

Вы когда-нибудь работали с IP телефонами? Расскажите, в чем состоит администрирование свежекупленного телефона под нового сотрудника.

Мне, например, не нужен весь функционал — мне нужно чтобы звонило

А потом потребуется, чтобы звонило по двум линиям. И пошло-поехало. Вернемся в 90-е с наклейками «нажмите *9, чтобы сделать то-то»?

IP-телефония в офисе?

10 сотрудников. 5 (снятых с производства) 2102-х? Это же абсолютно кошмарный пиздец. Под каждую пару новых сотрудников еще по автономной железке покупать, со своим администрированием. И главное — лишнее и никому ненужное преобразование аналог-цифра.

Далее. Аналоговый телефон, обладающий хотя бы отдаленно схожим функционалом, вовсе не бесплатен, а стоит от 1к и выше (приличные — около тех самых 2к). Итого — вы ни копейки не экономите, но получаете гору ненужного железа, требующего конфигурирования и усложняющего администрирование.

При этом нет абсолютно никакого выигрыша ни в чем по сравнению с установкой IP телефонов. Сплошные минусы и костыли.

IP-телефония в офисе?

и чтобы был стационарный телефон, то нужен шлюз (который преобразует цифру в аналог)

Вы всерьез предлагаете ставить на рабочие места аналоговые телефоны в XXI веке? А ничего, что это получится довольно дорого и совершенно бесполезно?