Аварийный вход в LAN через сотовый модем

Andrey Melnikoff написал(а) к Eugene Grosbein в Oct 20 14:11:20 по местному времени:

From: "Andrey Melnikoff" <temnota+news@kmv.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:
> 03 окт. 2020, суббота, в 00:35 NOVT, Andrey Melnikoff написал(а):

> AM>>> Да вопрос не в 20 мегабитах. Вопрос в удалении от вышки. Все эти
> AM>>> перделки-свистелки имеют один интересный ньюанс - если прием плохой, то
> AM>>> оно
> >>> Потому и модель с двумя внешними антеннами LTE.
> AM>> Да они все со внешними антеннами.
> >> Да прям.
> AM> Покажи мне модем формата mini-PCIE с встроенными антеннами. А?
> А вот я ссылочку кидал, там есть аппаратные ревизии с внешними
> и со встроенными антеннами.
Куда ссылочку? Давай прямую ссылку на mini-PCIE формата модем с встроенными
антеннами.

> AM>> Если вам их не доложили, сходить в
> AM>> ближайшую лавку и купить 2 разъема всегда можно. Лень идти - китайцы
> AM>> пришлют хоть чёрта лысого.
> >> А смысл? Давно китайцы сразу предлагают комплектации нужные, докупать ещё.
> AM> Там в сортах говна разбираться надо самому или плотно сидеть на форумах, в
> AM> попытке понять - из каких палок сделан очередной китайский сверхдешевый
> AM> железк. Вон даже ты, рекламируя EOL'ный MR6400 ни разу не скзал, что
> AM> оно-же
> AM> MR-150.
> AM> И скорее всего даже и не знаешь, что там за модем стоит.
> И мне не надо этого знать, пока оно работает.
Понятно, консумер обыкновенус.

[...]

> >> Нету в PPP этих MAC-ов.
> AM> Ну вот, методом нескольких итераций мы таки пришли к выводу, что у нас
> AM> L2TPv2.
> AM> Правда так и не понятно, нахрен он тут нужен.
> L2TP это пример стандартного протокола, который с одной стороны
> стандартно инкапсулирует в себя PPP, а с другой сам стандартно инкапсулируется
> в UDP, чтобы легко пролазить через NAT опсоса, выдающего серые адреса.
3 ненужных прослойки, зато стандартно. Академичненько, так сказать. А чего
не L2TPv3 сразу, там броадкастик с мультикстиком можно получить, SSDP
всякие.

[...]

> AM> 64 bytes from 8.8.8.8: icmp_seq=30 ttl=50 time=78002 ms
> AM> 64 bytes from 8.8.8.8: icmp_seq=31 ttl=50 time=77002 ms
> AM> ....
> AM> выясняй сам, где были эти пакеты и в чьих буферах.

> А я выяснял, причём выяснить это очень легко: подключаешь
> услугу передачи данных напрямую по PPP через USB-модем с симуляцией
> последовательного порта и наблюдаешь такие вот задержки и потери на IP,
> но при этом LCP echo внутри операторского PPP бегают чётенько
> без задержек и потерь. Очереди эти на стороне оператора,
> модемы не виноваты.
Всё, теперь всё понятно. Разговаривать с тобой дальше - бессмысленно, т.к.
ты не в теме. Верь в провайдерский PPP, магический LCP без задержек дальше
сам.

Как и в железные роутеры с "нетакими USB свистками", LTE модемы на pci-e
шине, перегрузки таблиц трансляции и прочие страшные ужасы этого вашего
инторнета.
--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Andrey Melnikoff в Oct 20 19:14:41 по местному времени:

03 окт. 2020, суббота, в 14:11 NOVT, Andrey Melnikoff написал(а):

>>>> Потому и модель с двумя внешними антеннами LTE.
AM>>> Да они все со внешними антеннами.
AM>> Покажи мне модем формата mini-PCIE с встроенными антеннами. А?
>> А вот я ссылочку кидал, там есть аппаратные ревизии с внешними
>> и со встроенными антеннами.
AM> Куда ссылочку? Давай прямую ссылку на mini-PCIE формата модем с встроенными
AM> антеннами.

В данном контексте меня не интересуют "модемы mini-PCIE со встроенными
антеннами", речь про внешние роутеры и ссылочка была на роутер
с аппаратной ревизией со встроенной антенной.

>>> Нету в PPP этих MAC-ов.

AM> А чего не L2TPv3 сразу, там броадкастик с мультикстиком можно получить,
AM> SSDP всякие.

А не надо.

Eugene
--- slrn/1.0.3 (FreeBSD)

Eugene Grosbein написал(а) к Andrey Melnikoff в Oct 20 01:36:48 по местному времени:

03 окт. 2020, суббота, в 14:11 NOVT, Andrey Melnikoff написал(а):

AM> 3 ненужных прослойки, зато стандартно.

Стандартно это важно. А если тебя волнует количество прослоек,
можно сэкономить на L2TP и PPP, оставив только одну инкапсуляцию
UDP-Encap в случае с if_ipsec(4), когда IP-пакеты шифруются
просто IPSec-ом туннельного режима и заворачиваются в UDP
с дополнительными 8 байтами: 4 байта SPI и 4 номера последовательности,
итого 36 байт оверхеда на заголовки.

В качестве демона IKE/ISAKMB годится strongswan из портов,
только что потестировал.

Eugene
--
Сердце - малочувствительный, мускулистый, грубый и жесткий орган.
--- slrn/1.0.3 (FreeBSD)

Dmitry Dolzenko написал(а) к Eugene Grosbein в Oct 20 14:06:58 по местному времени:

From: Dmitry Dolzenko <dol@mig.phys.msu.ru>

28.09.2020 10:42, Eugene Grosbein пишет:
> 26 сент. 2020, суббота, в 14:03 NOVT, Dmitry Dolzenko написал(а):
>
> DD> Арендую VPS, к нему сделаю туннель через tp-link, и резервный mx на этом
> DD> VPS с пропихиванием почты в случае чего по vpn тоннелю на основной MX.
>
> Вообще конкретно с SMTP это не особая проблема, потому что очереди
> на доставку есть у всех серверов отправителей, в крайнем случае
> почта полежит там, при условии что у тебя зарезервирован DNS.
>
> А если не зарезервирован DNS, ты хоть делай себе доступный резервный MX,
> хоть не делай - почта на него даже не пойдет.
>
> И, допустим, ты сделал себе резервный MX и он принимает почту и льёт
> её через резервный канал поверх LTE. А LTE идёт через операторские соты и
> конкурирует за полосу с другими клиентами оператора, которые смотрят
> футбол на ютубчике или киношечки. И вполне может случиться так,
> что почта с резервного MX тебе станет забивать доступную тебе ширину.
>
> А кроме того, ты очень быстро столкнёшься с тем фактом,
> что спамеры очень любят слать спам через низкоприоритетные
> (резервные) MX вместо основного, даже когда основной нормально
> доступен, потому что наивно настроенный резервный MX легче
> принимает всякий мусор. Например, основной MX может сразу отбивать
> почту на несуществующие локальные ящики, а резервный MX
> может принимать на любые адреса домена, затем при попытке доставки
> на основной сервер получит отлуп из-за несуществования имени,
> так что будет сгенерирован DSN на скорее всего подставной
> адрес отправителя и твой резервный MX отправит спам-письмо
> в виде возврата невинной жертве. За такое ты сам быстро попадёшь
> в черные списки.
>
> Это можно пытаться решить с помощью milter-ahead (в случае sendmail)
> или ещё каких наворотов, но я бы вообще сильно не парился
> созданием резервного MX для LTE, почта спокойно полежит в очередях
> серверов отправителей. А вот вторичный внешний DNS завести обязательно.
>
> DD> Плюс скрипт на основном роутере конторы, который переключает роутинг в
> DD> случае проблем на tp-link.
> DD> Есть еще нерешенная проблема с вебсервером конторы, который не виден в
> DD> случае падения канала.
> DD> Первое что приходит на ум - поставить на VPS nginx в режиме reverse
> DD> proxy с работой по 2 каналам. В случае падения основного переключение на
> DD> резерв.
> DD> Или может есть способ лучше?
>
> Обратный прокси на VPS добавит тебе заметных задержек при обращении
> к сайту, а интерактивный НTTP(S) к задержкам чувствителен.
>
> Да, есть способ лучше - подключить второго оператора фиксированной связи :-)
> Это, кстати, кардинально решает проблему с почтой и с DNS:
> почта будет приходить по "резервной" записи MX реально на основной
> почтовый сервер, и DNS будет зарезервирован так же второй записью NS.
>
> А сайт можно вообще вынести на внешний хостинг.
> Качественное резервирование без затрат скорее утопия.
>
> Eugene

Да, сайт надо на внешний хостинг, ты прав.

По поводу второго оператора, тут ничего не выходит, это госучереждение,
и там нельзя второго оператора .
Поэтому и приходится заморачиваться с LTE.

По поводу почты - при падении канала ее критично важно получать и
отправлять, поэтому вариант с лежанием в очереди не подходит.

