SerjioS

Да, вроде то, что надо, спасибо! Т.е. получается, что для работы split nat надо прописать на каждом Keenetic ip nat ISP ip nat LTE ip static Home ISP ip static Home LTE Плюс для каждого конкретного хоста что-то вроде. ip route 185.15.172.18 ISP auto !OFD.RU ip route 185.15.172.18 LTE auto !OFD.RU Жаль, конечно, что не получается централизовано, через OpenVPN, раздавать маршруты. И/или что нельзя использовать группы IP-адресов/подсетей при настройке маршрутизации и фаервола. А то, ведь, то у Сбера адрес эквайринга изменится, то новый ОФД начнут использовать...

Доброго дня, Есть работающий OpenVPN сервер (pfSense). Используется в режиме Remote Access TLS для доступа из нескольких магазинов (Keenetic 4G) к серверам в офисе (пусть будет 192.168.2.0/24). Типовая конфигурация магазина: Keenetic 4G (KN-1210) ver. 3.5.6; Настройки OpenVPN - TUN, subnet, 10.11.12.0/24; Домашняя сеть магазина - 192.168.172.0/24; Весь трафик из домашней сети магазина заворачивается в OpenVPN - redirect-gateway def1,route-gateway 10.11.12.1; Хосты в офисе и в магазинах видят друг-друга; Локальный NAT на Keenetic отключен (no ip nat Home, no ip nat OpenVPN0) - NAT выполняется на Firewall в офисе. Приоритеты подключений: OpenVPN ISP LTE Всё было хорошо и тут возник вопрос: есть ли возможность трафик на некоторые IP - эквайринг, ОФД и т.п. (н-р 185.15.172.18) таки выпускать через локальный NAT на Keenetic? Пробовал включить NAT для Home и вместо IP из домашней сети магазина (н-р 192.168.117.4) в офис стал отдаваться IP назначенный самому Keenetic в OpenVPN (н-р 10.11.12.14). Т.е. было Касса -> Keenetic -> OpenVPN -> pfSense -> NAT+Firewall -> Internet, а стало Касса -> Keenetic+NAT -> OpenVPN -> pfSense -> ??? Так же пробовал указать в настройках OpenVPN - push "route 185.15.172.18 255.255.255.255 net_gateway"; но в логах на Keenetic "Фев 3 01:53:04 ndm Network::RoutingTable: gateway is unreachable." =( Настройки интерфейсов Home и OpenVPN. Interface, name = "Home" id: Bridge0 index: 0 type: Bridge description: *Shop interface-name: Home link: up connected: yes state: up mtu: 1500 tx-queue: 0 address: 192.168.117.1 mask: 255.255.255.0 uptime: 740 global: no security-level: private mac: *:*:*:*:*:* auth-type: none bridge: interface, link = yes, inherited = yes: FastEthernet0/Vlan1 Interface, name = "OpenVPN0" id: OpenVPN0 index: 0 type: OpenVPN description: *Gate interface-name: OpenVPN0 link: up connected: yes state: up role: misc mtu: 1500 tx-queue: 0 address: 10.11.12.14 mask: 255.255.255.0 uptime: 6430 global: yes defaultgw: yes priority: 33117 security-level: private mac: *:*:*:*:*:* auth-type: none country: RU organization: *Retail common-name: *Retail Server Cert tunnel-protocol: udp via: UsbLte0

Согласен, у меня возникли те же подозрения. Хотя в данном случае у меня не работают обе редакции IKE. Я в самом начале этой эпопеи спрашивал нескольких разных специалистов Мегафона на этот счёт. Ни один не подтвердил. Но с другой стороны, это может быть их внутренняя инфа, не для разглашения, или они сами не в курсе нововведений.

Пробовал я и IKEv1 и IKEv2. Никаких изменений. Сейчас менеджер из Мегафона, с которым я общаюсь, в отпуске. Так что - пока пауза. По техническим вопросам идти на контакт их служба отказывается напрочь. Периодически продолжают изображать кипучую деятельность, н-р последний раз спросили настройки DMVPN. На вопрос - чего они там рассчитывают найти ТАКОГО - ответа я не получил (хотя я и писал изначально - конфигурация рабочая, её никто не менял несколько лет и "сломалось" всё в один день). Менеджером был предложен вариант некоей тарифной опции, как я понял - разновидность "белого" IP-адреса, для всё группы номеров, но "это не точно" и, блин, всё это ещё надо продавливать внутри самого Мегефона.

Про UDP/500 - соединение инициируется со стороны удалённой площадки. И на Cisco и на Zyxel дампы трафика это показывают. Раньше пакеты спокойно доходили до DMVPN Hub'а в центре. Сейчас до него пакеты просто не доходят. Только вот, ДО Апреля всё прекрасно работало. Сама схема отлажена и используется уже несколько лет - все необходимые NAT-T за это время были включены. Соответствующие опции присутствуют в пакетах, что видно при анализе дампов трафика. Про ip nat udp-port-preserve - да, помогает всегда. Или так или подключать на SIM фиксированный IP (и прописывать соответствующую APN). Я пробовал и обычный IPSec и с IKEv2, увы. Ровно по этим же причинам компонента IPsec на кинетиках не установлено, собственно - уже после Апреля я поробовал его добавлять (и не только его) - бесполезно, в моём случае не помогло. "IPsec довольно капризная штука. И да, некоторые провайдерские CG-NAT его умудряются ломать так или иначе" - истинно так. Жаль, нет более подробного описания опции "ip nat udp-port-preserve" глядишь, было бы понятно почему она помогает преодолевать CG NAT, и соответственно - что оператор мог поломать.

Добрый день, я ещё с начала Апреля нахожусь в контакте и с техподдержкой (есть активная заявка) и с корпоративным менеджером. Пока что воз и ныне там.

МегаФон это. Регионы, где столкнулись с этим: СПб, Москва, Московская, Ленинградская, Мурманская и Ярославская области. Кстати, про их тех. поддержку - раньше у них такой "упёртости" не замечал. До этого возникали пару раз серьёзные вопросы - решилась оперативно. Хз, что на них нашло в этот раз.

Дня! Для связи удалённых площадок с центром использую связку Cisco 881 + Keenetic 4G III (rev.B, release: 2.15.C.4.0-1) c USB-LTE модемом, поверх этого бегает IPSec (DMVPN). Однако, с Апреля начались "чудеса" с одним из операторов сотовой связи - перестал проходить IPSec (DMVPN). Как показал анализ трафика - пакеты (UDP/500) просто не доходят до центра. "Зачем и почему" - техподдержка оператора реагирует в высшей степени неторопливо и занимается какой-то дурью типа "почему у вас на динамическом(!) подключении... меняется IP-адрес" (я серьёзно, это практически цитата). Из-за этого пришлось искать "заплатку" на стороне Keenetic. "Пляски с бубном" выдали два варианта решения: Откат на сильно более раннюю прошивку - 2.7.х и ниже. Через CLI включать в конфигурацию (config)> ip nat udp-port-preserve Кстати, попутно выяснилось ещё несколько "чудесатых" условий: проблемы есть в нескольких регионах и только с одним конкретным оператором; при установке в тот же USB-модем SIM-карты от другого оператора - IPSec (DMVPN) восстанавливается, даже перезапускать оборудование не приходится; проблемы есть при использовании динамического IP, т.е. если на SIM-карту подключить фиксированный IP и прописать соответствующий APN - связь, опять же, восстанавливается, без перезагрузки. С учётом, что до этого несколько лет такая схема работала без проблем, то с "моей колокольни" видится - источник проблемы где-то районе операторского CG NAT. Но время уходит, а оператор не может ни подтвердить ни опровергнуть это. Версия Keenetic: