Два DNS-імені, адзін порт OpenVPN: што насамрэч выбірае

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

Пачніце з таго, што вяртае рэзалвер

Кліент запытвае vpn-a.example і атрымлівае адрас; гэты адрас плюс порт — усё, да чаго ён падключаецца. Імя выдаткавана лакальна, падчас пошуку, і яно ніколі не становіцца полем у сетцы, таму слухач на іншым канцы не бачыць, якая метка выкарыстана. Накіруйце vpn-a.example і vpn-b.example на адзін хост, і абодва пошукі дадуць той жа пункт прызначэння, таму дэман паглынае абодва злучэнні ў адзін асобнік, не фіксуючы розніцы. Профілі на аснове адраса паводзяць сябе гэтак жа, як профілі на аснове імя, з той жа прычыны.

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

Адзіны селектар, які лічыцца, едзе ўнутры пакета

HTTP робіць гэта з дапамогай загалоўка Host, а TLS — з дапамогай пашырэння імені сервера ў ClientHello, і менавіта так адзін адрас абслугоўвае мноства сайтаў за адным слухачом. Абодва працуюць, бо сеткавы пратакол нясе запыт на канкрэтную паслугу. Істотны факт пра OpenVPN: ні аднаго з гэтых палёў няма на тым узроўні, які аглядае прамежкавы вузел.

У звычайнай схеме рукапоціск TLS, які абараняе кантрольны канал, адбываецца пасля ўсталявання вонкавай сесіі і пераносіцца ўнутры яе, таму слухач, які не завяршыў гэтую сесію, бачыць непразрысты паток. Ён усё яшчэ можа сказаць, што гэта OpenVPN, бо коды аперацый і фарматаванне ў першых байтах пазнавальныя, але імя сервера, калі яно ёсць, знаходзіцца ў зашыфраванай частцы. Дызайн, які спадзяецца прачытаць віртуальны хост з вонкавага пакета, чытае поле, якое пратакол ніколі туды не піша. Гэта вынікае з таго, як пабудаваны тунель, а не з прагаліны, якую мог бы зачыніць разумнейшы пошук шаблону.

Дзе раздзяляльнік пратаколаў спыняецца

Мультыплексар таго тыпу, які дакументуе праект sslh, слухае на адным порце, аглядае першыя байты і перадае злучэнне таму бэкенду, які гаворыць на пазнаным пратаколе. Гэта рэальная каштоўнасць, калі адзін порт павінен абслугоўваць SSH, HTTPS і OpenVPN разам.

sslh трымае асобны зонд для кожнага пратакола, і яго зонд TLS можа выцягнуць імя сервера або значэнне ALPN з сапраўднага ClientHello. Распазнанне натыўнага OpenVPN — гэта іншая класіфікацыя, чым чытанне пашырэння TLS, і яны не складаюцца, бо кліент, які ніколі не дасылае ClientHello на слухаючы сокет, пакідае зонд без нічога для чытання. Таму правіла, якое супадае з OpenVPN, адказвае “гэта кліент OpenVPN” і далей не ідзе. Два бэкенды OpenVPN за гэтым правілам неадрозныя, у франтальнага боку няма падставы для выбару, і кожная сесія трапляе ў адно месца. Мультыплексаванне дзеліць адзін порт паміж рознымі службамі; яно не робіць віртуальны хост унутры адной службы.

Схемы, якія сапраўды раздзяляюць два серверы

Найтаннейшы сумленны падзел — другі публічны адрас, па адным на асобнік, і існуючыя профілі ўжо маюць патрэбнае, бо паказваюць на розныя адрасы. Наступны — іншы порт на тым жа адрасе, што не каштуе нічога, акрамя ліку ў кожным профілі. TCP і UDP трымаюць асобныя табліцы партоў, таму 1194/tcp і 1194/udp — незвязаныя сокеты, і па адным з кожнага могуць існаваць на адным хосце; гэта падзел транспарту, а не маршрутызацыя па імені, і яго часта з ёй блытаюць. Абодва варыянты вытрымліваюць праверку фаеруола, бо правіла супадае з тым, што пакет сапраўды змяшчае.

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

Тэрмінатар TLS, пастаўлены перад OpenVPN, можа паказаць сапраўднае імя сервера здольнаму франтальнаму боку, але толькі тады, калі кліенцкі бок таксама настроены на гэты дадатковы ўзровень. Існуючыя профілі не набываюць такіх паводзін ад простага накіравання на той жа адрас.

Дакажыце селектар да пабудовы

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

ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager

Радок openssl выдае сертыфікат толькі там, дзе нешта на гэтым адрасе завяршае TLS; супраць натыўнага слухача OpenVPN ён затынаецца або падае, і гэта само па сабе адказ пра тое, што паказвае вонкавы ўзровень. Радок journal, прачытаны на кожным бэкендзе, паказвае, які асобнік прыняў сесію. Франтальныя журналы запісваюць тое, што было класіфікавана, і ніколі тое, што меркавалася, таму бэкенд застаецца адзінай інстанцыяй пра тое, куды трапіў карыстальнік.

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