А если на резервном VPS 25 порт пробросить через туннель на основной
почтовый сервер какой то затычкой. Может тем же ipfw получится?

IPVPS:25 ---vpn ---- IPMAILSERV:25

это не решит проблему с валом отбойников?

/D
--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Dmitry Dolzenko в Oct 20 21:41:24 по местному времени:

14 окт. 2020, среда, в 14:06 NOVT, Dmitry Dolzenko написал(а):

DD> А если на резервном VPS 25 порт пробросить через туннель на основной
DD> почтовый сервер какой то затычкой. Может тем же ipfw получится?
DD> IPVPS:25 ---vpn ---- IPMAILSERV:25
DD> это не решит проблему с валом отбойников?

Да, это вариант. Стандартный redirect_port у ipfw nat/natd это делает.
Причём лучше всего поднять до VPS два туннеля, один через основной канал,
а второй через LTE и запустить на обоих сторонах frr7 с RIPv2 или OSPF
(лучше OSPF) с неравными приоритетами, чтобы приходящая на VPS
почта роутилась по основному каналу, пока он жив, и чтобы трафик
автоматом перероучивался в VPN через LTE, если падает основной канал.

OSPF лучше тем, что он, в отличие от RIPv2, умеет определять
ситуацию с односторонней проходимостью трафика по трассе,
когда анонсы маршрута проходят, а трафик в обратную сторону нет.

OSPF в таком случае рвёт отношение соседства до полного восстановления
канала, а RIPv2 продолжает роутить пакеты в пустоту.

Eugene
--
Устав от вечных упований,
Устав от радостных пиров
--- slrn/1.0.3 (FreeBSD)

Sergey Anohin написал(а) к Eugene Grosbein в Oct 20 14:22:11 по местному времени:

Нello, Eugene!

Помню ты спрашивал сабж

http://pics.rsh.ru/img/IMG<b>2020101...b>oknt07cu.jpg

В общем такой стоит, вроде сошлись на том что он IEEE 802.11n в эхотаге умеет

С наилучшими пожеланиями, Sergey Anohin.

--- wfido

Andrey Melnikoff написал(а) к Eugene Grosbein в Oct 20 21:11:06 по местному времени:

From: "Andrey Melnikoff" <temnota+news@kmv.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:
> 03 окт. 2020, суббота, в 14:11 NOVT, Andrey Melnikoff написал(а):

> AM> 3 ненужных прослойки, зато стандартно.

> Стандартно это важно. А если тебя волнует количество прослоек,
> можно сэкономить на L2TP и PPP, оставив только одну инкапсуляцию
> UDP-Encap в случае с if_ipsec(4), когда IP-пакеты шифруются
> просто IPSec-ом туннельного режима и заворачиваются в UDP
> с дополнительными 8 байтами: 4 байта SPI и 4 номера последовательности,
> итого 36 байт оверхеда на заголовки.
Мне шифровать шифрованное не нужно.

> В качестве демона IKE/ISAKMB годится strongswan из портов,
> только что потестировал.
Ну молодец, только вот изделиям фирмы сисько - место на свалке истории.
Но некоторые так и тянут эту корпоративщину куда не попадя.
--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Andrey Melnikoff в Oct 20 04:28:11 по местному времени:

27 окт. 2020, вторник, в 21:11 NOVT, Andrey Melnikoff написал(а):

>> Стандартно это важно. А если тебя волнует количество прослоек,
>> можно сэкономить на L2TP и PPP, оставив только одну инкапсуляцию
>> UDP-Encap в случае с if_ipsec(4), когда IP-пакеты шифруются
>> просто IPSec-ом туннельного режима и заворачиваются в UDP
>> с дополнительными 8 байтами: 4 байта SPI и 4 номера последовательности,
>> итого 36 байт оверхеда на заголовки.
AM> Мне шифровать шифрованное не нужно.

if_ipsec так и делает, берет нешифрованный IP и шифрует его один раз.

>> В качестве демона IKE/ISAKMB годится strongswan из портов,
>> только что потестировал.
AM> Ну молодец, только вот изделиям фирмы сисько - место на свалке истории.
AM> Но некоторые так и тянут эту корпоративщину куда не попадя.

strongswan не изделие Cisco, а IPSec - публичный стандарт,
а не корпоративщина.

Eugene
--
- Локапалы непобедимы, - сказал Кубера, а девочка подняла кубик
и долго-долго разглядывала его, прежде чем назвать.
--- slrn/1.0.3 (FreeBSD)

Andrey Melnikoff написал(а) к Eugene Grosbein в Oct 20 12:10:53 по местному времени:

