Такой разный VPN. Разбираем альтернативные протоколы VPN

#Обучение

Про­токол для VPN в иде­але дол­жен быть безопас­ным, фун­кци­ональ­ным и быс­трым. Но есть и еще один фак­тор: популяр­ность. Непопу­ляр­ный про­токол слож­нее внед­рить и под­держи­вать: его прог­рам­мное обес­печение тре­бует­ся уста­нав­ливать и нас­тра­ивать, а поль­зовате­лей и адми­нис­тра­торов нуж­но обу­чать.

Иног­да про­токо­лы ста­новят­ся популяр­ными воп­реки сво­им тех­ничес­ким недос­таткам, прос­то из‑за агрессив­ного прод­вижения круп­ной ком­пани­ей. Быва­ет и наобо­рот, про­токол незави­симых раз­работ­чиков реша­ет нас­толь­ко насущ­ную проб­лему какой‑то час­ти поль­зовате­лей, что быс­тро набира­ет популяр­ность сам по себе. Так про­изош­ло с OpenVPN или WireGuard.

Не­кото­рые про­токо­лы теря­ют популяр­ность. Некото­рые так и не ста­новят­ся широко извес­тны­ми, иног­да зас­лужен­но, иног­да нет. В этой статье мы погово­рим о нес­коль­ких таких про­токо­лах.

PPTP

Про­токол PPTP (Point to Point Tunneling Protocol) ока­зал­ся на зад­ворках впол­не спра­вед­ливо. Хочет­ся верить, что молодые читате­ли с ним уже не стал­кивались, но лет десять назад он был хрес­томатий­ным при­мером незас­лужен­но популяр­ного про­токо­ла.

По­пуляр­ность ему обес­печила монопо­лия его раз­работ­чика — кор­порации Microsoft. С середи­ны девянос­тых до кон­ца двух­тысяч­ных абсо­лют­ное боль­шинс­тво кли­ент­ских устрой­ств были компь­юте­рами с Windows. Оче­вид­но, наличие в Windows встро­енно­го кли­ента авто­мати­чес­ки делало про­токол как минимум рас­простра­нен­ным.

Microsoft не была бы самой собой, если бы не вос­поль­зовалась этим для сох­ранения и укрепле­ния сво­его монополь­ного положе­ния. Про­токол PPTP исполь­зовал стан­дар­тные PPP и GRE для переда­чи дан­ных, но для аутен­тифика­ции и шиф­рования при­менял­ся нес­тандар­тный, патен­тован­ный набор про­токо­лов: MPPE (Microsoft Point-to-Point Encryption) и MS-CHAP.

Из‑за это­го сво­бод­ные реали­зации что кли­ента, что сер­вера PPTP были в свое вре­мя такой же боль­ной темой, как GIF и MP3. Затем срок дей­ствия патен­тов истек, poptop для Linux и MPD для FreeBSD ста­ли популяр­ными аль­тер­натива­ми проп­риетар­ным про­дук­там.

Од­нако пре­дуп­режде­ния о проб­лемах безопас­ности самодель­ной крип­тогра­фии не были бес­почвен­ными. Оцен­ки стой­кос­ти MMPE и MS-CHAP неод­нократ­но сни­жались, и в 2012 году про­токол был дис­кре­дити­рован окон­чатель­но: иссле­дова­тели доказа­ли, что стой­кость MS-CHAP-v2 не луч­ше DES. Пос­ле это­го вос­при­нимать PPTP как безопас­ный про­токол ста­ло невоз­можно, и он быс­тро потерял пос­ледние остатки популяр­ности.

Стоит ли использовать PPTP?

Оче­вид­но, катего­ричес­ки не рекомен­дует­ся.

SSTP

SSTP (Secure Socket Tunneling Protocol) — вто­рая попыт­ка Microsoft соз­дать собс­твен­ный про­токол для VPN. В этот раз они не ста­ли изоб­ретать свои крип­тогра­фичес­кие алго­рит­мы, а исполь­зовали стан­дар­тный SSL/TLS. Они так­же боль­ше не пре­пятс­тву­ют соз­данию сво­бод­ных реали­заций.

SSTP пред­став­ляет собой PPP поверх HTTPS. Оче­вид­ное пре­иму­щес­тво — он отлично про­ходит через NAT и теоре­тичес­ки даже через прок­си. Пре­иму­щес­тво далеко не уни­каль­ное, OpenVPN умел работать поверх TCP/443 задол­го до это­го.

