Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Проблема доступа по SSH к компьютеру, подуключенному к сети через 3G.
195 views
Skip to first unread message
Dmitrii Kashin
Sep 25, 2013, 8:10:02 AM9/25/13
to
У меня есть настроенный OpenVPN в облаке, к которому автоматически
подключаются все мои рабочие машины сразу при поднятии сети. Недавно
появился компьютер в, скажем так, труднодоступной зоне - где выйти в
интернет можно только через 3G.
Собственно, я купил модем Huawei E398 и сим-карту от MTS. Настроил сеть,
все прекрасно работает. Подключился к VPN как обычно.
Но тут я наблюдаю странное поведение. Подключиться с этой машины к
любому компу в передлах VPN - запросто. А вот из VPN к конкретно этой
машине - никак.
Что забавно, компьютер очень даже успешно пингуется командой ping
(латентность где-то от 1 до 2 секунд) откуда угодно в VPN-сети. Но если
попробовать nmap-ом просканировать порты на этой машине - nmap отвечает,
что хост кажется ему выключенным.
Я пробовал менять порт, на котором машина слушает ssh на 2222 и на 80, я
пробовал давать четкую директиву слушать на адресе vpn-сети - и ничего.
Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
подключаются все мои рабочие машины сразу при поднятии сети. Недавно
появился компьютер в, скажем так, труднодоступной зоне - где выйти в
интернет можно только через 3G.
Собственно, я купил модем Huawei E398 и сим-карту от MTS. Настроил сеть,
все прекрасно работает. Подключился к VPN как обычно.
Но тут я наблюдаю странное поведение. Подключиться с этой машины к
любому компу в передлах VPN - запросто. А вот из VPN к конкретно этой
машине - никак.
Что забавно, компьютер очень даже успешно пингуется командой ping
(латентность где-то от 1 до 2 секунд) откуда угодно в VPN-сети. Но если
попробовать nmap-ом просканировать порты на этой машине - nmap отвечает,
что хост кажется ему выключенным.
Я пробовал менять порт, на котором машина слушает ssh на 2222 и на 80, я
пробовал давать четкую директиву слушать на адресе vpn-сети - и ничего.
Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
Alexander Wiedergold WIEDERGOLD.NET
Sep 25, 2013, 10:10:01 AM9/25/13
to
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/5242ED82...@web.de
Victor Wagner
Sep 25, 2013, 11:50:01 AM9/25/13
to
On 2013.09.25 at 16:08:49 +0400, Dmitrii Kashin wrote:
> Но тут я наблюдаю странное поведение. Подключиться с этой машины к
> любому компу в передлах VPN - запросто. А вот из VPN к конкретно этой
> машине - никак.
>
> Что забавно, компьютер очень даже успешно пингуется командой ping
> (латентность где-то от 1 до 2 секунд) откуда угодно в VPN-сети. Но если
> попробовать nmap-ом просканировать порты на этой машине - nmap отвечает,
> что хост кажется ему выключенным.
>
> Я пробовал менять порт, на котором машина слушает ssh на 2222 и на 80, я
> пробовал давать четкую директиву слушать на адресе vpn-сети - и ничего.
>
> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
Может быть умолчательные настройки файрволла в случае ppp-соединения
> Но тут я наблюдаю странное поведение. Подключиться с этой машины к
> любому компу в передлах VPN - запросто. А вот из VPN к конкретно этой
> машине - никак.
>
> Что забавно, компьютер очень даже успешно пингуется командой ping
> (латентность где-то от 1 до 2 секунд) откуда угодно в VPN-сети. Но если
> попробовать nmap-ом просканировать порты на этой машине - nmap отвечает,
> что хост кажется ему выключенным.
>
> Я пробовал менять порт, на котором машина слушает ssh на 2222 и на 80, я
> пробовал давать четкую директиву слушать на адресе vpn-сети - и ничего.
>
> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
(частным случаем которого является использование сотового модема) и
сильно отличаются от других вариантов?
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Андрей Михалёв
Sep 25, 2013, 12:10:03 PM9/25/13
to
> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.Может быть умолчательные настройки файрволла в случае ppp-соединения
(частным случаем которого является использование сотового модема) и
сильно отличаются от других вариантов?
Запросы на соединение с вашим компом просто блокируются провайдером. этож 3G! =)
С уважением, Андрей Михалёв
Системный администратор
451-023-713
endru.mihalev
451-023-713 endru.mihalev
Семен Кландров
Sep 25, 2013, 12:50:01 PM9/25/13
to
> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
Сталкивался с той же проблемой, используя 3G модем от Мегафон. Пришел к выводу, что скорее всего это дело рук провайдера. Хотя лучше всё-таки сами и спросите у вашего провайдера.
Aleksandr Sytar
Sep 25, 2013, 2:00:02 PM9/25/13
to
> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
Сталкивался с той же проблемой, используя 3G модем от Мегафон. Пришел к выводу, что скорее всего это дело рук провайдера. Хотя лучше всё-таки сами и спросите у вашего провайдера.
У меня, например, резервный канал на некотором оборудовании идет через 3G Мегафона и я с подобным не сталкивался. Так что я бы не стал обобщать.
Я бы топикстартеру посоветовал проверить роутинг до искомой машины из VPN
Dmitrii Kashin
Sep 25, 2013, 2:00:02 PM9/25/13
to
Victor Wagner <vi...@wagner.pp.ru> writes:
> On 2013.09.25 at 16:08:49 +0400, Dmitrii Kashin wrote:
>
>> Но тут я наблюдаю странное поведение. Подключиться с этой машины к
>> любому компу в передлах VPN - запросто. А вот из VPN к конкретно этой
>> машине - никак.
>>
>> Что забавно, компьютер очень даже успешно пингуется командой ping
>> (латентность где-то от 1 до 2 секунд) откуда угодно в VPN-сети. Но если
>> попробовать nmap-ом просканировать порты на этой машине - nmap отвечает,
>> что хост кажется ему выключенным.
>>
>> Я пробовал менять порт, на котором машина слушает ssh на 2222 и на 80, я
>> пробовал давать четкую директиву слушать на адресе vpn-сети - и ничего.
>>
>> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
>
> Может быть умолчательные настройки файрволла в случае ppp-соединения
> (частным случаем которого является использование сотового модема) и
> сильно отличаются от других вариантов?
Виктор, вот какое дело - у меня никаких настроек netfilter нет и в
> On 2013.09.25 at 16:08:49 +0400, Dmitrii Kashin wrote:
>
>> Но тут я наблюдаю странное поведение. Подключиться с этой машины к
>> любому компу в передлах VPN - запросто. А вот из VPN к конкретно этой
>> машине - никак.
>>
>> Что забавно, компьютер очень даже успешно пингуется командой ping
>> (латентность где-то от 1 до 2 секунд) откуда угодно в VPN-сети. Но если
>> попробовать nmap-ом просканировать порты на этой машине - nmap отвечает,
>> что хост кажется ему выключенным.
>>
>> Я пробовал менять порт, на котором машина слушает ssh на 2222 и на 80, я
>> пробовал давать четкую директиву слушать на адресе vpn-сети - и ничего.
>>
>> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
>
> Может быть умолчательные настройки файрволла в случае ppp-соединения
> (частным случаем которого является использование сотового модема) и
> сильно отличаются от других вариантов?
помине. Во всех таблицах все цепочки девственно пусты.
Все, что я использую для маршрутизации - в sysctl установил
net.ipv4.ip_forward=1, да дополнительные маршруты, которые выставил сам
openvpn при запуске:
192.168.247.2 dev tun0 proto kernel scope link src 192.168.247.1
192.168.247.0/24 via 192.168.247.2 dev tun0
Этого хватает для того, чтобы все компы друг друга видели. Пинги-то
идут. Но почему-то не хватает для того, чтобы я мог подключиться по
ssh.
Мне пока кажется разумным предположение, что мой провайдер 3g что-то
режет, обратился к VNC-овцам с этим вопросом, жду ответ.
Dmitrii Kashin
Sep 25, 2013, 2:10:02 PM9/25/13
to
Семен Кландров <ort...@gmail.com> writes:
>> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
>
> Сталкивался с той же проблемой, используя 3G модем от Мегафон. Пришел к
> выводу, что скорее всего это дело рук провайдера. Хотя лучше всё-таки сами
> и спросите у вашего провайдера.
Семен, а справились с ней как? Нашли другого провайдера? Если да, то какого?
>> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
>
> Сталкивался с той же проблемой, используя 3G модем от Мегафон. Пришел к
> выводу, что скорее всего это дело рук провайдера. Хотя лучше всё-таки сами
> и спросите у вашего провайдера.
Семен Кландров
Sep 25, 2013, 2:20:02 PM9/25/13
to
25 сентября 2013 г., 21:57 пользователь Dmitrii Kashin <fre...@freehck.ru> написал:
Семен, а справились с ней как? Нашли другого провайдера? Если да, то какого?
Никак не справился, просто отпала необходимость в SSH-соединении. Но у меня было даже хуже - ping не проходил (я так и не понял, почему, но остановился на том, что провайдер всё же блокирует). 3G от Мегафон до сих пор пользуюсь, но только в качестве подключения для домашнего компьютера.
Mikhail A Antonov
Sep 25, 2013, 3:10:01 PM9/25/13
to
25.09.2013 16:08, Dmitrii Kashin пишет:Я для начала посмотрел бы tcpdump на всех доступных участках. Приходит
ли трафик на ppp-соединение? Приходит ли трафик внутри vpn-соединения?
Есть ли ответы? Туда ли уходят?
ли трафик на ppp-соединение? Приходит ли трафик внутри vpn-соединения?
Есть ли ответы? Туда ли уходят?
--
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru
Alexander Wiedergold WIEDERGOLD.NET
Sep 26, 2013, 10:40:02 AM9/26/13
to
Am 26.09.2013 09:21, schrieb alexander
barakin (aka sash-kan):
25.09.2013, 20:41, "Семен Кландров" <ort...@gmail.com>:
> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.Сталкивался с той же проблемой, используя 3G модем от Мегафон. Пришел к выводу, что скорее всего это дело рук провайдера. Хотя лучше всё-таки сами и спросите у вашего провайдера.
25 сентября 2013 г., 20:01 пользователь Андрей Михалёв <end...@yandex.ru> написал:
> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.Может быть умолчательные настройки файрволла в случае ppp-соединения
(частным случаем которого является использование сотового модема) и
сильно отличаются от других вариантов?Запросы на соединение с вашим компом просто блокируются провайдером. этож 3G! =)
лудше Сателит поставитьсуровые пошли провайдеры…парсят шифрованный трафик — как семечки лузгают.
p.s. я в курсе про "cipher none".
Artem Chuprina
Sep 26, 2013, 1:10:01 PM9/26/13
to
alexander barakin (aka sash-kan) -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 11:21:38 +0400:
>> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
ab(s> Сталкивался с той же проблемой, используя 3G модем от Мегафон. Пришел к выводу, что скорее всего это дело рук провайдера. Хотя лучше всё-таки сами и спросите у
ab(s> вашего провайдера.
ab(s> 25 сентября 2013 г., 20:01 пользователь Андрей Михалёв <end...@yandex.ru> написал:
>> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
ab(s> Может быть умолчательные настройки файрволла в случае ppp-соединения
ab(s> (частным случаем которого является использование сотового модема) и
ab(s> сильно отличаются от других вариантов?
ab(s>
ab(s> Запросы на соединение с вашим компом просто блокируются провайдером. этож 3G! =)
ab(s> суровые пошли провайдеры…
ab(s> парсят шифрованный трафик — как семечки лузгают.
Для того, чтобы заблокировать входящий запрос, совершенно не обязательно
парсить шифрованный трафик. Ну, за исключением варианта OpenVPN over
TCP c настроенным keepalive.
Да, я тоже в курсе, что в других вариантах тоже иногда можно настроить
такой keepalive, чтобы файрволы провайдера не продалбывали соединение.
Но обычно это будет довольно частый keepalive, типичное время
протухания, допустим, UDP-"сессии" в подобном файрволе - секунд 30.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87ioxn8...@wizzle.ran.pp.ru
>> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
ab(s> вашего провайдера.
ab(s> 25 сентября 2013 г., 20:01 пользователь Андрей Михалёв <end...@yandex.ru> написал:
>> Если честно, я не знаю, куда копать. Посоветуйте что-нибудь пожалуйста.
ab(s> (частным случаем которого является использование сотового модема) и
ab(s> сильно отличаются от других вариантов?
ab(s>
ab(s> Запросы на соединение с вашим компом просто блокируются провайдером. этож 3G! =)
ab(s> суровые пошли провайдеры…
ab(s> парсят шифрованный трафик — как семечки лузгают.
Для того, чтобы заблокировать входящий запрос, совершенно не обязательно
парсить шифрованный трафик. Ну, за исключением варианта OpenVPN over
TCP c настроенным keepalive.
Да, я тоже в курсе, что в других вариантах тоже иногда можно настроить
такой keepalive, чтобы файрволы провайдера не продалбывали соединение.
Но обычно это будет довольно частый keepalive, типичное время
протухания, допустим, UDP-"сессии" в подобном файрволе - секунд 30.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Eugene Berdnikov
Sep 26, 2013, 1:40:02 PM9/26/13
to
On Thu, Sep 26, 2013 at 09:08:46PM +0400, Artem Chuprina wrote:
> alexander barakin (aka sash-kan) -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 11:21:38 +0400:
> ab(s> О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫ 3G! О©╫=)
> alexander barakin (aka sash-kan) -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 11:21:38 +0400:
>
> ab(s> О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫???
> ab(s> О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ ??? О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫.
>
> О©╫О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫? But why? :) О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫дёО©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ vpn-О©╫О©╫О©╫О©╫О©╫О©╫О©╫,
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫
О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ vpn.
--
Eugene Berdnikov
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitrii Kashin
Sep 26, 2013, 2:10:02 PM9/26/13
to
Eugene Berdnikov <b...@protva.ru> writes:
> On Thu, Sep 26, 2013 at 09:08:46PM +0400, Artem Chuprina wrote:
>> alexander barakin (aka sash-kan) -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 11:21:38 +0400:
> On Thu, Sep 26, 2013 at 09:08:46PM +0400, Artem Chuprina wrote:
>> alexander barakin (aka sash-kan) -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 11:21:38 +0400:
>> ab(s> Запросы на соединение с вашим компом просто блокируются провайдером. этож 3G! =)
>>
>> ab(s> суровые пошли провайдеры???
>>
>> ab(s> парсят шифрованный трафик ??? как семечки лузгают.
>>
>> Для того, чтобы заблокировать входящий запрос, совершенно не обязательно
>> парсить шифрованный трафик.
>
> Чё, правда? But why? :) Речь-то идёт о трафике внутри vpn-туннеля,
>> Для того, чтобы заблокировать входящий запрос, совершенно не обязательно
>> парсить шифрованный трафик.
>
> установленного от хоста в какое-то внешнее облако.
Ну, VPN-туннель у меня работает по UDP. Это не постоянно поддерживаемое
соединение. Раз в 10 секунд (настраивается параметром keepalive в
конфиге openvpn) происходит обмен сообщениями, откуда vpn-сервер и
узнает обратный адрес. Кстати, а не в этом ли может быть дело? Вот у
меня дома внешний адрес, судя по всему не так уж часто меняется, потому
все и работает... А вот с 3g-модемом дело может быть обстоит куда хуже.
Может, действительно для компа за 3g-модемом лучше использовать tcp?
Артём, спасибо!
> Во всяком случае это единственная видимая мне причина, по которой
> в этой дискуссии упоминается vpn.
Я думаю, что в случае возникновения ситуации "ничего не понятно" и "идей
больше нет", есть смысл в задаваемом вопросе указывать *все*
обстоятельства дела, даже если не ясна их важность для решения проблемы.
Artem Chuprina
Sep 26, 2013, 2:30:02 PM9/26/13
to
Eugene Berdnikov -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 21:32:17 +0400:
>> alexander barakin (aka sash-kan) -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 11:21:38 +0400:
>> ab(s> парсят шифрованный трафик ??? как семечки лузгают.
EB> установленного от хоста в какое-то внешнее облако.
Так VPN-туннель-то тоже в чем-то идет. Например, OpenVPN ходит либо
внутри UDP, либо внутри TCP. Если таймаут на (в терминах iptables)
RELATED,ESTABLISHED на файрволе провайдера меньше, чем keepalive, то
пакет, начинающий "сессию" внутри туннеля, может оказаться начинающим ее
и снаружи оного с кочки зрения оного файрвола. И привет. А на UDP
keepalive на файрволе может быть и маленьким, протокол-то sessionless.
Разумеется, гарантии у такой блокировки не будет. А вот проблему
создать она может.
В "официальных" VPN я не силен, каковы там особенности внешних
протоколов, не знаю.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/871u4b8...@wizzle.ran.pp.ru
>> alexander barakin (aka sash-kan) -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 11:21:38 +0400:
>> ab(s> Запросы на соединение с вашим компом просто блокируются провайдером. этож 3G! =)
>>
>> ab(s> суровые пошли провайдеры???
>>
>> ab(s> парсят шифрованный трафик ??? как семечки лузгают.
>>
>> Для того, чтобы заблокировать входящий запрос, совершенно не обязательно
>> парсить шифрованный трафик.
EB> Чё, правда? But why? :) Речь-то идёт о трафике внутри vpn-туннеля,
>> Для того, чтобы заблокировать входящий запрос, совершенно не обязательно
>> парсить шифрованный трафик.
EB> установленного от хоста в какое-то внешнее облако.
Так VPN-туннель-то тоже в чем-то идет. Например, OpenVPN ходит либо
внутри UDP, либо внутри TCP. Если таймаут на (в терминах iptables)
RELATED,ESTABLISHED на файрволе провайдера меньше, чем keepalive, то
пакет, начинающий "сессию" внутри туннеля, может оказаться начинающим ее
и снаружи оного с кочки зрения оного файрвола. И привет. А на UDP
keepalive на файрволе может быть и маленьким, протокол-то sessionless.
Разумеется, гарантии у такой блокировки не будет. А вот проблему
создать она может.
В "официальных" VPN я не силен, каковы там особенности внешних
протоколов, не знаю.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Artem Chuprina
Sep 26, 2013, 2:40:02 PM9/26/13
to
Dmitrii Kashin -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 22:06:17 +0400:
>>> alexander barakin (aka sash-kan) -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 11:21:38 +0400:
>>> ab(s> Запросы на соединение с вашим компом просто блокируются провайдером. этож 3G! =)
>>>
>>> ab(s> суровые пошли провайдеры???
>>> ab(s> парсят шифрованный трафик ??? как семечки лузгают.
>>>
>>> Для того, чтобы заблокировать входящий запрос, совершенно не обязательно
>>> парсить шифрованный трафик.
>>
>> Чё, правда? But why? :) Речь-то идёт о трафике внутри vpn-туннеля,
>> установленного от хоста в какое-то внешнее облако.
DK> Ну, VPN-туннель у меня работает по UDP. Это не постоянно поддерживаемое
DK> соединение. Раз в 10 секунд (настраивается параметром keepalive в
DK> конфиге openvpn) происходит обмен сообщениями, откуда vpn-сервер и
DK> узнает обратный адрес. Кстати, а не в этом ли может быть дело? Вот у
DK> меня дома внешний адрес, судя по всему не так уж часто меняется, потому
DK> все и работает... А вот с 3g-модемом дело может быть обстоит куда хуже.
Ну, у 3g-модема адрес так часто тоже не меняется. Ну и 10 секунд,
конечно, не таймаут для провайдерского файрвола. 30 секунд или минута -
верю, да. Если keepalive 10 минут, а не 10 секунд, другое дело.
DK> Может, действительно для компа за 3g-модемом лучше использовать tcp?
Хрен знает. У OpenVPN в документации сказано "на хреновом канале TCP в
норме работает заметно хуже, чем UDP", но зато все же какая-никакая, а
сессия. Мы в свое время делали TCP, потому что было два канала,
основной и резервный, и ответ должен был уходить туда, откуда пришел
запрос. TCP это позволял, а UDP - нет (точнее, мне не удалось тогда
быстро придумать, как его заставить).
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87wqm37...@wizzle.ran.pp.ru
>>> alexander barakin (aka sash-kan) -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 11:21:38 +0400:
>>> ab(s> Запросы на соединение с вашим компом просто блокируются провайдером. этож 3G! =)
>>>
>>> ab(s> суровые пошли провайдеры???
>>> ab(s> парсят шифрованный трафик ??? как семечки лузгают.
>>>
>>> Для того, чтобы заблокировать входящий запрос, совершенно не обязательно
>>> парсить шифрованный трафик.
>>
>> Чё, правда? But why? :) Речь-то идёт о трафике внутри vpn-туннеля,
>> установленного от хоста в какое-то внешнее облако.
DK> соединение. Раз в 10 секунд (настраивается параметром keepalive в
DK> конфиге openvpn) происходит обмен сообщениями, откуда vpn-сервер и
DK> узнает обратный адрес. Кстати, а не в этом ли может быть дело? Вот у
DK> меня дома внешний адрес, судя по всему не так уж часто меняется, потому
DK> все и работает... А вот с 3g-модемом дело может быть обстоит куда хуже.
Ну, у 3g-модема адрес так часто тоже не меняется. Ну и 10 секунд,
конечно, не таймаут для провайдерского файрвола. 30 секунд или минута -
верю, да. Если keepalive 10 минут, а не 10 секунд, другое дело.
DK> Может, действительно для компа за 3g-модемом лучше использовать tcp?
Хрен знает. У OpenVPN в документации сказано "на хреновом канале TCP в
норме работает заметно хуже, чем UDP", но зато все же какая-никакая, а
сессия. Мы в свое время делали TCP, потому что было два канала,
основной и резервный, и ответ должен был уходить туда, откуда пришел
запрос. TCP это позволял, а UDP - нет (точнее, мне не удалось тогда
быстро придумать, как его заставить).
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Eugene Berdnikov
Sep 26, 2013, 4:30:02 PM9/26/13
to
On Thu, Sep 26, 2013 at 10:26:48PM +0400, Artem Chuprina wrote:
> О©╫О©╫О©╫ VPN-О©╫О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, OpenVPN О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫ UDP, О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ TCP. О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ (О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ iptables)
> RELATED,ESTABLISHED О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ keepalive, О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ "О©╫О©╫О©╫О©╫О©╫О©╫" О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫
> О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫ "О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫".
> О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫ UDP
> keepalive О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ sessionless.
О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ keepalive, О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫,
О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ udp -- О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫-О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫... О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫ tcp
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. :)
--
Eugene Berdnikov
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013092620...@sie.protva.ru
> О©╫О©╫О©╫ VPN-О©╫О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫-О©╫О©╫ О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, OpenVPN О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫ UDP, О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ TCP. О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ (О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ iptables)
> RELATED,ESTABLISHED О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ keepalive, О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ "О©╫О©╫О©╫О©╫О©╫О©╫" О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫
> О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫.
О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫ "О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫".
> О©╫ О©╫О©╫О©╫О©╫О©╫О©╫. О©╫ О©╫О©╫ UDP
> keepalive О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫-О©╫О©╫ sessionless.
О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ keepalive, О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫,
О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ udp -- О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫-О©╫О©╫
О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫... О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫ tcp
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫. :)
--
Eugene Berdnikov
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Eugene Berdnikov
Sep 26, 2013, 4:30:02 PM9/26/13
to
On Thu, Sep 26, 2013 at 10:32:06PM +0400, Artem Chuprina wrote:
> Dmitrii Kashin -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 22:06:17 +0400:
> DK> О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ 3g-О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ tcp?
> Dmitrii Kashin -> debian-...@lists.debian.org @ Thu, 26 Sep 2013 22:06:17 +0400:
>
> О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫. О©╫ OpenVPN О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ "О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ TCP О©╫
> О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ UDP",
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ meltdown effect.
> О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫-О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫. О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ TCP, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫,
> О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫. TCP О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫ UDP - О©╫О©╫О©╫ (О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫
> О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫).
О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫: -j DNAT --to [ip.of.vpn.serv], О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫ conntrack
О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ src_ip О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫ О©╫О©╫О©╫.
--
Eugene Berdnikov
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mikhail A Antonov
Sep 26, 2013, 7:40:01 PM9/26/13
to
26.09.2013 21:08, Artem Chuprina пишет:
> Для того, чтобы заблокировать входящий запрос, совершенно не обязательно
> парсить шифрованный трафик. Ну, за исключением варианта OpenVPN over
> TCP c настроенным keepalive.
>
> Да, я тоже в курсе, что в других вариантах тоже иногда можно настроить
> такой keepalive, чтобы файрволы провайдера не продалбывали соединение.
> Но обычно это будет довольно частый keepalive, типичное время
> протухания, допустим, UDP-"сессии" в подобном файрволе - секунд 30.
Вариант с keepalive и протухшей записью в NAT у провайдера я отмёл
потому что для провайдерского NAT нет разницы что внутри пакета - TCP
или ICMP. У ТС есть ответ на icmp внутри туннеля, а вот на tcp ответов нет.
> Для того, чтобы заблокировать входящий запрос, совершенно не обязательно
> парсить шифрованный трафик. Ну, за исключением варианта OpenVPN over
> TCP c настроенным keepalive.
>
> Да, я тоже в курсе, что в других вариантах тоже иногда можно настроить
> такой keepalive, чтобы файрволы провайдера не продалбывали соединение.
> Но обычно это будет довольно частый keepalive, типичное время
> протухания, допустим, UDP-"сессии" в подобном файрволе - секунд 30.
потому что для провайдерского NAT нет разницы что внутри пакета - TCP
или ICMP. У ТС есть ответ на icmp внутри туннеля, а вот на tcp ответов нет.
Вот ещё идея пришла в голову - с MTU всё хорошо? Как внутри туннеля так
и снаружи.
Dmitrii Kashin
Sep 27, 2013, 7:50:02 AM9/27/13
to
Mikhail A Antonov <ba...@solarnet.ru> writes:
> Вот ещё идея пришла в голову - с MTU всё хорошо? Как внутри туннеля так
> и снаружи.
MTU 1400. С ним тоже попробую поиграться, когда до той машинки доберусь.
> Вот ещё идея пришла в голову - с MTU всё хорошо? Как внутри туннеля так
> и снаружи.
Artem Chuprina
Sep 27, 2013, 3:10:01 PM9/27/13
to
Eugene Berdnikov -> debian-...@lists.debian.org @ Fri, 27 Sep 2013 00:25:38 +0400:
>> но зато все же какая-никакая, а
>> сессия. Мы в свое время делали TCP, потому что было два канала,
>> основной и резервный, и ответ должен был уходить туда, откуда пришел
>> запрос. TCP это позволял, а UDP - нет (точнее, мне не удалось тогда
>> быстро придумать, как его заставить).
EB> Элементарно, Ватсон: -j DNAT --to [ip.of.vpn.serv], после чего conntrack
EB> делает штамповку правильного src_ip в обратных пакетах за вас.
Вот именно это с UDP и не работало. Пакеты от сервера упорно шли с src
основного канала. Потому что sessionless. OpenVPN был на самом
роутере, с двумя каналами. Если б внутри сети, надо полагать, работало
бы, а так - нет.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87siwq6...@wizzle.ran.pp.ru
>> но зато все же какая-никакая, а
>> сессия. Мы в свое время делали TCP, потому что было два канала,
>> основной и резервный, и ответ должен был уходить туда, откуда пришел
>> запрос. TCP это позволял, а UDP - нет (точнее, мне не удалось тогда
>> быстро придумать, как его заставить).
EB> делает штамповку правильного src_ip в обратных пакетах за вас.
Вот именно это с UDP и не работало. Пакеты от сервера упорно шли с src
основного канала. Потому что sessionless. OpenVPN был на самом
роутере, с двумя каналами. Если б внутри сети, надо полагать, работало
бы, а так - нет.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Eugene Berdnikov
Sep 27, 2013, 4:50:02 PM9/27/13
to
On Fri, Sep 27, 2013 at 10:14:46PM +0400, Artem Chuprina wrote:
> Eugene Berdnikov -> debian-...@lists.debian.org @ Fri, 27 Sep 2013 00:25:38 +0400:
>
> >> но зато все же какая-никакая, а
> >> сессия. Мы в свое время делали TCP, потому что было два канала,
> >> основной и резервный, и ответ должен был уходить туда, откуда пришел
> >> запрос. TCP это позволял, а UDP - нет (точнее, мне не удалось тогда
> >> быстро придумать, как его заставить).
>
> EB> Элементарно, Ватсон: -j DNAT --to [ip.of.vpn.serv], после чего conntrack
> EB> делает штамповку правильного src_ip в обратных пакетах за вас.
>
> Вот именно это с UDP и не работало. Пакеты от сервера упорно шли с src
> основного канала. Потому что sessionless.
Проверил. Сервер на шлюзе, пакеты с правильным src_ip возвращаются как в
> Eugene Berdnikov -> debian-...@lists.debian.org @ Fri, 27 Sep 2013 00:25:38 +0400:
>
> >> но зато все же какая-никакая, а
> >> сессия. Мы в свое время делали TCP, потому что было два канала,
> >> основной и резервный, и ответ должен был уходить туда, откуда пришел
> >> запрос. TCP это позволял, а UDP - нет (точнее, мне не удалось тогда
> >> быстро придумать, как его заставить).
>
> EB> Элементарно, Ватсон: -j DNAT --to [ip.of.vpn.serv], после чего conntrack
> EB> делает штамповку правильного src_ip в обратных пакетах за вас.
>
> Вот именно это с UDP и не работало. Пакеты от сервера упорно шли с src
> основного канала. Потому что sessionless.
тот канал, на который показывает default route, так и в остальные каналы.
При чём тут вообще sessionless? Для контрака нужно понятие коннекции,
а оно есть и для tcp, и для udp, icmp, esp и даже для таких кривуль
как ftp или pptp.
Хотя я не исключаю, что правила iptables и ip rules написать так, что
будет ставиться неправильный src_ip или выбираться не тот канал, через
который поступил запрос. К сожалению, мне уже нужно напрягаться, чтобы
вспомнить, как искривить конфигурацию роутера... Старею, наверное. :)))
> OpenVPN был на самом
> роутере, с двумя каналами. Если б внутри сети, надо полагать, работало
> бы, а так - нет.
работает, тут и проверять нечего. Но раньше и на многоствольных шлюзах
контрак работал, и я не вижу причин, которые мешали бы ему работать.
--
Eugene Berdnikov
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitrii Kashin
Oct 2, 2013, 6:00:02 PM10/2/13
to
Направил запрос в МТС.
--------------------
Текст вопроса:
Приобрел сим-карту МТС Коннект-4 для использования в 3g-модеме. С её
помощью вышел в сеть и подключился к своему VPN.
Столкнулся с интересной проблемой. Внутри VPN-сети хоть до машины пинги
и доходят, но я не могу установить входящее TCP-соединение до нее, а для
меня это очень важно, потому что на этой машине у меня висит sshd
(удаленный терминал), без которого я не могу работать.
Такое ощущение, что блокируются все входящие запросы к моему компьютеру,
подключенному к VPN через 3g-сеть. Собственно, хотел как раз спросить,
не блокируете ли Вы входящие соединения? Нет ли у вас предположений, с
чем связано данное поведение?
--------------------
Ответ:
Дмитрий, сообщаем, что входящее соединение с нашей стороны не
блокируется. Обратите, пожалуйста, внимание, что для удаленного
подключения необходим реальный адрес, поэтому необходимо подключить
Real IP.
--------------------
Но. Дошли руки почитать про то, что из себя представляет этот самый Real
IP. И вот на какую интересную страницу[0] я наткнулся, которую очень хочу
показать всем присутствующим в рассылке.
"Услуга «Real IP» обеспечивает возможность передачи данных с применением
сетевых протоколов, для работы которых необходимо наличие у пользователя
реального IP-адреса в сети Интернет. Это необходимо, например, для
установления шифрованного VPN-соединения".
Мне это кажется несусветным бредом. Ведь в том и суть VPN-сети, что с
белым адресом должен быть только сервер, а все остальные машины,
подключенные к нему из-за NAT'ов, видят друг друга через него.
Правильно ли я понимаю, что таким образом МТС навязывает пользователям
дополнительные услуги?
PS: Собственно, игры с MTU результата не дали. Попробовал поднять VPN на
и TCP, и на UDP - все равно не получается установить соединение.
[0] http://www.mts.ru/mobil_inet_and_tv/internet_comp/archive/real_ip/
Mikhail A Antonov
Oct 2, 2013, 6:10:02 PM10/2/13
to
03.10.2013 01:53, Dmitrii Kashin пишет:
> PS: Собственно, игры с MTU результата не дали. Попробовал поднять VPN на
> и TCP, и на UDP - все равно не получается установить соединение.
tcpdump посмотрел? Запросы приходят? Ответы уходят?
> PS: Собственно, игры с MTU результата не дали. Попробовал поднять VPN на
> и TCP, и на UDP - все равно не получается установить соединение.
Dmitrii Kashin
Oct 2, 2013, 6:30:02 PM10/2/13
to
> 03.10.2013 01:53, Dmitrii Kashin пишет:
>> PS: Собственно, игры с MTU результата не дали. Попробовал поднять VPN на
>> и TCP, и на UDP - все равно не получается установить соединение.
> tcpdump посмотрел? Запросы приходят? Ответы уходят?
Не успел. У меня был всего час на все. Но в следующий раз (где-то
>> PS: Собственно, игры с MTU результата не дали. Попробовал поднять VPN на
>> и TCP, и на UDP - все равно не получается установить соединение.
> tcpdump посмотрел? Запросы приходят? Ответы уходят?
понедельник-вторник), обязательно займусь этим.
Eugene Berdnikov
Oct 3, 2013, 1:20:02 AM10/3/13
to
On Thu, Oct 03, 2013 at 01:53:15AM +0400, Dmitrii Kashin wrote:
>
> "Услуга ??Real IP?? обеспечивает возможность передачи данных с применением
Вы не умеете, и самое главное не хотите сесть и вникнуть в суть проблемы.
МТС тоже не может и не хочет няньчится с теми, кто отнимает время попусту,
вместо того, чтобы потратить его на образование. А таких целые стада...
Поэтому в описании услуги лишь пара ключевых слов, которые дают правильный
вектор движения тем, кто нужные знания уже имеет.
>
> "Услуга ??Real IP?? обеспечивает возможность передачи данных с применением
> сетевых протоколов, для работы которых необходимо наличие у пользователя
> реального IP-адреса в сети Интернет. Это необходимо, например, для
> установления шифрованного VPN-соединения".
>
> Мне это кажется несусветным бредом. Ведь в том и суть VPN-сети, что с
> белым адресом должен быть только сервер, а все остальные машины,
> подключенные к нему из-за NAT'ов, видят друг друга через него.
>
> Правильно ли я понимаю, что таким образом МТС навязывает пользователям
> дополнительные услуги?
Нет, неправильно.
> реального IP-адреса в сети Интернет. Это необходимо, например, для
> установления шифрованного VPN-соединения".
>
> Мне это кажется несусветным бредом. Ведь в том и суть VPN-сети, что с
> белым адресом должен быть только сервер, а все остальные машины,
> подключенные к нему из-за NAT'ов, видят друг друга через него.
>
> Правильно ли я понимаю, что таким образом МТС навязывает пользователям
> дополнительные услуги?
Вы не умеете, и самое главное не хотите сесть и вникнуть в суть проблемы.
МТС тоже не может и не хочет няньчится с теми, кто отнимает время попусту,
вместо того, чтобы потратить его на образование. А таких целые стада...
Поэтому в описании услуги лишь пара ключевых слов, которые дают правильный
вектор движения тем, кто нужные знания уже имеет.
--
Eugene Berdnikov
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013100305...@sie.protva.ru
Eugene Berdnikov
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitrii Kashin
Oct 3, 2013, 3:10:01 AM10/3/13
to
Eugene Berdnikov <b...@protva.ru> writes:
> Вы не умеете, и самое главное не хотите сесть и вникнуть в суть проблемы.
Надо же. И чем же, по-вашему, я тут занимаюсь?
> Вы не умеете, и самое главное не хотите сесть и вникнуть в суть проблемы.
Alexander Wiedergold WIEDERGOLD.NET
Oct 5, 2013, 5:00:02 PM10/5/13
to
--
..
Developer forum http://wiedergold.org/forum/index.php
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vladimir Skubriev
Oct 8, 2013, 5:50:02 AM10/8/13
to
реального (хотя бы динамического адреса Интернет).
Это говорит все волишь о том, что использовать dynamic dns у вас не
получиться. И соединяться со своим компьютером подключенным по модему
тоже не получиться. Т.к. модем будет использовать внутр. CIDR адрес.
Который ни кому из Интернет не ведом. Маршрутизация по просту не
работает до таких адресов.
Но это и не важно особо. Важно то, что просто у вас не до конца все
настроено.
--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор
Скубриев Владимир
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Россия, Ростовская область, г. Таганрог
тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vladimir Skubriev
Oct 8, 2013, 6:00:01 AM10/8/13
to
On 10/08/2013 01:46 PM, Vladimir Skubriev wrote:
> On 10/03/2013 11:00 AM, Dmitrii Kashin wrote:
>> Eugene Berdnikov <b...@protva.ru> writes:
>>
>>> Вы не умеете, и самое главное не хотите сесть и вникнуть в суть
>>> проблемы.
>> Надо же. И чем же, по-вашему, я тут занимаюсь?
>>
>
> Многие модемы 3g выходят в Интернет через NAT сервер, не имея при этом
> реального (хотя бы динамического адреса Интернет).
>
> Это говорит все волишь о том, что использовать dynamic dns у вас не
> получиться. И соединяться со своим компьютером подключенным по модему
> тоже не получиться. Т.к. модем будет использовать внутр. CIDR адрес.
> Который ни кому из Интернет не ведом. Маршрутизация по просту не
> работает до таких адресов.
>
> Но это и не важно особо. Важно то, что просто у вас не до конца все
> настроено.
>
>
>
Дело скорее в настройке openvpn. Там есть ньюанс, без которого "для
> On 10/03/2013 11:00 AM, Dmitrii Kashin wrote:
>> Eugene Berdnikov <b...@protva.ru> writes:
>>
>>> Вы не умеете, и самое главное не хотите сесть и вникнуть в суть
>>> проблемы.
>> Надо же. И чем же, по-вашему, я тут занимаюсь?
>>
>
> Многие модемы 3g выходят в Интернет через NAT сервер, не имея при этом
> реального (хотя бы динамического адреса Интернет).
>
> Это говорит все волишь о том, что использовать dynamic dns у вас не
> получиться. И соединяться со своим компьютером подключенным по модему
> тоже не получиться. Т.к. модем будет использовать внутр. CIDR адрес.
> Который ни кому из Интернет не ведом. Маршрутизация по просту не
> работает до таких адресов.
>
> Но это и не важно особо. Важно то, что просто у вас не до конца все
> настроено.
>
>
>
пущей безопасности" сеть клиента не будет видна до тех пор пока не
сконфигурируете правильно.
Щас вспоминаю, где я это записывал - пока не нашел.
/etc/openvpn/ccd/rgw:
iroute 192.168.1.0 255.255.255.0
Читайте в сторону iroute и ccd )
Это конфиг на сервере. т.е. у вас на облаке.
И плюс firewall выключите на время проверки или будьте уверены, что он
не мешает.
Мне именно это помогло увидеть сеть за клиентом сервера openvpn.
--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор
Скубриев Владимир
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Россия, Ростовская область, г. Таганрог
тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Vladimir Skubriev
Oct 8, 2013, 6:00:02 AM10/8/13
to
On 10/08/2013 01:55 PM, Vladimir Skubriev wrote:
>
> Мне именно это помогло увидеть сеть за клиентом сервера openvpn.
>
# For work to client subnet in server.conf
>
> Мне именно это помогло увидеть сеть за клиентом сервера openvpn.
>
client-config-dir /etc/openvpn/ccd
--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор
Скубриев Владимир
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Россия, Ростовская область, г. Таганрог
тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages