Эпидемия в сети

[german]

вообще инкапсуляция TCP over TCP плохая вещь , связанна с известной проблемой MRU, те управлением размером окна MTU.
Была статья очень интересная об особенностях работы инкапсулированного трафика на каналах с дропами....
Почему TCP поверх TCP - плохая идея

но терминирование клиента VPN , наиболее удобная и красивая идея, особенно если есть устройства для этого предназначеные, типа DSLAM'ов с vlan'овыми портами и поддержкой 802.1x, и считать удобно и управлять тоже. Все удовольствия в одном флаконе, те в Radius'e.

 

[alexk]

Koios
Цитата

Кстати, хотел бы узнать мнение тех кто в интернет "ходит" через VPN.
И как ведут себя сервисы поднятые на ВНП каналах. Лично мои воспоминания о пользовании интернетом через ВПН не совсем приятны. Не раз приходилось переподключаться, так как сессии рвались. В конце концов в Crone пришлось прописать каждые полчаса проверку того есть ли канал и если нет то Cron "поднимал" его заново.

У меня как раз ситуация доступа в интернет через реальный ip с помощью pptp vpn. Иногда бывает, что соединение держится днями, иногда - рвется несколько раз за полдня, о причинах такой работы ничего не могу сказать, т.к. для этого нужно одновременно видеть и сторону провайдера, а такой возможности у меня нет. Возможно указанные постоянные проблемы с обрывами сессий происходят при работе шифрования, у моего провайдера оно не применяется и вводить его зачастую нет смысла.

SlavaD
Цитата

тратим на клиента сеточку из 4-х IP как и раньше, но IP выдаем из приватной(фейковой) сети. IP выданный клиенту, используя SNAT и DNAT, подменяем реальным. В результате у клиента появляются все возможности работы с реального IP.

Имхо в теории не все возможности. Сервисы, которые в пакетах прикладного уровня хранят информацию об ip-адресах, при такой схеме работать не будут без дополнительных модулей conntrack и nat (если говорить про netfilter), которых может и не быть. На практике правда я с такими сервисами не встречался, но при желании можно написать

.