Дзве VPN-прыступкі запар: хто насамрэч бачыць ваш трафік?

Кожны профіль кліента называе адзін сервер, таму з месца карыстальніка ёсць адзін тунель і адно месца, дзе абарона заканчваецца. Што адбываецца пасля гэтага першага шлюза — гэта рашэнне праектавання, якога кліент ніколі не бачыць, і два распаўсюджаныя варыянты паводзяць сябе вельмі па-рознаму пры праверцы. У паслядоўным ланцугу першы шлюз расшыфроўвае і зноў шыфруе. Ва ўкладзеным ланцугу ён здымае знешні слой і перадае ўнутраны тунель, які не можа адкрыць. Колькасць прыступак у абодвух аднолькавая, таму розніцу трэба маляваць, а не лічыць.

Пачніце з кліента і назавіце абодва канцы

Пачніце там, дзе пачынае карыстальнік, — у профілі злучэння. У ім ёсць адзін выдалены адрас, адзін метад аўтэнтыфікацыі і, калі праект гэта падтрымлівае, спіс маршрутаў. Пазначце гэты знешні тунель ад кліента да шлюза A і дайце яму прыкладныя адрасы: адрас тунеля кліента 10.77.0.2, адрас A 10.77.0.1 і публічны канчатковы пункт A 198.51.100.10, узятыя з дакументацыйнага дыяпазону TEST-NET-2, каб нішто ў прыкладзе не сутыкнулася з рэальным хастом.

У гэтым профілі нічога не сказана пра шлюз B, і гэта не дэфект. Другая прыступка належыць A, і адзіны абавязак кліента — даставіць трафік да A і прыняць тое, што вернецца. Ці A завяршае тунель, перадае яго або адкрывае новы, — гэта пытанне, на якое адказвае рэшта гэтага агляду, і яно вызначае, што A можа чытаць.

Паслядоўна: A расшыфроўвае, потым шыфруе зноў

У паслядоўным варыянце A завяршае трафік двойчы. Яно здымае абарону з кліента, атрымлівае IP-пакет праграмы і затым адпраўляе гэты пакет праз другі тунель, які A стварае ў бок B. Паміж гэтымі дзвюма аперацыямі пакет знаходзіцца ў шляху перасылкі A як звычайны IP-пакет, адрасаваны прыватнаму пункту прызначэння.

Гэта дае дзве наступствы, якія варта назваць прама. A можа ўжыць палітыку да ўнутранага пакета — маршруты, правілы фільтрацыі і журналіраванне крыніцы і прызначэння, — і A павінна трымаць два наборы ўліковых даных: адзін як сервер для кліента і адзін як кліент B. Абарона існуе ў кожны момант, але аб'ект, які абараняецца, змяняе ідэнтычнасць на A.

З гэтага не вынікае, што A чытае адкрыты тэкст праграмы. Калі кліент і сэрвіс выкарыстоўваюць TLS і правяраюць сертыфікаты адзін аднаго, A бачыць паток запісаў TLS, а не чытэльны запыт. Каб пацвердзіць, дзе заканчваецца гэтая абарона, трэба глядзець на ланцуг сертыфікатаў сэрвісу, а не на схему тунеля.

Укладзена: A здымае толькі знешні слой

Ва ўкладзеным варыянце кліент спачатку будуе ўнутраны тунель да B, а затым нясе гэты тунель унутры знешняга да A. A здымае знешні загаловак, знаходзіць унутраны тунель і перадае яго, не трымаючы яго ключоў, таму ўнутраная абарона ўсё яшчэ заканчваецца на B.

Тады ўзыходзячы канал кліента нясе два слоі, а шлях паміж A і B — адзін. A бачыць знешнія адрасы ўнутранага тунеля; гэтага дастаткова, каб ведаць, што трафік існуе і прыблізна куды ён ідзе, і недастаткова, каб прачытаць карысную нагрузку. Гэта ўся розніца ад паслядоўнага выпадку, і ніводны лічыльнік прыступак яе не пакажа. Што A ўсё яшчэ можа зрабіць — адмовіцца перадаваць тое, чаго не можа прачытаць, і гэта заўсёды даступна аператару гэтага шлюза.

Укладанне бярэ плату за гэтую ўласцівасць. Кожны слой дадае накладныя выдаткі загалоўка, таму планаванне MTU і MSS робіцца абавязковым, а не акуратным, і шлях, які працуе з адным слоем, можа маўкліва губляць буйныя пакеты з двума. Кожны слой таксама патрабуе сваіх паводзін перападлучэння і падтрымання сувязі, а збой у адным слоі выглядае як частковае перапыненне праз другі.

Маліце назіральнікаў, а не толькі тунелі

Тунелі — лёгкая частка малюнка. Назіральнікі — гэта тое, пра што ўвесь праект, таму напішыце па адным радку на кожную кропку агляду і запоўніце, што кожная насамрэч можа прачытаць.

Два радкі пастаянна блытаюць: аператар A і пастаўшчык тунеля кліента. Яны могуць быць адной сутнасцю, і асобныя імёны шлюзаў не робяць іх незалежнымі. Незалежнае ўладанне патрабуе асобнага адміністрацыйнага кантролю, асобных уліковых даных і асобнага журнала.

Метаданыя перажываюць абодва варыянты. Час, памеры пакетаў і колькасць злучэнняў застаюцца назіральнымі на кожнай прыступцы, таму дзве прыступкі падымаюць цану карэляцыі, а не выдаляюць сігнал. Варыянт, які абяцае нябачнасць, варта праверыць па гэтым спісе, перш чым на яго спадзявацца.

Прайдзіце шляхі збояў, перш чым выбіраць

Ламайце рэчы наўмысна з боку кліента, у тым парадку, у якім іх сустрэне карыстальнік. Пачніце з інтэрфейса і яго MTU, бо ўкладанне здае на памеры пакета значна раней, чым на аўтэнтыфікацыі.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Затым пацвердзіце канчатковыя пункты абароны, а не прымайце іх на веру. Папрасіце ў сэрвісу яго сертыфікат знутры таго тунеля, які зараз падняты, і параўнайце ланцуг, які бачыць кліент, з ланцугом, які сэрвіс насамрэч прад'яўляе. Шлюз, які перападпісвае або перахоплівае, змяняе гэты сертыфікат, і праверка робіцца бачнай адной камандай.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Скончыце матрыцай перападлучэння: тунель кліента падае, тунель B падае, шлях паміж A і B змяняецца. Заўважце, што вяртаецца і што не, і ці ніколі ўнутранае злучэнне не адкатваецца на маршрут па-за сваім прызначаным носьбітам. Запішыце адрасы, якія выкарыстоўваў кожны тэст, бо паўтор на іншай сетцы доступу адказвае на іншае пытанне. Паўтарыце таксама пробу MTU пасля кожнага перападлучэння, бо зменены шлях можа знізіць прыдатны памер без аніводнага зруху радка канфігурацыі.

Выбірайце паслядоўны варыянт, калі A павінна ўжыць палітыку да ўнутранага пакета або калі кліент не можа запускаць два ўкладзеныя тунелі. Выбірайце ўкладанне, калі ўнутраная нагрузка павінна заставацца нечытэльнай на A. Запішыце выбар разам з назіральнікамі і лічбамі MTU, і наступнаму чалавеку не давядзецца перамалёўваць усю карціну, каб адказаць на адно пытанне.