19:04 

Про VPN

DukeSS
Танкист Апокалипсиса
Сегодня хочу рассказать немного о различных реализациях VPN, которыми мне пришлось пользоваться за долгую историю работы у нас в конторе. Выбор программ эволюционировал вслед за ростом фирмы, а также повышением уровня моей лени. Как я уже достаточно давно писал, за всё время работы мне довелось участвовать в переездах более 10 раз. Развитие фирмы отразилось в количестве офисов (с двух в 2002 году до 13 на нынешний момент), а регулярные переезды - в регулярной же перенастройке VPN-соединений (точка-точка), число которых уже должно достигать 91 (тут, правда, спасает то, что три четверти соединений, могут быть перенаправлены через существующие каналы, так как используются намного менее интенсивно из-за территориальной обособленности. Но хочется ведь, чтобы было красиво.
Итак:
1. Первым вариантом, который я испробовал, был PPP через SSH. Могу сказать, что такой вариант соединения работал, но достаточно регулярно происходили обрывы связи. Впрочем, это было давно и неправда. Сейчас, при наличии различных реализаций VPN, о том опыте можно вспоминать только.... лучше не вспоминать.
2. После первой попытки, возможно, я что-то пробовал ещё, но об этом опыте уже забыл, поэтому перехожу к сразу к следующему варианту: CIPE - Crypto IP Encapsulation. Этот вариант позволил связывать несколько сетей с не очень большим количеством трудозатрат на добавление-удаление новых узлов, однако, для того, чтобы добавить новый узел при N уже существующих, необходимо было настроить 2*N конфигурационных файлов. При смене внешнего адреса приходилось также менять 2*N конфигурационных файлов. В общем, с этим можно было бы продолжать мириться, но последние версии ядра Linux семейства 2.6 уже не работали с этой программой, поэтому пришлось искать замену.
3. Следующий вариант искать долго не пришлось, несмотря на то, что к этому моменту я уже понимал, что: а) мне не хочется каждый раз при переезде менять кучу настроек, б) при обрыве связи мне хочется, чтобы канал восстанавливался автоматически, как только будет возможность. Итак, в 2010 году был предпринят очередной поиск лучшего варианта, результатом которого стал CloudVPN. Эта реализация VPN отличается от предыдущих тем, что позволяет строить частные сети сети произвольной конфигурации, дублировать соединения, имеет встроенный маршрутизатор, позволяющий связать два любых узла сети, даже если между ними нет прямого канала. Недостатки есть продолжение достоинств: по умолчанию нельзя принудительно указать узлы, которые разрешено использовать для маршрутизации, а которые нет, во избежание чрезмерного забивания канала траффиком. В последних версиях появилась опция настройки route_max_dist, которая позволяет ограничивать удаль встроенного маршрутизатора, но на сайте разработчика, насколько я помню, об этом пока не сказано ни слова, искать информацию нужно в исходных текстах.
4. Время не стоит на месте, и появляются новые разработки. Сейчас меня заинтересовал проект n2n - средство для создания одноранговой (децентрализованной) VPN, которое очень просто и быстро в настройке: для создания сети из N узлов достаточно настроить по одной конфигурации на каждом из узлов. Всё остальное (установление соединений между каждой парой узлов) будет сделано автоматически. Сделано это благодаря использованию одного-двух "суперузлов", которые занимаются регистрацией членов сети и предоставлением информации о адресах и портах участников сети друг другу для возможности установления соединения напрямую, минуя посредников. В случае, если два узла находятся за NAT/брандмауэром, суперузел берёт на себя роль посредника, через которого и общаются эти узлы. Впрочем, наличие суперузлов, которые, к тому же, пока не умеют обмениваться информацией о состоянии сети и синхронизировать её, делает эту VPN неработоспособной при их отказе. Также есть нюанс в работе клиентов: при недоступности по какой-либо причине первого из суперузлов, происходит переключение на резервный без последующих попыток подключиться к основному суперузлу. То есть возможна такая ситуация: у одного из узлов теряется несколько пакетов на пути к суперузлу; видя, что суперузел недоступен, узел переходит к резервному суперузлу; для остальных же участников сети основной суперузел продолжает оставаться активным. В результате перешедший к резервному суперузлу клиент пропадает из сети.
Впрочем, этот проект сейчас находится в стадии разработки, так что к релизу, надеюсь, детские болезни будут побеждены. Надеюсь потому, что эта концепция VPN наиболее близка моей лени.

@темы: Информационные технологии, Опыт сын ошибок трудных

URL
   

Что-то видел, что-то знаю...

главная