From: "Andrey Melnikoff" <temnota+news@kmv.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:
> 27 окт. 2020, вторник, в 21:11 NOVT, Andrey Melnikoff написал(а):

> >> Стандартно это важно. А если тебя волнует количество прослоек,
> >> можно сэкономить на L2TP и PPP, оставив только одну инкапсуляцию
> >> UDP-Encap в случае с if_ipsec(4), когда IP-пакеты шифруются
> >> просто IPSec-ом туннельного режима и заворачиваются в UDP
> >> с дополнительными 8 байтами: 4 байта SPI и 4 номера последовательности,
> >> итого 36 байт оверхеда на заголовки.
> AM> Мне шифровать шифрованное не нужно.
> if_ipsec так и делает, берет нешифрованный IP и шифрует его один раз.
Да-да, а внутри бегает исключительно с NULL cipher ssh/https/rdp и прочием
imap/smtp.

> >> В качестве демона IKE/ISAKMB годится strongswan из портов,
> >> только что потестировал.
> AM> Ну молодец, только вот изделиям фирмы сисько - место на свалке истории.
> AM> Но некоторые так и тянут эту корпоративщину куда не попадя.

> strongswan не изделие Cisco, а IPSec - публичный стандарт,
> а не корпоративщина.
То, что это стандартизировали - это еще не значит, что это придумала не
циска. Как и прочую кучу слабовменяемых в текущем мире нужных протоколов:
GRE (для улучшения которого в реальном мире аж пришлось придумать etherip),
VRRP/НSRP (из-за цисковсих "патентов" в OpenBSD аж нарисовали свой CARP).
Но от этого, протокол придуманный в мире где у каждого есть по глобальной
сеточке адресов класса A, лучше не стал. И в текущие реалии - когда надо
таскать ОДИН IPv4 между кучей нод имея при этом дохренналион IPv6 - без
костылей не натягивается.
--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Andrey Melnikoff в Oct 20 06:00:42 по местному времени:

28 окт. 2020, среда, в 12:10 NOVT, Andrey Melnikoff написал(а):

>>> Стандартно это важно. А если тебя волнует количество прослоек,
>>> можно сэкономить на L2TP и PPP, оставив только одну инкапсуляцию
>>> UDP-Encap в случае с if_ipsec(4), когда IP-пакеты шифруются
>>> просто IPSec-ом туннельного режима и заворачиваются в UDP
>>> с дополнительными 8 байтами: 4 байта SPI и 4 номера последовательности,
>>> итого 36 байт оверхеда на заголовки.
AM>> Мне шифровать шифрованное не нужно.
>> if_ipsec так и делает, берет нешифрованный IP и шифрует его один раз.
AM> Да-да, а внутри бегает исключительно с NULL cipher ssh/https/rdp и прочием
AM> imap/smtp.

А это уже твоё личное дело, что внутри гонять.
И нет никакой разницы с другими типами шифрующих VPN.

Если у тебя внутри всё уже шифрованное, тебе никто не мешает
использовать любую из нешифрующих инкапсуляций, начиная
с L2TP over UDP и заканчивая IPIP/gif или GRE.

>>> В качестве демона IKE/ISAKMB годится strongswan из портов,
>>> только что потестировал.
AM>> Ну молодец, только вот изделиям фирмы сисько - место на свалке истории.
AM>> Но некоторые так и тянут эту корпоративщину куда не попадя.
>> strongswan не изделие Cisco, а IPSec - публичный стандарт,
>> а не корпоративщина.
AM> То, что это стандартизировали - это еще не значит, что это придумала не
AM> циска.

Но это значит, что это не корпоративщина.

AM> Как и прочую кучу слабовменяемых в текущем мире нужных протоколов:
AM> GRE (для улучшения которого в реальном мире аж пришлось придумать etherip),

EtherIP нужен для тех, кто не понимает, что эмулировать Ethernet в L3 VPN незачем
и вообще ничего кроме ethernet не умеет.

AM> VRRP/НSRP (из-за цисковсих "патентов" в OpenBSD аж нарисовали свой CARP).
AM> Но от этого, протокол придуманный в мире где у каждого есть по глобальной
AM> сеточке адресов класса A, лучше не стал.

Никакой связи.

AM> И в текущие реалии - когда надо таскать ОДИН IPv4 между кучей нод
AM> имея при этом дохренналион IPv6 - без костылей не натягивается.

Я без понятия, что значит "таскать один IPv4 между кучей нод".

Eugene
--
Научить не кланяться авторитетам, а исследовать их и сравнивать их поучения
с жизнью. Научить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.
--- slrn/1.0.3 (FreeBSD)