OpenVPN, впро­чем, не прос­то так по умол­чанию исполь­зует UDP, а не TCP. У тун­нелей поверх TCP наб­люда­ются серь­езные проб­лемы с про­изво­дитель­ностью — на одном и том же железе они могут быть в десят­ки раз мед­леннее.

В Windows, оче­вид­но, есть встро­енный кли­ент — начиная с Windows Vista. Для Linux есть реали­зации кли­ента и пла­гины к NetworkManager. Есть и сто­рон­ние кли­енты для macOS, нап­ример EasySSTP. Для мобиль­ных устрой­ств тоже при­дет­ся искать и ста­вить сто­рон­ние при­ложе­ния.

Ес­ли нуж­но раз­вернуть сер­вер SSTP, из сво­бод­ных про­ектов его под­держи­вают accel-pppd и SoftEther.

Стоит ли использовать SSTP?

Раз­ве что если вынуж­дает кор­поратив­ная полити­ка.

SOFTETHER

SoftEther — мно­гоп­ротоколь­ный сер­вер VPN, подоб­но MPD или accel-ppp. Он под­держи­вает L2TP/IPsec, PPTP, SSTP, OpenVPN и одно­имен­ный нес­тандар­тный про­токол SoftEther. Это дос­таточ­но молодой про­ект, его пер­вая вер­сия выш­ла в 2014 году.

Про­токол SoftEther пред­став­ляет собой Ethernet поверх HTTPS. Пос­коль­ку за шиф­рование и аутен­тифика­цию отве­чает стан­дар­тный SSL, безопас­ность осо­бых воп­росов не вызыва­ет.

Ав­торы заяв­ляют о про­изво­дитель­нос­ти в десять раз выше OpenVPN. Верит­ся с тру­дом, но воз­можнос­ти про­верить их заяв­ления у меня нет. Кли­ент есть толь­ко для Linux и Windows, так что на про­чих плат­формах при­дет­ся исполь­зовать дру­гие про­токо­лы.

Стоит ли использовать SoftEther?

Ес­ли утвер­жде­ния авто­ров о про­изво­дитель­нос­ти вер­ны, может, и сто­ит.

OPENCONNECT

Тер­мин SSL VPN без кон­тек­ста — час­то встре­чающий­ся, но совер­шенно бес­смыс­ленный. «Под­держи­вает SSL VPN» может озна­чать и SSTP, и OpenVPN, и мно­жес­тво несов­мести­мых проп­риетар­ных про­токо­лов.

Свой такой про­токол есть поч­ти у каж­дого вен­дора. Нап­ример, Cisco AnyConnect, Juniper Pulse Connect, Palo Alto GlobalProtect. Если в орга­низа­ции широко исполь­зует­ся кли­ент к такому про­токо­лу, сме­нить обо­рудо­вание кон­цен­тра­тора VPN может быть очень слож­но — чего вен­доры и добива­ются.

Сво­бод­ный про­ект OpenConnect пре­дос­тавля­ет реали­зации сер­вера и кли­ента для про­токо­лов Cisco, Juniper и Palo Alto. Кли­ент OpenConnect работа­ет на Windows и мно­жес­тве UNIX-подоб­ных сис­тем: не толь­ко Linux и macOS, но и сис­темах семей­ства BSD и даже Solaris.

Сер­вер OCServ может сэконо­мить орга­низа­ции немалые день­ги, пос­коль­ку в проп­риетар­ных реали­заци­ях эти про­токо­лы час­то лицен­зиру­ются на каж­дого поль­зовате­ля.

Стоит ли использовать OpenConnect?

Ес­ли твоя орга­низа­ция внед­рила один из этих про­токо­лов и теперь сама не рада — безус­ловно. Пос­коль­ку ни один из этих про­токо­лов не защищен патен­тами (да и патен­товать в них осо­бо нечего), единс­твен­ный реаль­ный риск сущес­тво­ванию про­екта — судеб­ные иски о тор­говых мар­ках. В наз­вании про­екта зарегис­три­рован­ные тор­говые мар­ки не фигури­руют, так что риск невелик. Кро­ме того, про­ект сущес­тву­ет с 2009 года, и до сих пор ник­то из вен­доров не судил­ся с авто­рами.

ВАРИАЦИИ НА ТЕМУ IPSEC

