Twa DNS-nammen, ien OpenVPN-poarte: wat echt selektearret

Twa A-records, ien adres, ien daemon: hokker namme in brûker ek yntypet, it pakket dat oankomt is identyk, en it proses dat oan poarte 1194 bûn is, hat neat om de beide te ûnderskieden. Dat is gjin ferkearde konfiguraasje dy't op reparaasje wachtet; it is de grins fan wat in nammesyksyk útdrukke kin. Alles dat tusken twa OpenVPN-instânsjes kiest, moat in wearde wêze dy't de klient yn 'e ferbining set en dy't it frontend weromlêze kin, en in standert OpenVPN-klient set gjin sa'n wearde yn it iepen. Wat folget is wêr't dat jo lit, en hokker regelingen it ferkear echt skiede.

Begjin mei wat de resolver weromjout

In klient freget vpn-a.example oan en krijt in adres; dat adres plus in poarte is alles wat er opskillet. De namme wurdt lokaal útjûn, by it sykjen, en wurdt nea in fjild op 'e tried, sadat de lústerder oan 'e oare kant net sjen kin hokker label brûkt is. Wys vpn-a.example en vpn-b.example nei ien host, en beide syktochten jouwe deselde bestimming, en dêrom absorbearret de daemon beide ferbiningen yn ien instânsje sûnder ferskil te registrearjen. Adresbasearre profilen gedrage har krekt as nammebasearre, om deselde reden.

Dit slút ek in famylje fan ferloklike omwegen ôf: ekstra aliassen, in sertifikaat per namme op ien socket kieze, of in firewallregel dy't oan 'e frege namme bûn is. Gjin fan dy kin hannelje op ynformaasje dy't al weilitten wie foar't it earste pakket de klient ferliet. As twa servers skieden bliuwe moatte, moat de splitsing mei de ferbining sels reizgje, dat wol sizze in adres, in poarte of in payloaffjild dat it protokol definiearret.

De iennichste selektor dy't telt rydt yn it pakket

HTTP docht dat mei in Host-kop, en TLS mei in servernamme-útwreiding yn 'e ClientHello, en sa betsjinnet ien adres in soad siden efter ien lústerder. Beide wurkje om't it triedprotokol in fersyk foar in spesifike tsjinst draacht. It relevante feit oer OpenVPN is dat gjin fan dy fjilden oanwêzich is yn 'e laach dy't in tuskenlizzende doaze ûndersiket.

Yn in standert regeling bart de TLS-hânskodding dy't it kontrôlekanaal beskermet neidat de bûtenste sesje fêstige is, en wurdt dy deryn ferfierd, sadat in lústerder dy't dy sesje net einige hat, in ûntrochsichtige stream sjocht. Hy kin noch sjen dat dit OpenVPN is, om't de opcode en it ramen yn 'e iepeningsbytes werkenber binne, mar de servernamme, as dy bestiet, sit yn it fersifere diel. In ûntwerp dat ferwachtet in firtuele host út it bûtenste pakket te lêzen, lêst in fjild dat it protokol dêr nea skriuwt. Dat komt fan hoe't de tunnel boud is, net fan in gat dat in slimmer patroanmatch slute koe.

Wêr't in protokolsplitter te koart sjit

In multiplexer fan it soarte dat it sslh-projekt dokumintearret, lústeret op ien poarte, ûndersiket de iepeningsbytes en jout de ferbining oan wa't ek de protokol sprekt dy't er werkenber makke hat. Dat is echte wearde as ien poarte SSH, HTTPS en OpenVPN tagelyk betsjinje moat.

sslh hâldt in aparte probe per protokol, en syn TLS-probe kin in servernamme of in ALPN-wearde út in echte ClientHello helje. Native OpenVPN werkenne is in oare klassifikaasje as in TLS-útwreiding lêze, en de beide gearstalle se net, om't in klient dy't nea in ClientHello nei de lústersocket stjoert, de probe sûnder wat te lêzen lit. In regel dy't by OpenVPN past, antwurdet dêrom “dit is in OpenVPN-klient” en giet net fierder. Twa OpenVPN-backends efter dy regel binne net te ûnderskieden, it frontend hat gjin grûn foar in kar, en elke sesje bedarret op itselde plak. Multiplexing dielt ien poarte oer ferskate tsjinsten; it docht gjin firtuele hosting yn ien tsjinst.

Regelingen dy't twa servers echt skiede

De goedkeapste earlike splitsing is in twadde iepenbier adres, ien per instânsje, en besteande profilen drage al wat nedich is, om't se nei ferskate adressen wize. De folgjende is in oare poarte op itselde adres, wat neat kostet behalve in nûmer yn elk profyl. TCP en UDP hâlde aparte poartetabellen, dus 1194/tcp en 1194/udp binne net besibbe sockets en ien fan elk kin op ien host njonkeninoar bestean; dat is ferfierskieding en gjin nammerûting, en it wurdt dêrfaak mei betize. Beide opsjes oerlibje in firewallbefêstiging, om't de regel past by eat dat it pakket wier befettet.

As de grins dy't jo nedich hawwe tusken groepen brûkers rint ynstee fan tusken twa ymplemintaasjes, kin ien instânsje mei ferskate klientkonfiguraasjes, syn eigen sertifikaatôfhanneling en in eksplisyt tagongsbelied dat dekke. Wat dat keapet is belied yn in server, net isolaasje tusken servers, en dat binne ferskate easken. Isolaasje dy't ûnder kompromittering stean moat, hat noch altyd it adres of de firewallrâne nedich.

In TLS-terminator foar OpenVPN kin in echte servernamme oan in betûft frontend bleatstelle, mar allinnich as de klientside ek foar dy ekstra laach konfigurearre is. Besteande profilen krije it gedrach net troch se nei itselde adres te wizen.

Bewiis de selektor foar't jo bouwe

Nammeseit it fjild dat in backend identifisearje sil, en befêstigje dan dat de klient it wier stjoert; as it antwurd in adres is, hâldt it plan, en as it in servernamme yn in hânskodding is dy't de lústerder nea berikt, sil gjin hoemannichte DNS-wurk it rêde. Trije opdrachten meitsje de lústerkant gau dúdlik.

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

De openssl-rige jout allinnich in sertifikaat wêr't eat op dat adres TLS einige; tsjin in native OpenVPN-lústerder stokket it of mislearret it, en dat is sels it antwurd oer wat de bûtenste laach bleatleit. De journal-rige, lêzen op elke backend, lit sjen hokker instânsje de sesje akseptearre. Frontend-logboeken skriuwe op wat klassifisearre is en nea wat bedoeld wie, sadat de backend de iennichste autoriteit bliuwt oer wêr't in brûker bedarre.

Einigje mei twa profilen bedoeld om ferskate servers te berikken, ferbyn se ien foar ien en notearje it backend-log foar elk. As beide sesjes yn itselde journal ferskine, ûntbrekt de selektor ynstee fan ferkeard konfigurearre te wêzen, en de oplossing is in adres of in poarte dy't de klient rjochtsje kin. It bewurkjen fan 'e rûtingsregel sil net helpe, om't de regel nea eat krigen hat om op te rûten. Sadree't de splitsing echt is, skriuw it njonken de profilen, sadat de folgjende persoan net in twadde alias tafoeget en ferwachtet dat dy it wurk docht.