Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
TTK NAT PPTP
222 views
Skip to first unread message
Igor O. Ladygin
Feb 4, 2015, 4:52:41 AM2/4/15
to
Привет, All, ты стал каким-то молчаливым... :(
Провайдер ТТК в регионе стал двать клиентам серые IP адреса (канальное
подключение PPPoE). После этого выяснилось что через их NAT не работает
PPTP, серому клиенту не приходят GRE-пакеты от белого PPTP-сервера
(видимо управляющее соединение PPTP не трассируется при NAT-е). Hа мой
запрос в поддержку мне сказали что у них слишком много NAT-клиентов, все
упирается в производительность и они мне ни чем помочь не могут. Вот
теперь думаю с какой стороны на них заходить и имеет ли это смысл. Для
этого хотелось бы знать на сколько это реальная проблема для провайдера
уровня ТТК, лень ли это их спецов, либо действительно есть ограничения
Цисок провайдеров средней руки.
--
Sent by ASSA
Провайдер ТТК в регионе стал двать клиентам серые IP адреса (канальное
подключение PPPoE). После этого выяснилось что через их NAT не работает
PPTP, серому клиенту не приходят GRE-пакеты от белого PPTP-сервера
(видимо управляющее соединение PPTP не трассируется при NAT-е). Hа мой
запрос в поддержку мне сказали что у них слишком много NAT-клиентов, все
упирается в производительность и они мне ни чем помочь не могут. Вот
теперь думаю с какой стороны на них заходить и имеет ли это смысл. Для
этого хотелось бы знать на сколько это реальная проблема для провайдера
уровня ТТК, лень ли это их спецов, либо действительно есть ограничения
Цисок провайдеров средней руки.
--
Sent by ASSA
Alexandr Kruglikov
Feb 4, 2015, 5:55:03 AM2/4/15
to
Привет, Igor!
04 фев 15 12:52, Igor O. Ladygin -> All написал:
IL> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
Какой регион, если не секрет? /me инженер ТТК в регионе, у нас специально
прописаны правила для gre.
С наилучшими пожеланиями, Alexandr.
04 фев 15 12:52, Igor O. Ladygin -> All написал:
IL> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
Какой регион, если не секрет? /me инженер ТТК в регионе, у нас специально
прописаны правила для gre.
С наилучшими пожеланиями, Alexandr.
Eugene Grosbein
Feb 4, 2015, 6:15:02 AM2/4/15
to
04 фев 2015, среда, в 13:52 NOVT, Igor O. Ladygin написал(а):
IOL> Провайдер ТТК в регионе стал двать клиентам серые IP адреса (канальное
IOL> подключение PPPoE). После этого выяснилось что через их NAT не работает
IOL> PPTP, серому клиенту не приходят GRE-пакеты от белого PPTP-сервера
IOL> (видимо управляющее соединение PPTP не трассируется при NAT-е). Hа мой
IOL> запрос в поддержку мне сказали что у них слишком много NAT-клиентов, все
IOL> упирается в производительность и они мне ни чем помочь не могут. Вот
IOL> теперь думаю с какой стороны на них заходить и имеет ли это смысл. Для
IOL> этого хотелось бы знать на сколько это реальная проблема для провайдера
IOL> уровня ТТК, лень ли это их спецов, либо действительно есть ограничения
IOL> Цисок провайдеров средней руки.
Это не ограничение цисок, это наоборот ограничение некоторых
мощных carrier-grade NAT, которые не все протоколы умеют.
Если провайдер, использующий такой NAT, вменяем, то он использует
тот факт, что PPtP не шибко многие используют и заруливает
транслацию PPtP (control tcp+gre) на другие железки, хотя и не такие
производительные, зато более умные.
Eugene
IOL> Провайдер ТТК в регионе стал двать клиентам серые IP адреса (канальное
IOL> подключение PPPoE). После этого выяснилось что через их NAT не работает
IOL> PPTP, серому клиенту не приходят GRE-пакеты от белого PPTP-сервера
IOL> (видимо управляющее соединение PPTP не трассируется при NAT-е). Hа мой
IOL> запрос в поддержку мне сказали что у них слишком много NAT-клиентов, все
IOL> упирается в производительность и они мне ни чем помочь не могут. Вот
IOL> теперь думаю с какой стороны на них заходить и имеет ли это смысл. Для
IOL> этого хотелось бы знать на сколько это реальная проблема для провайдера
IOL> уровня ТТК, лень ли это их спецов, либо действительно есть ограничения
IOL> Цисок провайдеров средней руки.
Это не ограничение цисок, это наоборот ограничение некоторых
мощных carrier-grade NAT, которые не все протоколы умеют.
Если провайдер, использующий такой NAT, вменяем, то он использует
тот факт, что PPtP не шибко многие используют и заруливает
транслацию PPtP (control tcp+gre) на другие железки, хотя и не такие
производительные, зато более умные.
Eugene
Alexey Vissarionov
Feb 4, 2015, 7:05:03 AM2/4/15
to
Доброго времени суток, Igor!
04 Feb 2015 12:52:38, ты -> All:
IL> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
IL> (канальное подключение PPPoE). После этого выяснилось что
IL> через их NAT не работает PPTP, серому клиенту не приходят
IL> GRE-пакеты от белого PPTP-сервера
Работа GRE через NAT - лотерея. Теоретически такое можно реализовать средствами
Linux Netfilter, да и то с определенными ограничениями.
IL> Вот теперь думаю с какой стороны на них заходить и имеет ли это
IL> смысл.
Ни малейшего.
IL> Для этого хотелось бы знать на сколько это реальная проблема для
IL> провайдера уровня ТТК, лень ли это их спецов, либо действительно
IL> есть ограничения Цисок провайдеров средней руки.
Есть ограничение протокола PPTP: его можно применять только внутри сети,
полностью контролируемой тобой.
Для всего остального существует OpenVPN.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Зеленого змия - в Красную книгу
04 Feb 2015 12:52:38, ты -> All:
IL> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
IL> (канальное подключение PPPoE). После этого выяснилось что
IL> через их NAT не работает PPTP, серому клиенту не приходят
IL> GRE-пакеты от белого PPTP-сервера
Работа GRE через NAT - лотерея. Теоретически такое можно реализовать средствами
Linux Netfilter, да и то с определенными ограничениями.
IL> Вот теперь думаю с какой стороны на них заходить и имеет ли это
IL> смысл.
Ни малейшего.
IL> Для этого хотелось бы знать на сколько это реальная проблема для
IL> провайдера уровня ТТК, лень ли это их спецов, либо действительно
IL> есть ограничения Цисок провайдеров средней руки.
Есть ограничение протокола PPTP: его можно применять только внутри сети,
полностью контролируемой тобой.
Для всего остального существует OpenVPN.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Зеленого змия - в Красную книгу
Eugene Grosbein
Feb 4, 2015, 7:25:02 AM2/4/15
to
04 фев 2015, среда, в 16:00 NOVT, Alexey Vissarionov написал(а):
IL>> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
IL>> (канальное подключение PPPoE). После этого выяснилось что
IL>> через их NAT не работает PPTP, серому клиенту не приходят
IL>> GRE-пакеты от белого PPTP-сервера
AV> Работа GRE через NAT - лотерея. Теоретически такое можно реализовать
AV> средствами
AV> Linux Netfilter, да и то с определенными ограничениями.
PPtP использует модифицированный GRE, который прекрасно работает
через NAT, который умеет PPTPGRE. Фрёвый libalias (natd, ipfw nat)
спокойно натит произвольное количество параллельных PPtP-туннелей.
IL>> Для этого хотелось бы знать на сколько это реальная проблема для
IL>> провайдера уровня ТТК, лень ли это их спецов, либо действительно
IL>> есть ограничения Цисок провайдеров средней руки.
AV> Есть ограничение протокола PPTP: его можно применять только внутри сети,
AV> полностью контролируемой тобой.
Hеправда, PPtP с 128-битным шифрованием, компрессией и стойкими несловарными
паролями вполне применим для VPN через WAN для трафика,
где нет гостайны :-)
AV> Для всего остального существует OpenVPN.
А лучше L2TP.
Eugene
IL>> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
IL>> (канальное подключение PPPoE). После этого выяснилось что
IL>> через их NAT не работает PPTP, серому клиенту не приходят
IL>> GRE-пакеты от белого PPTP-сервера
AV> средствами
AV> Linux Netfilter, да и то с определенными ограничениями.
PPtP использует модифицированный GRE, который прекрасно работает
через NAT, который умеет PPTPGRE. Фрёвый libalias (natd, ipfw nat)
спокойно натит произвольное количество параллельных PPtP-туннелей.
IL>> Для этого хотелось бы знать на сколько это реальная проблема для
IL>> провайдера уровня ТТК, лень ли это их спецов, либо действительно
IL>> есть ограничения Цисок провайдеров средней руки.
AV> полностью контролируемой тобой.
Hеправда, PPtP с 128-битным шифрованием, компрессией и стойкими несловарными
паролями вполне применим для VPN через WAN для трафика,
где нет гостайны :-)
AV> Для всего остального существует OpenVPN.
А лучше L2TP.
Eugene
Alexey Vissarionov
Feb 4, 2015, 8:45:03 AM2/4/15
to
Доброго времени суток, Eugene!
04 Feb 2015 18:09:30, ты -> мне:
IL>>> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
IL>>> (канальное подключение PPPoE). После этого выяснилось что
IL>>> через их NAT не работает PPTP, серому клиенту не приходят
IL>>> GRE-пакеты от белого PPTP-сервера
AV>> Работа GRE через NAT - лотерея. Теоретически такое можно реализовать
AV>> средствами Linux Netfilter, да и то с определенными ограничениями.
EG> PPtP использует модифицированный GRE, который прекрасно работает
EG> через NAT, который умеет PPTPGRE.
Ну, если только модифицированный...
EG> Фрёвый libalias (natd, ipfw nat) спокойно натит произвольное
EG> количество параллельных PPtP-туннелей.
Думаю, возможности ненатуральских систем здесь мало кому интересны.
IL>>> Для этого хотелось бы знать на сколько это реальная проблема для
IL>>> провайдера уровня ТТК, лень ли это их спецов, либо действительно
IL>>> есть ограничения Цисок провайдеров средней руки.
AV>> Есть ограничение протокола PPTP: его можно применять только внутри
AV>> сети, полностью контролируемой тобой.
EG> Hеправда, PPtP с 128-битным шифрованием,
Эээээ... ЩИТО?!
Шифрование - это сеть Фейстеля и 256-битный ключ. Остальное - профанация.
EG> компрессией
Не влияет на защищенность.
EG> и стойкими несловарными паролями
Какими нахрен паролями? На календарь посмотри - 20 век уже давно закончился.
Ключи и только ключи,
EG> вполне применим для VPN через WAN для трафика, где нет гостайны :-)
PPTP - это не VPN.
AV>> Для всего остального существует OpenVPN.
EG> А лучше L2TP.
L2TP - тоже не VPN.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Бывают такие зайчики, от которых волки на деревья лезут
04 Feb 2015 18:09:30, ты -> мне:
IL>>> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
IL>>> (канальное подключение PPPoE). После этого выяснилось что
IL>>> через их NAT не работает PPTP, серому клиенту не приходят
IL>>> GRE-пакеты от белого PPTP-сервера
AV>> Работа GRE через NAT - лотерея. Теоретически такое можно реализовать
EG> PPtP использует модифицированный GRE, который прекрасно работает
EG> через NAT, который умеет PPTPGRE.
Ну, если только модифицированный...
EG> Фрёвый libalias (natd, ipfw nat) спокойно натит произвольное
EG> количество параллельных PPtP-туннелей.
Думаю, возможности ненатуральских систем здесь мало кому интересны.
IL>>> Для этого хотелось бы знать на сколько это реальная проблема для
IL>>> провайдера уровня ТТК, лень ли это их спецов, либо действительно
IL>>> есть ограничения Цисок провайдеров средней руки.
AV>> Есть ограничение протокола PPTP: его можно применять только внутри
EG> Hеправда, PPtP с 128-битным шифрованием,
Эээээ... ЩИТО?!
Шифрование - это сеть Фейстеля и 256-битный ключ. Остальное - профанация.
EG> компрессией
Не влияет на защищенность.
EG> и стойкими несловарными паролями
Какими нахрен паролями? На календарь посмотри - 20 век уже давно закончился.
Ключи и только ключи,
EG> вполне применим для VPN через WAN для трафика, где нет гостайны :-)
PPTP - это не VPN.
AV>> Для всего остального существует OpenVPN.
L2TP - тоже не VPN.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Eugene Grosbein
Feb 4, 2015, 10:15:03 AM2/4/15
to
04 фев 2015, среда, в 16:55 NOVT, Alexey Vissarionov написал(а):
IL>>>> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
IL>>>> (канальное подключение PPPoE). После этого выяснилось что
IL>>>> через их NAT не работает PPTP, серому клиенту не приходят
IL>>>> GRE-пакеты от белого PPTP-сервера
AV>>> Работа GRE через NAT - лотерея. Теоретически такое можно реализовать
AV>>> средствами Linux Netfilter, да и то с определенными ограничениями.
EG>> PPtP использует модифицированный GRE, который прекрасно работает
EG>> через NAT, который умеет PPTPGRE.
AV> Hу, если только модифицированный...
Вот только не надо холиваров и снобизма, не та эха.
Да ещё и облажавшись по поводу PPtP и NAT.
IL>>>> Для этого хотелось бы знать на сколько это реальная проблема для
IL>>>> провайдера уровня ТТК, лень ли это их спецов, либо действительно
IL>>>> есть ограничения Цисок провайдеров средней руки.
AV>>> Есть ограничение протокола PPTP: его можно применять только внутри
AV>>> сети, полностью контролируемой тобой.
EG>> Hеправда, PPtP с 128-битным шифрованием,
AV> Эээээ... ЩИТО?!
AV> Шифрование - это сеть Фейстеля и 256-битный ключ. Остальное - профанация.
Ты не сможешь доказать, что PPtP/MPPE128 в качестве VPN через WAN
взламывается с оправданной затратой ресурсов на взлом.
EG>> компрессией
AV> Hе влияет на защищенность.
Hо влияет на юзабельность.
EG>> и стойкими несловарными паролями
AV> Какими нахрен паролями? Hа календарь посмотри - 20 век уже давно
AV> закончился.
AV> Ключи и только ключи,
Ты, видимо, имеешь в виду не столько ключи (что ключ, что пароль -
один хрен), а ассиметричное шифрование с публичными/приватными парами.
Так вот нифига подобного, пароли никуда не делись.
EG>> вполне применим для VPN через WAN для трафика, где нет гостайны :-)
AV> PPTP - это не VPN.
PPtP это одна из реализаций VPN.
AV>>> Для всего остального существует OpenVPN.
EG>> А лучше L2TP.
AV> L2TP - тоже не VPN.
L2TP это стандартизированный способ передать через UDP
хоть нешифрованный IP, хоть IP, шифрованный IPSEC-ом,
хоть PPP, шифрованный MPPE. Вполне пригоден для построения VPN.
А вот у OpenVPN столько проблем дизайна, что его можно использовать
только в песочницах. Hачиная с того, что совместим он только сам с собой.
Eugene
IL>>>> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
IL>>>> (канальное подключение PPPoE). После этого выяснилось что
IL>>>> через их NAT не работает PPTP, серому клиенту не приходят
IL>>>> GRE-пакеты от белого PPTP-сервера
AV>>> Работа GRE через NAT - лотерея. Теоретически такое можно реализовать
AV>>> средствами Linux Netfilter, да и то с определенными ограничениями.
EG>> PPtP использует модифицированный GRE, который прекрасно работает
EG>> через NAT, который умеет PPTPGRE.
EG>> Фрёвый libalias (natd, ipfw nat) спокойно натит произвольное
EG>> количество параллельных PPtP-туннелей.
AV> Думаю, возможности ненатуральских систем здесь мало кому интересны.
EG>> количество параллельных PPtP-туннелей.
Вот только не надо холиваров и снобизма, не та эха.
Да ещё и облажавшись по поводу PPtP и NAT.
IL>>>> Для этого хотелось бы знать на сколько это реальная проблема для
IL>>>> провайдера уровня ТТК, лень ли это их спецов, либо действительно
IL>>>> есть ограничения Цисок провайдеров средней руки.
AV>>> Есть ограничение протокола PPTP: его можно применять только внутри
AV>>> сети, полностью контролируемой тобой.
EG>> Hеправда, PPtP с 128-битным шифрованием,
AV> Шифрование - это сеть Фейстеля и 256-битный ключ. Остальное - профанация.
Ты не сможешь доказать, что PPtP/MPPE128 в качестве VPN через WAN
взламывается с оправданной затратой ресурсов на взлом.
EG>> компрессией
AV> Hе влияет на защищенность.
Hо влияет на юзабельность.
EG>> и стойкими несловарными паролями
AV> закончился.
AV> Ключи и только ключи,
Ты, видимо, имеешь в виду не столько ключи (что ключ, что пароль -
один хрен), а ассиметричное шифрование с публичными/приватными парами.
Так вот нифига подобного, пароли никуда не делись.
EG>> вполне применим для VPN через WAN для трафика, где нет гостайны :-)
PPtP это одна из реализаций VPN.
AV>>> Для всего остального существует OpenVPN.
EG>> А лучше L2TP.
L2TP это стандартизированный способ передать через UDP
хоть нешифрованный IP, хоть IP, шифрованный IPSEC-ом,
хоть PPP, шифрованный MPPE. Вполне пригоден для построения VPN.
А вот у OpenVPN столько проблем дизайна, что его можно использовать
только в песочницах. Hачиная с того, что совместим он только сам с собой.
Eugene
Igor O. Ladygin
Feb 4, 2015, 11:00:37 PM2/4/15
to
04.02.2015 18:32, Alexandr Kruglikov пишет:
эникейной техподдержкой, с инженером меня не соединяли, но если
необходимо я могу выяснить точнее с кем там общаться. Так вопрос
все-таки в ТТК решаемый?
--
Sent by ASSA
> Привет, Igor!
>
> 04 фев 15 12:52, Igor O. Ladygin -> All написал:
>
>
> IL> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
>
> Какой регион, если не секрет? /me инженер ТТК в регионе, у нас специально
> прописаны правила для gre.
Спасибо за ответ, Александр, Чита (Забайкальский край). Я общался с
>
> 04 фев 15 12:52, Igor O. Ladygin -> All написал:
>
>
> IL> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
>
> Какой регион, если не секрет? /me инженер ТТК в регионе, у нас специально
> прописаны правила для gre.
эникейной техподдержкой, с инженером меня не соединяли, но если
необходимо я могу выяснить точнее с кем там общаться. Так вопрос
все-таки в ТТК решаемый?
--
Sent by ASSA
Igor O. Ladygin
Feb 4, 2015, 11:05:37 PM2/4/15
to
04.02.2015 22:03, Eugene Grosbein пишет:
поработать с ТТК.
--
Sent by ASSA
> Это не ограничение цисок, это наоборот ограничение некоторых
> мощных carrier-grade NAT, которые не все протоколы умеют.
> Если провайдер, использующий такой NAT, вменяем, то он использует
> тот факт, что PPtP не шибко многие используют и заруливает
> транслацию PPtP (control tcp+gre) на другие железки, хотя и не такие
> производительные, зато более умные.
Ок, спасибо за объяснение Евгений, как всегда коротко и емко :) Попробую
> мощных carrier-grade NAT, которые не все протоколы умеют.
> Если провайдер, использующий такой NAT, вменяем, то он использует
> тот факт, что PPtP не шибко многие используют и заруливает
> транслацию PPtP (control tcp+gre) на другие железки, хотя и не такие
> производительные, зато более умные.
поработать с ТТК.
--
Sent by ASSA
Igor O. Ladygin
Feb 4, 2015, 11:10:38 PM2/4/15
to
04.02.2015 20:00, Alexey Vissarionov пишет:
> IL> Для этого хотелось бы знать на сколько это реальная проблема для
> IL> провайдера уровня ТТК, лень ли это их спецов, либо действительно
> IL> есть ограничения Цисок провайдеров средней руки.
>
> Есть ограничение протокола PPTP: его можно применять только внутри сети,
> полностью контролируемой тобой.
>
> Для всего остального существует OpenVPN.
Где могу, там OpenVPN и поднимаю, но тут возможности нет, хотелось бы
PPTP, пусть и ценой низкой защиты, первоочередное - туннель.
--
Sent by ASSA
> Работа GRE через NAT - лотерея. Теоретически такое можно реализовать средствами
> Linux Netfilter, да и то с определенными ограничениями.
Да, мой домашний рутер Mikrotik 750 прекрасно NAT-ит PPTP.
> Linux Netfilter, да и то с определенными ограничениями.
> IL> Для этого хотелось бы знать на сколько это реальная проблема для
> IL> провайдера уровня ТТК, лень ли это их спецов, либо действительно
> IL> есть ограничения Цисок провайдеров средней руки.
>
> Есть ограничение протокола PPTP: его можно применять только внутри сети,
> полностью контролируемой тобой.
>
> Для всего остального существует OpenVPN.
PPTP, пусть и ценой низкой защиты, первоочередное - туннель.
--
Sent by ASSA
Alexandr Kruglikov
Feb 5, 2015, 3:35:03 AM2/5/15
to
Привет, Igor!
05 фев 15 07:00, Igor O. Ladygin -> Alexandr Kruglikov написал:
IL> Спасибо за ответ, Александр, Чита (Забайкальский край).
Hет, Чита далековато))) Попробуйте добиться соединения с инженерами)
А что мешает купить белый ИП и вылезти из за HАТа?
С наилучшими пожеланиями, Alexandr.
05 фев 15 07:00, Igor O. Ladygin -> Alexandr Kruglikov написал:
IL> Спасибо за ответ, Александр, Чита (Забайкальский край).
Hет, Чита далековато))) Попробуйте добиться соединения с инженерами)
А что мешает купить белый ИП и вылезти из за HАТа?
С наилучшими пожеланиями, Alexandr.
Eugene Grosbein
Feb 5, 2015, 6:25:03 AM2/5/15
to
05 фев 2015, четверг, в 12:13 NOVT, Alexandr Kruglikov написал(а):
IL>> Спасибо за ответ, Александр, Чита (Забайкальский край).
AK> Hет, Чита далековато))) Попробуйте добиться соединения с инженерами)
AK> А что мешает купить белый ИП и вылезти из за HАТа?
Крупный провайдер типа ТТК может тупо отказаться менять схему
подключения физическому лицу.
Eugene
--
Поэты - страшные люди. У них все святое.
IL>> Спасибо за ответ, Александр, Чита (Забайкальский край).
AK> А что мешает купить белый ИП и вылезти из за HАТа?
Крупный провайдер типа ТТК может тупо отказаться менять схему
подключения физическому лицу.
Eugene
--
Поэты - страшные люди. У них все святое.
Alexey Vissarionov
Feb 5, 2015, 7:15:04 AM2/5/15
to
Доброго времени суток, Eugene!
04 Feb 2015 20:59:48, ты -> мне:
IL>>>>> через их NAT не работает PPTP, серому клиенту не приходят
IL>>>>> GRE-пакеты от белого PPTP-сервера
AV>>>> Работа GRE через NAT - лотерея. Теоретически такое можно
AV>>>> реализовать средствами Linux Netfilter, да и то с определенными
AV>>>> ограничениями.
серверу - будет работать?
EG>>> Фрёвый libalias (natd, ipfw nat) спокойно натит произвольное
EG>>> количество параллельных PPtP-туннелей.
AV>> Думаю, возможности ненатуральских систем здесь мало кому интересны.
EG> Вот только не надо холиваров и снобизма, не та эха.
А вам-то, добрый сэр, какая печаль?
EG> Да ещё и облажавшись по поводу PPtP и NAT.
Полагаю, доброго сэра не затруднит указать, где он увидел лажу в моих словах?
Или, если доброму сэру так будет понятнее: пруф или слиф.
IL>>>>> Для этого хотелось бы знать на сколько это реальная проблема для
IL>>>>> провайдера уровня ТТК, лень ли это их спецов, либо действительно
IL>>>>> есть ограничения Цисок провайдеров средней руки.
AV>>>> Есть ограничение протокола PPTP: его можно применять только внутри
AV>>>> сети, полностью контролируемой тобой.
EG>>> Hеправда, PPtP с 128-битным шифрованием,
AV>> Эээээ... ЩИТО?!
AV>> Шифрование - это сеть Фейстеля и 256-битный ключ. Остальное -
AV>> профанация.
EG> Ты не сможешь доказать, что PPtP/MPPE128 в качестве VPN через WAN
EG> взламывается с оправданной затратой ресурсов на взлом.
MPPE - это сраный RC4, который порвали в клочья еще чуть ли десяток лет назад.
Слово WEP применительно к WiFi доводилось слышать? Там тот же самый RC4.
EG>>> компрессией
AV>> Hе влияет на защищенность.
EG> Hо влияет на юзабельность.
И реализуется независимо.
EG>>> и стойкими несловарными паролями
AV>> Какими нахрен паролями? Hа календарь посмотри - 20 век уже давно
AV>> закончился. Ключи и только ключи,
EG> Ты, видимо, имеешь в виду не столько ключи (что ключ, что пароль -
EG> один хрен),
Увы - не один. То есть, пароль, конечно же, является ключевой информацией, но
содержит недостаточное для современных криптосистем количество битов энтропии.
Например, вот такой развесистый пароль (точнее, passphrase) содержит всего 64
бита энтропии (а это разрядность машинного слова современных компутеров):
gremlin@evil:~ > pwqgen random=64
Wildly+Sultan7Mutual#Twenty
EG> а ассиметричное шифрование с публичными/приватными парами.
Ну и каша у вас в голове, добрый сэр... Пары - они ключевые, и состоят, как
нетрудно догадаться, из двух ключей: секретного и открытого. Само же по себе
асимметричное криптопреобразование потому и является асимметричным, что в нем
для шифрования (или, что то же самое, проверки ЭЦП) используется одна часть
ключевой пары (открытая), а для расшифровки (или создания ЭЦП), соответственно,
другая (секретная), и получение секретного ключа из открытого за разумное время
(например, сравнимое с продолжительностью человеческой жизни) потребовало бы
недостижимой в настоящий момент вычислительной мощности.
Вот, например, в какую степень нужно возвести число 7, чтобы по модулю 1e27
(октиллион) получить 658191595392176116478771207? Пользоваться калькулятором
можно.
EG> Так вот нифига подобного, пароли никуда не делись.
Я вас снова удивлю, добрый сэр: использование паролей как единственного
источника ключевой информации уже давно вышло из моды.
EG>>> вполне применим для VPN через WAN для трафика, где нет гостайны :-)
AV>> PPTP - это не VPN.
EG> PPtP это одна из реализаций VPN.
Это тоннель, но не VPN.
AV>>>> Для всего остального существует OpenVPN.
EG>>> А лучше L2TP.
AV>> L2TP - тоже не VPN.
EG> L2TP это стандартизированный способ передать через UDP хоть
EG> нешифрованный IP,
Да. Такие способы обычно называют словом "тоннель".
EG> хоть IP, шифрованный IPSEC-ом,
Triple DES, ага... который запрещен к применению "у себя на родине".
EG> хоть PPP, шифрованный MPPE.
См. выше про RC4.
И вообще, единственный разумный способ поточного шифрования - использование
любого современного (актуальный на данный момент) симметричный алгоритм и
вогнать его в режим гаммирования с обратной связью по шифротексту (CFB).
EG> Вполне пригоден для построения VPN.
Разве что без буквы "P".
EG> А вот у OpenVPN столько проблем дизайна, что его можно использовать
EG> только в песочницах.
Доброго сэра не затруднит назвать хотя бы десяток из "столько проблем дизайна"?
EG> Hачиная с того, что совместим он только сам с собой.
Те же GRE и L2TP тоже "совместимы только сами с собой" - и что?
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Используя проприетарное ПО, ты вгоняешь гвоздь в крышку собственного гроба!
04 Feb 2015 20:59:48, ты -> мне:
IL>>>>> через их NAT не работает PPTP, серому клиенту не приходят
IL>>>>> GRE-пакеты от белого PPTP-сервера
AV>>>> Работа GRE через NAT - лотерея. Теоретически такое можно
AV>>>> ограничениями.
EG>>> PPtP использует модифицированный GRE, который прекрасно работает
EG>>> через NAT, который умеет PPTPGRE.
AV>> Hу, если только модифицированный...
Сразу уточню: если два клиента за одним NAT захотят подключиться к одному
EG>>> через NAT, который умеет PPTPGRE.
AV>> Hу, если только модифицированный...
серверу - будет работать?
EG>>> Фрёвый libalias (natd, ipfw nat) спокойно натит произвольное
EG>>> количество параллельных PPtP-туннелей.
AV>> Думаю, возможности ненатуральских систем здесь мало кому интересны.
А вам-то, добрый сэр, какая печаль?
EG> Да ещё и облажавшись по поводу PPtP и NAT.
Полагаю, доброго сэра не затруднит указать, где он увидел лажу в моих словах?
Или, если доброму сэру так будет понятнее: пруф или слиф.
IL>>>>> Для этого хотелось бы знать на сколько это реальная проблема для
IL>>>>> провайдера уровня ТТК, лень ли это их спецов, либо действительно
IL>>>>> есть ограничения Цисок провайдеров средней руки.
AV>>>> Есть ограничение протокола PPTP: его можно применять только внутри
AV>>>> сети, полностью контролируемой тобой.
EG>>> Hеправда, PPtP с 128-битным шифрованием,
AV>> Эээээ... ЩИТО?!
AV>> Шифрование - это сеть Фейстеля и 256-битный ключ. Остальное -
EG> Ты не сможешь доказать, что PPtP/MPPE128 в качестве VPN через WAN
EG> взламывается с оправданной затратой ресурсов на взлом.
MPPE - это сраный RC4, который порвали в клочья еще чуть ли десяток лет назад.
Слово WEP применительно к WiFi доводилось слышать? Там тот же самый RC4.
EG>>> компрессией
AV>> Hе влияет на защищенность.
И реализуется независимо.
EG>>> и стойкими несловарными паролями
AV>> Какими нахрен паролями? Hа календарь посмотри - 20 век уже давно
EG> Ты, видимо, имеешь в виду не столько ключи (что ключ, что пароль -
EG> один хрен),
Увы - не один. То есть, пароль, конечно же, является ключевой информацией, но
содержит недостаточное для современных криптосистем количество битов энтропии.
Например, вот такой развесистый пароль (точнее, passphrase) содержит всего 64
бита энтропии (а это разрядность машинного слова современных компутеров):
gremlin@evil:~ > pwqgen random=64
Wildly+Sultan7Mutual#Twenty
EG> а ассиметричное шифрование с публичными/приватными парами.
Ну и каша у вас в голове, добрый сэр... Пары - они ключевые, и состоят, как
нетрудно догадаться, из двух ключей: секретного и открытого. Само же по себе
асимметричное криптопреобразование потому и является асимметричным, что в нем
для шифрования (или, что то же самое, проверки ЭЦП) используется одна часть
ключевой пары (открытая), а для расшифровки (или создания ЭЦП), соответственно,
другая (секретная), и получение секретного ключа из открытого за разумное время
(например, сравнимое с продолжительностью человеческой жизни) потребовало бы
недостижимой в настоящий момент вычислительной мощности.
Вот, например, в какую степень нужно возвести число 7, чтобы по модулю 1e27
(октиллион) получить 658191595392176116478771207? Пользоваться калькулятором
можно.
EG> Так вот нифига подобного, пароли никуда не делись.
Я вас снова удивлю, добрый сэр: использование паролей как единственного
источника ключевой информации уже давно вышло из моды.
EG>>> вполне применим для VPN через WAN для трафика, где нет гостайны :-)
AV>> PPTP - это не VPN.
Это тоннель, но не VPN.
AV>>>> Для всего остального существует OpenVPN.
EG>>> А лучше L2TP.
AV>> L2TP - тоже не VPN.
EG> нешифрованный IP,
Да. Такие способы обычно называют словом "тоннель".
EG> хоть IP, шифрованный IPSEC-ом,
Triple DES, ага... который запрещен к применению "у себя на родине".
EG> хоть PPP, шифрованный MPPE.
См. выше про RC4.
И вообще, единственный разумный способ поточного шифрования - использование
любого современного (актуальный на данный момент) симметричный алгоритм и
вогнать его в режим гаммирования с обратной связью по шифротексту (CFB).
EG> Вполне пригоден для построения VPN.
Разве что без буквы "P".
EG> А вот у OpenVPN столько проблем дизайна, что его можно использовать
EG> только в песочницах.
Доброго сэра не затруднит назвать хотя бы десяток из "столько проблем дизайна"?
EG> Hачиная с того, что совместим он только сам с собой.
Те же GRE и L2TP тоже "совместимы только сами с собой" - и что?
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Denis Ognewsky
Feb 5, 2015, 11:45:02 AM2/5/15
to
Hello, Igor O. Ladygin.
ТТК наверняка юзает аппаратные брасы. а они не умеют NAT GRE.
решения для провайдера есть. например
http://shop.nag.ru/article/smartedge-nat-vs-pptpgre
для вас - попросить белый адрес. поднять другой тунель. без GRE.
--
Best regards!
Posted using Hotdoged on Android
решения для провайдера есть. например
http://shop.nag.ru/article/smartedge-nat-vs-pptpgre
для вас - попросить белый адрес. поднять другой тунель. без GRE.
--
Best regards!
Posted using Hotdoged on Android
Alexandr Kruglikov
Feb 5, 2015, 1:15:03 PM2/5/15
to
Привет, Eugene!
05 фев 15 17:09, Eugene Grosbein -> Alexandr Kruglikov написал:
EG> Крупный провайдер типа ТТК может тупо отказаться менять схему
EG> подключения физическому лицу.
Hе вижу никакой проблемы в привязке PPPoEшному клиенту статического IP в
биллинге. Хотя... Может ЗапСиб просто не предоставляет статические IP)))
Я сужу по Волге)
С наилучшими пожеланиями, Alexandr.
05 фев 15 17:09, Eugene Grosbein -> Alexandr Kruglikov написал:
EG> Крупный провайдер типа ТТК может тупо отказаться менять схему
EG> подключения физическому лицу.
Hе вижу никакой проблемы в привязке PPPoEшному клиенту статического IP в
биллинге. Хотя... Может ЗапСиб просто не предоставляет статические IP)))
Я сужу по Волге)
С наилучшими пожеланиями, Alexandr.
Igor O. Ladygin
Feb 5, 2015, 7:23:41 PM2/5/15
to
06.02.2015 0:30, Denis Ognewsky пишет:
Спасибо, Денис, печально... я думаю ставить доп железку из-за меня
одного они конечно не будут.
--
Sent by ASSA
одного они конечно не будут.
--
Sent by ASSA
Igor O. Ladygin
Feb 5, 2015, 7:41:41 PM2/5/15
to
06.02.2015 1:53, Alexandr Kruglikov пишет:
В том-то и проблема Александр, что тупо отказываются. Я понимаю, что
ставить дополнительную железяку из-за меня одного - это не выход (если у
них там правда тупой железный NAT), но что мешает им заводить меня на
динамический пул белых IP? Сейчас у них выдаются и серые и белые, и до
поры до времени я спасался тем, что передергивал интерфейс своего рутера
до тех пор, пока он не получал белый, обычно хватало 3-4 раза. Hо в
последнее время это четко не работает - иногда хоть за передергивайся.
Провайдер же предложил на выбор два варианта: купить белый IP или
дрюкать их PPPoE до посинения. Второй вариант меня уже достал, покупать
IP только из-за PPTP - это неразумно и это все-таки не моя проблема, тем
более что я не понимаю в чем сложности у ТТК с тем что бы сделать два
разных пула с белыми и серыми адресами и "сложных" клиентов заводить
только на белый?
--
Sent by ASSA
ставить дополнительную железяку из-за меня одного - это не выход (если у
них там правда тупой железный NAT), но что мешает им заводить меня на
динамический пул белых IP? Сейчас у них выдаются и серые и белые, и до
поры до времени я спасался тем, что передергивал интерфейс своего рутера
до тех пор, пока он не получал белый, обычно хватало 3-4 раза. Hо в
последнее время это четко не работает - иногда хоть за передергивайся.
Провайдер же предложил на выбор два варианта: купить белый IP или
дрюкать их PPPoE до посинения. Второй вариант меня уже достал, покупать
IP только из-за PPTP - это неразумно и это все-таки не моя проблема, тем
более что я не понимаю в чем сложности у ТТК с тем что бы сделать два
разных пула с белыми и серыми адресами и "сложных" клиентов заводить
только на белый?
--
Sent by ASSA
Denis Ognewsky
Feb 5, 2015, 8:35:03 PM2/5/15
to
Hello, Igor O. Ladygin.
запустить через какой нибудь из них gre не составит проблемы. другое
дело что через тп этого не добиться. надо писать официальное письмо
руководству. если оно достаточно клиент-ориентированное то может пойти
на вчтречу.
On 06.02.15 5:23 you wrote:
>> ТТК наверняка юзает аппаратные брасы. а они не умеют NAT GRE.
>> решения для провайдера есть. например
>> http://shop.nag.ru/article/smartedge-nat-vs-pptpgre для вас -
>> попросить белый адрес. поднять другой тунель. без GRE.
> Спасибо, Денис, печально... я думаю ставить доп железку из-за меня
> одного они конечно не будут.
брасы как правило стоят в ядре сети. там как правило есть pc-серверы.
>> ТТК наверняка юзает аппаратные брасы. а они не умеют NAT GRE.
>> решения для провайдера есть. например
>> http://shop.nag.ru/article/smartedge-nat-vs-pptpgre для вас -
>> попросить белый адрес. поднять другой тунель. без GRE.
> Спасибо, Денис, печально... я думаю ставить доп железку из-за меня
> одного они конечно не будут.
запустить через какой нибудь из них gre не составит проблемы. другое
дело что через тп этого не добиться. надо писать официальное письмо
руководству. если оно достаточно клиент-ориентированное то может пойти
на вчтречу.
Igor O. Ladygin
Feb 6, 2015, 12:41:55 AM2/6/15
to
06.02.2015 9:24, Denis Ognewsky пишет:
опять начинается все по новой. Попробую склонить на отдельный пул белых IP.
--
Sent by ASSA
> брасы как правило стоят в ядре сети. там как правило есть pc-серверы.
> запустить через какой нибудь из них gre не составит проблемы. другое
> дело что через тп этого не добиться. надо писать официальное письмо
> руководству. если оно достаточно клиент-ориентированное то может пойти
> на вчтречу.
Я уже понял... но это не проектные костыли, про которые вкоре забывают и
> запустить через какой нибудь из них gre не составит проблемы. другое
> дело что через тп этого не добиться. надо писать официальное письмо
> руководству. если оно достаточно клиент-ориентированное то может пойти
> на вчтречу.
опять начинается все по новой. Попробую склонить на отдельный пул белых IP.
--
Sent by ASSA
Denis Ognewsky
Feb 6, 2015, 2:05:03 AM2/6/15
to
Hello, Igor O. Ladygin.
меньше 1%
On 06.02.15 10:41 you wrote:
>> брасы как правило стоят в ядре сети. там как правило есть
>> pc-серверы. запустить через какой нибудь из них gre не составит
>> проблемы. другое дело что через тп этого не добиться. надо писать
>> официальное письмо руководству. если оно достаточно
>> клиент-ориентированное то может пойти на вчтречу.
> Я уже понял... но это не проектные костыли, про которые вкоре
> забывают и опять начинается все по новой. Попробую склонить на
> отдельный пул белых IP.
я, тем кому нужен gre, выдаю бесплатно белые адреса. как оказалось их
>> брасы как правило стоят в ядре сети. там как правило есть
>> pc-серверы. запустить через какой нибудь из них gre не составит
>> проблемы. другое дело что через тп этого не добиться. надо писать
>> официальное письмо руководству. если оно достаточно
>> клиент-ориентированное то может пойти на вчтречу.
> Я уже понял... но это не проектные костыли, про которые вкоре
> забывают и опять начинается все по новой. Попробую склонить на
> отдельный пул белых IP.
меньше 1%
Igor O. Ladygin
Feb 6, 2015, 4:09:36 AM2/6/15
to
06.02.2015 14:51, Denis Ognewsky пишет:
ИМХО, нормальный провайдер так и должен поступать...
--
Sent by ASSA
--
Sent by ASSA
Eugene Grosbein
Feb 6, 2015, 3:05:03 PM2/6/15
to
05 фев 2015, четверг, в 21:53 NOVT, Alexandr Kruglikov написал(а):
EG>> Крупный провайдер типа ТТК может тупо отказаться менять схему
EG>> подключения физическому лицу.
AK> Hе вижу никакой проблемы в привязке PPPoEшному клиенту статического IP в
AK> биллинге. Хотя... Может ЗапСиб просто не предоставляет статические IP)))
AK> Я сужу по Волге)
Я сказал про отказ делать исключения, ничего не говоря о технической
возможности их делать.
Eugene
EG>> Крупный провайдер типа ТТК может тупо отказаться менять схему
EG>> подключения физическому лицу.
AK> биллинге. Хотя... Может ЗапСиб просто не предоставляет статические IP)))
AK> Я сужу по Волге)
Я сказал про отказ делать исключения, ничего не говоря о технической
возможности их делать.
Eugene
Ivan Levchenko
Mar 9, 2015, 2:05:04 PM3/9/15
to
Привет, Eugene!
Ответ на сообщение Eugene Grosbein (2:5006/1) к Alexey Vissarionov,
написанное 04 фев 15 в 20:59:
В нашем регионе ТТК вообще IPoE использует, выдавая каждому клиенту белые
айпишники "на шнурок" по DHCP физ. лицам и с ручным прописываниям адреса на
интерфейсе у юр. лиц.
С уважением - Ivan
Ответ на сообщение Eugene Grosbein (2:5006/1) к Alexey Vissarionov,
написанное 04 фев 15 в 20:59:
В нашем регионе ТТК вообще IPoE использует, выдавая каждому клиенту белые
айпишники "на шнурок" по DHCP физ. лицам и с ручным прописываниям адреса на
интерфейсе у юр. лиц.
С уважением - Ivan
Denis Ognewsky
Mar 10, 2015, 11:15:03 AM3/10/15
to
Hello, Ivan Levchenko.
On 09.03.15 22:57 you wrote:
> В нашем регионе ТТК вообще IPoE использует, выдавая каждому клиенту
> белые айпишники "на шнурок" по DHCP физ. лицам и с ручным
> прописываниям адреса на интерфейсе у юр. лиц.
и это правильно.
> В нашем регионе ТТК вообще IPoE использует, выдавая каждому клиенту
> белые айпишники "на шнурок" по DHCP физ. лицам и с ручным
> прописываниям адреса на интерфейсе у юр. лиц.
Alexey Vissarionov
Mar 10, 2015, 1:55:03 PM3/10/15
to
Доброго времени суток, Denis!
10 Mar 2015 17:59:14, ты -> All:
>> В нашем регионе ТТК вообще IPoE использует, выдавая каждому
>> клиенту белые айпишники "на шнурок" по DHCP
Option 0x82, или?
>> физ. лицам и с ручным прописываниям адреса на интерфейсе у юр. лиц.
DO> и это правильно.
И все же наиболее правильно - выдавать RFC-1918 по умолчанию и внешние по
запросу. Просто потому, что подавляющему большинству усеров внешние адреса
вообще не нужны...
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Никогда не оставляйте в туалете кубик Рубика!
10 Mar 2015 17:59:14, ты -> All:
>> В нашем регионе ТТК вообще IPoE использует, выдавая каждому
>> клиенту белые айпишники "на шнурок" по DHCP
>> физ. лицам и с ручным прописываниям адреса на интерфейсе у юр. лиц.
И все же наиболее правильно - выдавать RFC-1918 по умолчанию и внешние по
запросу. Просто потому, что подавляющему большинству усеров внешние адреса
вообще не нужны...
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Denis Ognewsky
Mar 11, 2015, 7:55:02 AM3/11/15
to
Hello, Alexey Vissarionov.
что для NAT нужно более мощное и более дорогое железо. но изза того что
ipv4 адреса кончились деваться некуда.
On 10.03.15 22:46 you wrote:
>>> В нашем регионе ТТК вообще IPoE использует, выдавая каждому
>>> клиенту белые айпишники "на шнурок" по DHCP
> Option 0x82, или?
>>> физ. лицам и с ручным прописываниям адреса на интерфейсе у юр.
>>> лиц.
> DO> и это правильно. И все же наиболее правильно - выдавать RFC-1918
> по умолчанию и внешние по запросу. Просто потому, что подавляющему
> большинству усеров внешние адреса вообще не нужны...
а потом возникают вопросы "почему меня забанили ?". не говоря уже о том
>>> В нашем регионе ТТК вообще IPoE использует, выдавая каждому
>>> клиенту белые айпишники "на шнурок" по DHCP
> Option 0x82, или?
>>> физ. лицам и с ручным прописываниям адреса на интерфейсе у юр.
>>> лиц.
> DO> и это правильно. И все же наиболее правильно - выдавать RFC-1918
> по умолчанию и внешние по запросу. Просто потому, что подавляющему
> большинству усеров внешние адреса вообще не нужны...
что для NAT нужно более мощное и более дорогое железо. но изза того что
ipv4 адреса кончились деваться некуда.
Denis Mikhlevich
Mar 12, 2015, 6:15:03 AM3/12/15
to
Hello, Alexey Vissarionov.
On 10.03.15 20:46 you wrote:
AV> Option 0x82, или?
??>>> физ. лицам и с ручным прописываниям адреса на интерфейсе у юр.
??>>> лиц.
DO>> и это правильно.
AV> И все же наиболее правильно - выдавать RFC-1918 по умолчанию и
AV> внешние по запросу. Просто потому, что подавляющему большинству
AV> усеров внешние адреса вообще не нужны...
Вместо RFC-1918 лучше выдавать из RFC-6598.
--
Galaxy Nexus, UB4CAR
On 10.03.15 20:46 you wrote:
AV> Option 0x82, или?
??>>> физ. лицам и с ручным прописываниям адреса на интерфейсе у юр.
??>>> лиц.
DO>> и это правильно.
AV> И все же наиболее правильно - выдавать RFC-1918 по умолчанию и
AV> внешние по запросу. Просто потому, что подавляющему большинству
AV> усеров внешние адреса вообще не нужны...
Вместо RFC-1918 лучше выдавать из RFC-6598.
--
Galaxy Nexus, UB4CAR
Denis Mikhlevich
Mar 12, 2015, 6:15:03 AM3/12/15
to
Hello, Denis Ognewsky.
On 11.03.15 14:07 you wrote:
??>> DO> и это правильно. И все же наиболее правильно - выдавать
??>> RFC-1918 по умолчанию и внешние по запросу. Просто потому, что
??>> подавляющему большинству усеров внешние адреса вообще не
??>> нужны...
DO> а потом возникают вопросы "почему меня забанили ?". не говоря уже
DO> о том что для NAT нужно более мощное и более дорогое железо. но
DO> изза того что ipv4 адреса кончились деваться некуда.
IPv6 надо уже использовать.
IPv4 был научным экспериментом.
--
Galaxy Nexus, UB4CAR
On 11.03.15 14:07 you wrote:
??>> DO> и это правильно. И все же наиболее правильно - выдавать
??>> RFC-1918 по умолчанию и внешние по запросу. Просто потому, что
??>> подавляющему большинству усеров внешние адреса вообще не
??>> нужны...
DO> а потом возникают вопросы "почему меня забанили ?". не говоря уже
DO> о том что для NAT нужно более мощное и более дорогое железо. но
DO> изза того что ipv4 адреса кончились деваться некуда.
IPv6 надо уже использовать.
IPv4 был научным экспериментом.
--
Galaxy Nexus, UB4CAR
Denis Mikhlevich
Mar 12, 2015, 6:15:04 AM3/12/15
to
Hello, Ivan Levchenko.
On 09.03.15 20:57 you wrote:
IL> В нашем регионе ТТК вообще IPoE использует, выдавая каждому
IL> клиенту белые айпишники "на шнурок" по DHCP физ. лицам и с ручным
IL> прописываниям адреса на интерфейсе у юр. лиц.
Зап сиб?
--
Galaxy Nexus, UB4CAR
On 09.03.15 20:57 you wrote:
IL> В нашем регионе ТТК вообще IPoE использует, выдавая каждому
IL> клиенту белые айпишники "на шнурок" по DHCP физ. лицам и с ручным
IL> прописываниям адреса на интерфейсе у юр. лиц.
Зап сиб?
--
Galaxy Nexus, UB4CAR
Alexey Vissarionov
Mar 12, 2015, 8:25:02 AM3/12/15
to
Доброго времени суток, Denis!
12 Mar 2015 12:56:32, ты -> мне:
??>>>> физ. лицам и с ручным прописываниям адреса на интерфейсе у юр.
??>>>> лиц.
DO>>> и это правильно.
AV>> И все же наиболее правильно - выдавать RFC-1918 по умолчанию и
AV>> внешние по запросу. Просто потому, что подавляющему большинству
AV>> усеров внешние адреса вообще не нужны...
DM> Вместо RFC-1918 лучше выдавать из RFC-6598.
Это 100.64.0.0/10 что ли?
Я егойный номер RFC не помню, а RFC-1918 написал по памяти :-)
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Сервер под Windows - как Запорожец представительского класса
12 Mar 2015 12:56:32, ты -> мне:
??>>>> физ. лицам и с ручным прописываниям адреса на интерфейсе у юр.
??>>>> лиц.
DO>>> и это правильно.
AV>> И все же наиболее правильно - выдавать RFC-1918 по умолчанию и
AV>> внешние по запросу. Просто потому, что подавляющему большинству
AV>> усеров внешние адреса вообще не нужны...
Это 100.64.0.0/10 что ли?
Я егойный номер RFC не помню, а RFC-1918 написал по памяти :-)
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Alexey Vissarionov
Mar 12, 2015, 8:35:03 AM3/12/15
to
Доброго времени суток, Denis!
12 Mar 2015 12:57:36, ты -> Denis Ognewsky:
??>>> RFC-1918 по умолчанию и внешние по запросу. Просто потому,
??>>> что подавляющему большинству усеров внешние адреса вообще
??>>> не нужны...
DO>> но изза того что ipv4 адреса кончились деваться некуда.
DM> IPv6 надо уже использовать.
Одно другого не исключает. Особенно если раздавать по DHCP.
DM> IPv4 был научным экспериментом.
И надо заметить, в IPv6 исправлены очень многие коряквы, с которыми люди
столкнулись в процессе этого эксперимента - прежде всего, размер адресного
пространства.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Лучше гипс и кроватка, чем плита и оградка
12 Mar 2015 12:57:36, ты -> Denis Ognewsky:
??>>> RFC-1918 по умолчанию и внешние по запросу. Просто потому,
??>>> не нужны...
DO>> а потом возникают вопросы "почему меня забанили ?". не говоря
DO>> уже о том что для NAT нужно более мощное и более дорогое железо.
DO>> но изза того что ipv4 адреса кончились деваться некуда.
DM> IPv6 надо уже использовать.
Одно другого не исключает. Особенно если раздавать по DHCP.
DM> IPv4 был научным экспериментом.
И надо заметить, в IPv6 исправлены очень многие коряквы, с которыми люди
столкнулись в процессе этого эксперимента - прежде всего, размер адресного
пространства.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Victor Sudakov
Mar 12, 2015, 10:01:50 AM3/12/15
to
Alexey Vissarionov wrote:
> IL> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
> IL> (канальное подключение PPPoE). После этого выяснилось что
> средствами Linux Netfilter, да и то с определенными ограничениями.
FreeBSD-шный libalias умеет натить PPTP, правда тоже с определенными
ограничениями:
"Alias_pptp.c performs special processing for PPTP sessions under TCP.
Specifically, watch PPTP control messages and alias the Call ID or
the Peer's Call ID in the appropriate messages.
[...] For Call IDs encountered for the first time, a PPTP alias link
is created. The PPTP alias link uses the Call ID in place of the
original port number. An alias Call ID is created. For this routine
to work, the PPTP control messages must fit entirely into a single TCP
packet."
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
> IL> Провайдер ТТК в регионе стал двать клиентам серые IP адреса
> IL> (канальное подключение PPPoE). После этого выяснилось что
> IL> через их NAT не работает PPTP, серому клиенту не приходят
> IL> GRE-пакеты от белого PPTP-сервера
> Работа GRE через NAT - лотерея. Теоретически такое можно реализовать
> IL> GRE-пакеты от белого PPTP-сервера
> средствами Linux Netfilter, да и то с определенными ограничениями.
FreeBSD-шный libalias умеет натить PPTP, правда тоже с определенными
ограничениями:
"Alias_pptp.c performs special processing for PPTP sessions under TCP.
Specifically, watch PPTP control messages and alias the Call ID or
the Peer's Call ID in the appropriate messages.
[...] For Call IDs encountered for the first time, a PPTP alias link
is created. The PPTP alias link uses the Call ID in place of the
original port number. An alias Call ID is created. For this routine
to work, the PPTP control messages must fit entirely into a single TCP
packet."
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Ivan Levchenko
Mar 12, 2015, 12:05:03 PM3/12/15
to
Привет, Denis!
Ответ на сообщение Denis Mikhlevich (2:5053/54.100) к Ivan Levchenko,
написанное 12 мар 15 в 12:55:
DM> Зап сиб?
ЦФО, Ивановская обл.
С уважением - Ivan
Ответ на сообщение Denis Mikhlevich (2:5053/54.100) к Ivan Levchenko,
написанное 12 мар 15 в 12:55:
DM> Зап сиб?
ЦФО, Ивановская обл.
С уважением - Ivan
Denis Ognewsky
Mar 12, 2015, 7:45:03 PM3/12/15
to
Hello, Denis Mikhlevich.
On 12.03.15 14:57 you wrote:
> ??>> DO> и это правильно. И все же наиболее правильно - выдавать
> ??>> RFC-1918 по умолчанию и внешние по запросу. Просто потому, что
> ??>> подавляющему большинству усеров внешние адреса вообще не ??>>
> нужны... DO> а потом возникают вопросы "почему меня забанили ?". не
> говоря уже DO> о том что для NAT нужно более мощное и более дорогое
> железо. но DO> изза того что ipv4 адреса кончились деваться некуда.
> IPv6 надо уже использовать. IPv4 был научным экспериментом.
в ipv6 сети контента мало очень.
> ??>> DO> и это правильно. И все же наиболее правильно - выдавать
> ??>> RFC-1918 по умолчанию и внешние по запросу. Просто потому, что
> ??>> подавляющему большинству усеров внешние адреса вообще не ??>>
> нужны... DO> а потом возникают вопросы "почему меня забанили ?". не
> говоря уже DO> о том что для NAT нужно более мощное и более дорогое
> железо. но DO> изза того что ipv4 адреса кончились деваться некуда.
> IPv6 надо уже использовать. IPv4 был научным экспериментом.
Denis Mikhlevich
Mar 13, 2015, 1:05:03 AM3/13/15
to
Hello, Ivan Levchenko.
On 12.03.15 18:48 you wrote:
IL> Ответ на сообщение Denis Mikhlevich (2:5053/54.100) к Ivan
IL> Levchenko, написанное 12 мар 15 в 12:55:
DM>> Зап сиб?
IL> ЦФО, Ивановская обл.
Значит ТТК-Центр.
Я из Волги-ТТК. Саратов.
--
Galaxy Nexus, UB4CAR
On 12.03.15 18:48 you wrote:
IL> Ответ на сообщение Denis Mikhlevich (2:5053/54.100) к Ivan
IL> Levchenko, написанное 12 мар 15 в 12:55:
DM>> Зап сиб?
IL> ЦФО, Ивановская обл.
Значит ТТК-Центр.
Я из Волги-ТТК. Саратов.
--
Galaxy Nexus, UB4CAR
Denis Mikhlevich
Mar 13, 2015, 1:05:03 AM3/13/15
to
Hello, Alexey Vissarionov.
AV> написал по памяти :-)
Да оно.
--
Galaxy Nexus, UB4CAR
On 12.03.15 15:15 you wrote:
AV>>> И все же наиболее правильно - выдавать RFC-1918 по умолчанию и
AV>>> внешние по запросу. Просто потому, что подавляющему большинству
AV>>> усеров внешние адреса вообще не нужны...
DM>> Вместо RFC-1918 лучше выдавать из RFC-6598.
AV> Это 100.64.0.0/10 что ли? Я егойный номер RFC не помню, а RFC-1918
AV>>> И все же наиболее правильно - выдавать RFC-1918 по умолчанию и
AV>>> внешние по запросу. Просто потому, что подавляющему большинству
AV>>> усеров внешние адреса вообще не нужны...
DM>> Вместо RFC-1918 лучше выдавать из RFC-6598.
AV> написал по памяти :-)
Да оно.
--
Galaxy Nexus, UB4CAR
Denis Mikhlevich
Mar 13, 2015, 1:05:03 AM3/13/15
to
Hello, Denis Ognewsky.
On 13.03.15 2:35 you wrote:
??>> ??>> DO> и это правильно. И все же наиболее правильно - выдавать
??>> ??>> RFC-1918 по умолчанию и внешние по запросу. Просто потому,
??>> что ??>> подавляющему большинству усеров внешние адреса вообще
??>> не ??>> нужны... DO> а потом возникают вопросы "почему меня
??>> забанили ?". не говоря уже DO> о том что для NAT нужно более
??>> мощное и более дорогое железо. но DO> изза того что ipv4 адреса
??>> кончились деваться некуда. IPv6 надо уже использовать. IPv4 был
??>> научным экспериментом.
DO> в ipv6 сети контента мало очень.
Нормально. А для тех кто ещё не перешёл можно и через NAT44 сходить. Главное
что при использовании IPv6 нет проблем сопутствующих NAT'у.
У меня например телевизор по IPv6 ходит за ютубом на гугловый кэш в моем
городе.
И это письмо отправляю с Андроида на ноду по IPv6.
--
Galaxy Nexus, UB4CAR
On 13.03.15 2:35 you wrote:
??>> ??>> DO> и это правильно. И все же наиболее правильно - выдавать
??>> ??>> RFC-1918 по умолчанию и внешние по запросу. Просто потому,
??>> что ??>> подавляющему большинству усеров внешние адреса вообще
??>> не ??>> нужны... DO> а потом возникают вопросы "почему меня
??>> забанили ?". не говоря уже DO> о том что для NAT нужно более
??>> мощное и более дорогое железо. но DO> изза того что ipv4 адреса
??>> кончились деваться некуда. IPv6 надо уже использовать. IPv4 был
??>> научным экспериментом.
DO> в ipv6 сети контента мало очень.
Нормально. А для тех кто ещё не перешёл можно и через NAT44 сходить. Главное
что при использовании IPv6 нет проблем сопутствующих NAT'у.
У меня например телевизор по IPv6 ходит за ютубом на гугловый кэш в моем
городе.
И это письмо отправляю с Андроида на ноду по IPv6.
--
Galaxy Nexus, UB4CAR
Denis Mikhlevich
Mar 13, 2015, 1:05:04 AM3/13/15
to
Hello, Alexey Vissarionov.
On 12.03.15 15:15 you wrote:
On 12.03.15 15:15 you wrote:
DO>>> а потом возникают вопросы "почему меня забанили ?". не говоря
DO>>> уже о том что для NAT нужно более мощное и более дорогое железо.
DO>>> но изза того что ipv4 адреса кончились деваться некуда.
DM>> IPv6 надо уже использовать.
AV> Одно другого не исключает. Особенно если раздавать по DHCP.
DO>>> уже о том что для NAT нужно более мощное и более дорогое железо.
DO>>> но изза того что ipv4 адреса кончились деваться некуда.
DM>> IPv6 надо уже использовать.
DM>> IPv4 был научным экспериментом.
AV> И надо заметить, в IPv6 исправлены очень многие коряквы, с
AV> которыми люди столкнулись в процессе этого эксперимента - прежде
AV> всего, размер адресного пространства.
Не предполагалось что IPv4 выйдет дальше эксперимента, поэтому адресов овер
нормально было для эксперимента.
Как мне известно в IPv6 размер поля адреса в заголовке тоже не плавающая
величина.
И больно расточительно придумали по /64 в влан. Т.е каждому абоненту надо
давать /64 минимум. Выделенные юникаст /3 из общего пространства в6. Получаем
/61 вместо /32 у в4. А не так как многие считают /128.
Я у Ripe сразу по максимуму /29 отхапал. Пока не понятно куда столько. Но в
будущем мне кажется меньше будут давать. И потомки будут благодарны. Максимум
видел у Ripe по /19 отхапали Orange и Дейч-Телеком. Вот куда столько, чтобы
потом через 30 лет продавать?
Должна повториться история с IPv4. Раньше можно было много загрести.
--
Galaxy Nexus, UB4CAR
Stanislav Vlasov
Mar 13, 2015, 4:15:03 AM3/13/15
to
Привет, Denis!
13 мар 15 07:50, Denis Mikhlevich -> Alexey Vissarionov в сообщении по ссылке
area://ru.cisco?msgid=2:5053/54.100+f5342838:
DM> Я у Ripe сразу по максимуму /29 отхапал. Пока не понятно куда столько.
Hа работе взяли /32.
Посчитали, сколько примерно атомов во вселенной (точнее, где-то нашли готовый
результат), решили, что нашего адресного пространства хватит, чтоб пометить
каждый атом и останется еще чуть-чуть на огородик.
Hа следующий день пришло письмо, где предлагали /28. Отказались.
С наилучшими пожеланиями, Stanislav.
13 мар 15 07:50, Denis Mikhlevich -> Alexey Vissarionov в сообщении по ссылке
area://ru.cisco?msgid=2:5053/54.100+f5342838:
DM> Я у Ripe сразу по максимуму /29 отхапал. Пока не понятно куда столько.
Hа работе взяли /32.
Посчитали, сколько примерно атомов во вселенной (точнее, где-то нашли готовый
результат), решили, что нашего адресного пространства хватит, чтоб пометить
каждый атом и останется еще чуть-чуть на огородик.
Hа следующий день пришло письмо, где предлагали /28. Отказались.
С наилучшими пожеланиями, Stanislav.
Alexey Vissarionov
Mar 13, 2015, 4:25:03 AM3/13/15
to
Доброго времени суток, Denis!
13 Mar 2015 07:50:36, ты -> мне:
DM>>> IPv6 надо уже использовать.
AV>> Одно другого не исключает. Особенно если раздавать по DHCP.
DM>>> IPv4 был научным экспериментом.
AV>> И надо заметить, в IPv6 исправлены очень многие коряквы, с которыми
AV>> люди столкнулись в процессе этого эксперимента - прежде всего,
AV>> размер адресного пространства.
DM> Не предполагалось что IPv4 выйдет дальше эксперимента, поэтому
DM> адресов овер нормально было для эксперимента.
Да и на глобус их кое-как натянули...
DM> Как мне известно в IPv6 размер поля адреса в заголовке тоже не
DM> плавающая величина.
Ты про struct sockaddr_in6? Там адрес описан вот таким элементом:
struct in6_addr sin6_addr;
Хотя на данный момент struct in6_addr содержит всего один элемент:
struct in6_addr { uint8_t s6_addr[16]; };
DM> И больно расточительно придумали по /64 в влан.
Расточительно было в IPX (32 бита номер сети + 48 битов адрес хоста). А
применительно к IPv6 никто не мешает использовать для сети хоть /126 :-)
DM> Т.е каждому абоненту надо давать /64 минимум.
Не обязательно: можно выдавать отдельные адреса из своей подсети.
Хотя вот тебе пример: аплинк зароутилл мне (как усеру) /64, а я ее порезал на
кучку /96, тем самым получив 4294967296 подсетей по 4294967296 адресов - то
есть, каждая из них имеет размер как у всего IPv4.
DM> Выделенные юникаст /3 из общего пространства в6. Получаем /61 вместо
DM> /32 у в4. А не так как многие считают /128.
/3 - это 1/8 адресного пространства. Остается 7/8.
DM> Я у Ripe сразу по максимуму /29 отхапал. Пока не понятно куда
DM> столько. Но в будущем мне кажется меньше будут давать. И потомки
DM> будут благодарны.
"Даже если я и жадничаю, зато от чистого сердца" // (ц)
DM> Максимум видел у Ripe по /19 отхапали Orange и Дейч-Телеком. Вот
DM> куда столько, чтобы потом через 30 лет продавать?
А куда тебе /29?
DM> Должна повториться история с IPv4. Раньше можно было много загрести.
При наличии процедуры отзыва адресов это не проблема.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... Рожденный ползать, уйдите со взлетной полосы!
13 Mar 2015 07:50:36, ты -> мне:
DM>>> IPv6 надо уже использовать.
AV>> Одно другого не исключает. Особенно если раздавать по DHCP.
DM>>> IPv4 был научным экспериментом.
AV>> люди столкнулись в процессе этого эксперимента - прежде всего,
AV>> размер адресного пространства.
DM> Не предполагалось что IPv4 выйдет дальше эксперимента, поэтому
DM> адресов овер нормально было для эксперимента.
Да и на глобус их кое-как натянули...
DM> Как мне известно в IPv6 размер поля адреса в заголовке тоже не
DM> плавающая величина.
Ты про struct sockaddr_in6? Там адрес описан вот таким элементом:
struct in6_addr sin6_addr;
Хотя на данный момент struct in6_addr содержит всего один элемент:
struct in6_addr { uint8_t s6_addr[16]; };
DM> И больно расточительно придумали по /64 в влан.
Расточительно было в IPX (32 бита номер сети + 48 битов адрес хоста). А
применительно к IPv6 никто не мешает использовать для сети хоть /126 :-)
DM> Т.е каждому абоненту надо давать /64 минимум.
Не обязательно: можно выдавать отдельные адреса из своей подсети.
Хотя вот тебе пример: аплинк зароутилл мне (как усеру) /64, а я ее порезал на
кучку /96, тем самым получив 4294967296 подсетей по 4294967296 адресов - то
есть, каждая из них имеет размер как у всего IPv4.
DM> Выделенные юникаст /3 из общего пространства в6. Получаем /61 вместо
DM> /32 у в4. А не так как многие считают /128.
/3 - это 1/8 адресного пространства. Остается 7/8.
DM> Я у Ripe сразу по максимуму /29 отхапал. Пока не понятно куда
DM> столько. Но в будущем мне кажется меньше будут давать. И потомки
DM> будут благодарны.
"Даже если я и жадничаю, зато от чистого сердца" // (ц)
DM> Максимум видел у Ripe по /19 отхапали Orange и Дейч-Телеком. Вот
DM> куда столько, чтобы потом через 30 лет продавать?
А куда тебе /29?
DM> Должна повториться история с IPv4. Раньше можно было много загрести.
При наличии процедуры отзыва адресов это не проблема.
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
Ivan Levchenko
Mar 13, 2015, 3:45:03 PM3/13/15
to
Привет, Denis!
Ответ на сообщение Denis Mikhlevich (2:5053/54.100) к Alexey Vissarionov,
написанное 13 мар 15 в 07:50:
DM> Ripe сразу по максимуму /29 отхапал. Пока не понятно куда столько. Но
DM> в будущем мне кажется меньше будут давать. И потомки будут благодарны.
DM> Максимум видел у Ripe по /19 отхапали Orange и Дейч-Телеком. Вот куда
DM> столько, чтобы потом через 30 лет продавать? Должна повториться
DM> история с IPv4. Раньше можно было много загрести.
А не подскажите, как подать заявку? вот хочется себе домой /64 подсеточку
получить. Дадут ли не организациям?
С уважением - Ivan
Ответ на сообщение Denis Mikhlevich (2:5053/54.100) к Alexey Vissarionov,
написанное 13 мар 15 в 07:50:
DM> Ripe сразу по максимуму /29 отхапал. Пока не понятно куда столько. Но
DM> в будущем мне кажется меньше будут давать. И потомки будут благодарны.
DM> Максимум видел у Ripe по /19 отхапали Orange и Дейч-Телеком. Вот куда
DM> столько, чтобы потом через 30 лет продавать? Должна повториться
DM> история с IPv4. Раньше можно было много загрести.
А не подскажите, как подать заявку? вот хочется себе домой /64 подсеточку
получить. Дадут ли не организациям?
С уважением - Ivan
Denis Ognewsky
Mar 15, 2015, 12:05:02 PM3/15/15
to
Hello, Ivan Levchenko.
On 14.03.15 0:25 you wrote:
> DM> Ripe сразу по максимуму /29 отхапал. Пока не понятно куда
> столько. Hо DM> в будущем мне кажется меньше будут давать. И потомки
> DM> Ripe сразу по максимуму /29 отхапал. Пока не понятно куда
> будут благодарны. DM> Максимум видел у Ripe по /19 отхапали Orange и
> Дейч-Телеком. Вот куда DM> столько, чтобы потом через 30 лет
> продавать? Должна повториться DM> история с IPv4. Раньше можно было
> много загрести. А не подскажите, как подать заявку? вот хочется
> себе домой /64 подсеточку получить. Дадут ли не организациям?
подключите провайдера с ipv6.
> Дейч-Телеком. Вот куда DM> столько, чтобы потом через 30 лет
> продавать? Должна повториться DM> история с IPv4. Раньше можно было
> много загрести. А не подскажите, как подать заявку? вот хочется
> себе домой /64 подсеточку получить. Дадут ли не организациям?
0 new messages