Две DNS имиња, еден OpenVPN порт: што всушност избира

Два A записи, една адреса, еден демон: кое и име да внесе корисникот, пакетот што пристигнува е идентичен, а процесот врзан за портата 1194 нема со што да ги разликува двете. Ова не е погрешна конфигурација што чека поправка; ова е границата на она што може да го изрази едно пребарување по име. Сето она што избира меѓу две инстанци на OpenVPN мора да биде вредност што клиентот ја става во врската и што предниот дел може да ја прочита назад, а стандарден OpenVPN клиент не става таква вредност отворено. Она што следи е каде ве остава тоа и кои распореди навистина го делат сообраќајот.

Започнете со тоа што го враќа разрешувачот

Клиент бара vpn-a.example и добива адреса; таа адреса плус порта е сето она на што се поврзува. Името се троши локално, за време на пребарувањето, и никогаш не станува поле на жицата, па слушателот од другата страна не може да види која ознака е искористена. Насочете vpn-a.example и vpn-b.example кон еден домаќин и двете пребарувања ќе дадат иста цел, поради што демонот ги впива двете врски во една инстанца без да регистрира разлика. Профилите засновани на адреса се однесуваат сосема како оние засновани на име, од истата причина.

Ова исто така затвора едно семејство примамливи заобиколни решенија: дополнителни псевдоними, избирање сертификат за секое име на еден сокет или правило на огнен ѕид врзано за прашаното име. Ниту едно од нив не може да дејствува врз информација што веќе била отфрлена пред првиот пакет да го напушти клиентот. Ако два сервера мора да останат одделни, поделбата мора да патува со самата врска, што значи адреса, порта или поле за носивост што го дефинира протоколот.

Единствениот избирач што се брои патува во пакетот

HTTP го решава ова со заглавие Host, а TLS со продолжување за име на сервер во ClientHello, и така една адреса служи многу локации зад еден слушател. Двете функционираат затоа што протоколот на жицата носи барање за одредена услуга. Релевантниот факт за OpenVPN е дека ниту едно од тие полиња не е присутно на слојот што го прегледува средна кутија.

Во стандарден распоред TLS-ракувањето што го штити контролниот канал се случува откако ќе се воспостави надворешната сесија и се носи внатре во неа, па слушателот што не ја завршил таа сесија гледа непрозирен тек. Сѐ уште може да каже дека ова е OpenVPN, бидејќи опкодот и врамувањето во првите бајти се препознатливи, но името на серверот, ако постои, стои во шифрираниот дел. Дизајн што очекува да прочита виртуелен домаќин од надворешниот пакет чита поле што протоколот никогаш не го пишува таму. Тоа доаѓа од начинот на кој е изграден тунелот, а не од празнина што поумно совпаѓање на шаблон би можело да ја затвори.

Каде застанува разделувачот на протоколи

Мултиплексор од видот што го документира проектот sslh слуша на една порта, ги прегледува првите бајти и ја предава врската на оној backend што го зборува препознаениот протокол. Тоа е вистинска вредност кога една порта треба да служи SSH, HTTPS и OpenVPN заедно.

sslh држи посебна сонда за секој протокол, а неговата TLS-сонда може да извлече име на сервер или вредност на ALPN од вистински ClientHello. Препознавањето на стандарден OpenVPN е поинаква класификација од читање на TLS-продолжување, и двете не се составуваат, зашто клиент што никогаш не праќа ClientHello до сокетот за слушање ја остава сондата без ништо за читање. Затоа правило што се совпаѓа со OpenVPN одговара „ова е OpenVPN клиент“ и не оди понатаму. Два OpenVPN backend-а зад тоа правило се неразликливи, предниот дел нема основа за избор, и секоја сесија слетува на истото место. Мултиплексирањето дели една порта меѓу различни услуги; тоа не прави виртуелен хостинг во една услуга.

Распореди што навистина раздвојуваат два сервера

Најевтиното чесно раздвојување е втора јавна адреса, по една на инстанца, а постојните профили веќе го носат потребното зашто покажуваат на различни адреси. Следното е друга порта на истата адреса, што не чини ништо освен еден број во секој профил. TCP и UDP држат одделни таблици на порти, па 1194/tcp и 1194/udp се неповрзани сокети и по еден од секој може да постои на еден домаќин; тоа е транспортно раздвојување, а не рутирање по име, и често се меша со него. Двете опции поминуваат преглед на огнен ѕид, зашто правилото се совпаѓа со нешто што пакетот навистина го содржи.

Ако границата што ви треба оди меѓу групи корисници наместо меѓу две имплементации, една инстанца со различни клиентски конфигурации, сопствено ракување со сертификати и јасна политика за пристап може да го покрие тоа. Она што се купува е политика внатре во сервер, не изолација меѓу сервери, и тоа се различни барања. Изолацијата што мора да издржи под компромитација сè уште бара адресата или работ на огнениот ѕид.

TLS-терминатор поставен пред OpenVPN може да изложи вистинско име на сервер на способен преден дел, но само кога и клиентската страна е конфигурирана за тој дополнителен слој. Постојните профили не го добиваат однесувањето со тоа што се насочени кон истата адреса.

Докажете го избирачот пред да градите

Именувајте го полето што ќе идентификува backend, потоа потврдете дека клиентот навистина го праќа; ако одговорот е адреса, планот стои, а ако е име на сервер во ракување што никогаш не стигнува до слушателот, никаква работа со 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, прочитан на секој backend, покажува која инстанца ја примила сесијата. Предните логови запишуваат што е класифицирано и никогаш што било наменето, па backend-от останува единствениот авторитет за тоа каде слетал корисникот.

Завршете со два профила наменети за различни сервери, поврзете ги еден по еден и забележете го логот на backend-от за секој. Ако двете сесии се појават во истиот journal, избирачот недостига наместо да е погрешно конфигуриран, и поправката е адреса или порта што клиентот може да ја намери. Уредувањето на правилото за рутирање нема да помогне, зашто на правилото никогаш не му било дадено ништо по што да рутира. Кога поделбата ќе стане вистинска, запишете ја покрај профилите за следниот човек да не додаде втор псевдоним и да очекува тој да ја заврши работата.