Ка­залось бы, IPsec — самый стан­дарти­зован­ный про­токол из всех, и его под­держи­вают все пос­тавщи­ки сетево­го обо­рудо­вания. Но со стан­дарти­зован­ным про­токо­лом не заманишь поль­зовате­лей в ловуш­ку vendor lock-in, поэто­му на тему IPsec регуляр­но изоб­рета­ют проп­риетар­ные вари­ации.

Иног­да они реша­ют впол­не реаль­ную проб­лему, которую слож­но решить чис­тым IPsec. Нап­ример, Cisco GETVPN (Group Encrypted Transport) упро­щает раз­верты­вание защищен­ной сети для поль­зовате­лей MPLS, пос­коль­ку сам MPLS никакой защиты от перех­вата тра­фика не пре­дос­тавля­ет.

В дру­гих слу­чаях, как с EZVPN, пос­тавщи­ки пыта­ются под­купить поль­зовате­лей отно­ситель­ной прос­тотой нас­трой­ки по срав­нению с «нор­маль­ным» IPsec.

Стоит ли использовать проприетарные вариации IPsec?

Ес­ли пер­спек­тива нав­сегда остать­ся при­вязан­ным к одно­му пос­тавщи­ку не пуга­ет... В слу­чае с EZVPN, нап­ример, некото­рые устрой­ства под­держи­вают толь­ко сер­вер, а некото­рые — толь­ко кли­ент, так что выбор может быть огра­ничен еще и кон­крет­ной моделью.

КЛИЕНТСКИЙ IPSEC

Кста­ти об IPsec. Обыч­но он исполь­зует­ся для фик­сирован­ных тун­нелей site-to-site либо как защищен­ный тран­спорт для дру­гого про­токо­ла вро­де L2TP. Ста­рый про­токол IKEv1 дей­стви­тель­но был пло­хо прис­пособ­лен для кли­ент­ских под­клю­чений. Одна­ко сов­ремен­ный IKEv2 справ­ляет­ся куда луч­ше. Более того, встро­енная под­дер­жка это­го вида тун­нелей при­сутс­тву­ет во всех сис­темах, вклю­чая Windows, macOS и мобиль­ные устрой­ства.

Со сво­бод­ными реали­заци­ями сер­вера тоже проб­лем нет, тот же StrongSWAN офи­циаль­но под­держи­вает кли­ент­ские под­клю­чения.

Стоит ли использовать клиентский IPsec?

Ес­ли ты нас­тра­иваешь сер­вер с нуля и хочешь встро­енную под­дер­жку кли­ента во всех рас­простра­нен­ных ОС, как минимум рас­смот­реть этот вари­ант нарав­не с L2TP/IPsec точ­но сто­ит.

TINC

Боль­шинс­тво про­токо­лов VPN ори­енти­руют­ся на тополо­гии «точ­ка — точ­ка» или «звез­да». Mesh-сети до сих пор оста­ются дос­таточ­но экзо­тичес­ким сце­нари­ем. Тем не менее про­токо­лы для этих целей сущес­тву­ют и раз­вива­ются. Про­ект TINC раз­рабаты­вает­ся с 1998 года. Это зна­чит, он стар­ше OpenVPN, который выпус­тил свою пер­вую вер­сию в 2001-м. Он под­держи­вает Windows и все UNIX-подоб­ные ОС, но вер­сий для мобиль­ных ОС у него нет.

Глав­ная фича — авто­мати­чес­кое пос­тро­ение mesh-сети. Даже если в сети мно­жес­тво узлов, тра­фик меж­ду ними будет переда­вать­ся нап­рямую, а не через цен­траль­ный сер­вер. Это может сде­лать TINC рабочей аль­тер­нативой Dynamic Multi-Point VPN и упо­мяну­тому GETVPN для кор­поратив­ных сетей. Ну или мог­ло бы, если бы пос­тавщи­ки сетево­го обо­рудо­вания и популяр­ные сво­бод­ные сетевые ОС его под­держи­вали.

Стоит ли использовать TINC?

Как минимум поэк­спе­римен­тировать точ­но будет инте­рес­но.

ЗАКЛЮЧЕНИЕ

Про­токо­лов для VPN в мире великое мно­жес­тво. Даже если ты пред­почита­ешь исполь­зовать толь­ко самые популяр­ные, знать о дру­гих небес­полез­но — выбор будет более информи­рован­ным.

Источник