SerjioS
-
Posts
8 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by SerjioS
-
-
Доброго дня,
Есть работающий 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 -
On 6/11/2019 at 11:56 PM, Le ecureuil said:
Я так подозреваю, что это в связи с массовым использванием IKEv2 для VPN у частников.
Согласен, у меня возникли те же подозрения. Хотя в данном случае у меня не работают обе редакции IKE.
Я в самом начале этой эпопеи спрашивал нескольких разных специалистов Мегафона на этот счёт. Ни один не подтвердил. Но с другой стороны, это может быть их внутренняя инфа, не для разглашения, или они сами не в курсе нововведений.
-
Пробовал я и IKEv1 и IKEv2. Никаких изменений.
Сейчас менеджер из Мегафона, с которым я общаюсь, в отпуске. Так что - пока пауза. По техническим вопросам идти на контакт их служба отказывается напрочь. Периодически продолжают изображать кипучую деятельность, н-р последний раз спросили настройки DMVPN. На вопрос - чего они там рассчитывают найти ТАКОГО - ответа я не получил (хотя я и писал изначально - конфигурация рабочая, её никто не менял несколько лет и "сломалось" всё в один день). Менеджером был предложен вариант некоей тарифной опции, как я понял - разновидность "белого" IP-адреса, для всё группы номеров, но "это не точно" и, блин, всё это ещё надо продавливать внутри самого Мегефона.
-
On 5/24/2019 at 7:28 PM, KorDen said:
UDP/500 - т.е. установка соединения вообще не начинается? Или всё-таки что-то начинается, но потом тухнет (где-то забыли включить NAT-T?)
ip nat udp-port-preserve проблему решает, или нет/не везде/частично? Компонент IPsec на кинетике установлен или нет?
IPsec довольно капризная штука. И да, некоторые провайдерские CG-NAT его умудряются ломать так или иначе. Можно еще вспомнить МТС с поломаной фрагментацией пакетов (хотя может уже починили). Увы, с учетом нынешнего состояния тех.блока опсосов решать подобные технические проблемы очень затруднительно.
Про 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, и соответственно - что оператор мог поломать.
-
On 5/24/2019 at 6:47 PM, Елена Фадеева said:
Здравствуйте! Напишите, пожалуйста, о сложившейся ситуации в личные сообщения наших аккаунтов ВКонтакте (vk.com/megafon), Facebook (facebook.com/MegaFon.ru) или Твиттер (twitter.com/megafonru). Обязательно во всем разберемся!
Добрый день, я ещё с начала Апреля нахожусь в контакте и с техподдержкой (есть активная заявка) и с корпоративным менеджером. Пока что воз и ныне там.
-
16 hours ago, Usatyj said:
Почему бы не назвать оператора, думаю информация была бы не бесполезной.
МегаФон это. Регионы, где столкнулись с этим: СПб, Москва, Московская, Ленинградская, Мурманская и Ярославская области.
Кстати, про их тех. поддержку - раньше у них такой "упёртости" не замечал. До этого возникали пару раз серьёзные вопросы - решилась оперативно. Хз, что на них нашло в этот раз.
-
Дня!
Для связи удалённых площадок с центром использую связку 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:
Spoilerconfig)> show ver
release: 2.15.C.4.0-1
arch: mipsndm:
exact: 0-91000d4
cdate: 11 May 2019bsp:
exact: 0-1767f78
cdate: 13 May 2019ndw:
version: 1.6.27
features: wifi_button,single_usb_port,dual_image,wifi_ft
components: base,dhcpd,miniupnpd,monitor,nathelper-pptp,
pingcheck,ppe,usb,usblte,usbmodem,usbnetmanufacturer: ZyXEL
vendor: ZyXEL
series: Keenetic series
model: Keenetic
hw_version: 01130000-B
hw_id: kg_rh
device: Keenetic 4G III
class: Internet Center
region: RU
description: ZyXEL Keenetic
раздельная маршрутизация OpenVPN и ISP
in Обсуждение IPsec, OpenVPN и других туннелей
Posted
Да, вроде то, что надо, спасибо! Т.е. получается, что для работы 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-адресов/подсетей при настройке маршрутизации и фаервола. А то, ведь, то у Сбера адрес эквайринга изменится, то новый ОФД начнут использовать...