Dalawang pangalan ng DNS, isang port ng OpenVPN: ano talaga ang pumipili

Dalawang A record, isang address, isang daemon: anuman ang pangalang itayp ng gumagamit, ang packet na dumarating ay pareho, at ang prosesong nakatali sa port 1194 ay walang anumang maipagkakaiba sa dalawa. Hindi ito maling configuration na naghihintay ng pag-aayos; ito ang hangganan ng kayang ipahayag ng paghahanap ng pangalan. Anumang pumipili sa pagitan ng dalawang instance ng OpenVPN ay dapat na halagang inilalagay ng kliyente sa koneksyon at kayang basahin pabalik ng harapan, at ang karaniwang kliyente ng OpenVPN ay walang inilalagay na gayong halaga nang hayagan. Ang sumusunod ay kung saan ka nito iniiwan, at kung aling mga kaayusan ang tunay na naghahati sa trapiko.

Magsimula sa ibinabalik ng resolver

Nagtatanong ang kliyente para sa vpn-a.example at tumatanggap ng address; ang address na iyon at isang port ang lahat ng dinidial nito. Nagagamit ang pangalan nang lokal, habang naghahanap, at hindi ito kailanman nagiging field sa kawad, kaya hindi makikita ng tagapakinig sa kabilang dulo kung aling label ang ginamit. Ituro ang vpn-a.example at vpn-b.example sa isang host at parehong destinasyon ang ibibigay ng dalawang paghahanap, kaya sinisipsip ng daemon ang dalawang koneksyon sa isang instance nang hindi nagtatala ng pagkakaiba. Ang mga profile na nakabatay sa address ay kumikilos nang eksakto tulad ng mga nakabatay sa pangalan, sa parehong dahilan.

Isinasara rin nito ang isang pamilya ng mga nakakaakit na paraan: karagdagang alias, pagpili ng sertipiko para sa bawat pangalan sa isang socket, o patakaran ng firewall na nakakabit sa itinanong pangalan. Wala sa mga ito ang makakagalaw sa impormasyong itinapon na bago pa man umalis ang unang packet sa kliyente. Kung kailangang manatiling hiwalay ang dalawang server, dapat sumama ang paghahati sa mismong koneksyon, ibig sabihin ay address, port, o field ng payload na tinutukoy ng protocol.

Ang tanging pumipili na binibilang ay sumasakay sa loob ng packet

Pinangangasiwaan ito ng HTTP sa pamamagitan ng header na Host, at ng TLS sa pamamagitan ng extension ng pangalan ng server sa ClientHello, at sa gayon isang address ang naglilingkod sa maraming site sa likod ng isang tagapakinig. Gumagana ang dalawa dahil may dalang kahilingan ang protocol sa kawad para sa isang partikular na serbisyo. Ang kaugnay na katotohanan tungkol sa OpenVPN ay wala sa alinmang field na iyon ang naroroon sa layer na sinisiyasat ng pantulong na kahon.

Sa karaniwang kaayusan, ang pakikipagkamay ng TLS na nagpoprotekta sa channel ng kontrol ay nangyayari pagkatapos maitatag ang panlabas na session at dinadala ito sa loob nito, kaya ang tagapakinig na hindi pa natapos ang session na iyon ay nakakakita ng malabong daloy. Masasabi pa rin nitong OpenVPN ito, dahil nakikilala ang opcode at pag-frame sa mga unang byte, ngunit ang pangalan ng server, kung mayroon, ay nakaupo sa naka-encrypt na bahagi. Ang disenyong umaasa na makabasa ng virtual host mula sa panlabas na packet ay nagbabasa ng field na hindi kailanman isinusulat ng protocol doon. Nagmumula ito sa kung paano itinayo ang tunnel, hindi sa puwang na kayang sarhan ng mas matalinong pagtutugma ng pattern.

Saan humihinto ang tagahati ng protocol

Ang multiplexer ng uring dokumentado ng proyektong sslh ay nakikinig sa isang port, sinisiyasat ang mga unang byte, at ibinibigay ang koneksyon sa alinmang backend na nagsasalita ng nakilalang protocol. Tunay na halaga iyon kapag isang port lang ang kailangang maglingkod sa SSH, HTTPS at OpenVPN nang sabay.

May hiwalay na pagsisiyasat ang sslh para sa bawat protocol, at ang pagsisiyasat nito sa TLS ay makakakuha ng pangalan ng server o halaga ng ALPN mula sa tunay na ClientHello. Ang pagkilala sa native na OpenVPN ay ibang klasipikasyon kaysa pagbasa ng extension ng TLS, at hindi nagsasama ang dalawa, dahil ang kliyenteng hindi kailanman nagpapadala ng ClientHello sa socket na nakikinig ay nag-iiwan sa pagsisiyasat na walang mababasa. Kaya ang patakarang tumutugma sa OpenVPN ay sumasagot ng “kliyente ito ng OpenVPN” at hindi na lumalayo pa. Ang dalawang backend ng OpenVPN sa likod ng patakarang iyon ay hindi makikilala, walang batayan ang harapan para pumili, at bawat session ay dumadapo sa parehong lugar. Ang multiplexing ay naghahati ng isang port sa iba't ibang serbisyo; hindi ito gumagawa ng virtual hosting sa loob ng isang serbisyo.

Mga kaayusang tunay na naghihiwalay sa dalawang server

Ang pinakamurang tapat na paghahati ay ang ikalawang pampublikong address, isa sa bawat instance, at may dala na ang mga umiiral na profile ng kailangan dahil nakaturo sila sa magkaibang address. Ang susunod ay ibang port sa parehong address, na walang gastos maliban sa isang numero sa bawat profile. May hiwalay na talahanayan ng port ang TCP at UDP, kaya ang 1194/tcp at 1194/udp ay walang kaugnayang socket at isa sa bawat isa ay maaaring magkasamang umiral sa isang host; paghahati iyon ng transportasyon at hindi routing ayon sa pangalan, at madalas itong napagkakamalan. Parehong lumalagpas ang dalawang opsyon sa pagsusuri ng firewall, dahil tumutugma ang patakaran sa isang bagay na talagang nilalaman ng packet.

Kung ang hangganang kailangan mo ay dumadaan sa pagitan ng mga grupo ng gumagamit sa halip na sa pagitan ng dalawang implementasyon, kayang saklawin iyon ng isang instance na may magkaibang configuration ng kliyente, sariling paghawak ng sertipiko at malinaw na patakaran sa pag-access. Ang nabibili niyon ay patakaran sa loob ng isang server, hindi paghihiwalay sa pagitan ng mga server, at magkaibang pangangailangan ang dalawa. Ang paghihiwalay na dapat tumayo sa ilalim ng kompromiso ay nangangailangan pa rin ng address o gilid ng firewall.

Ang tagapagtapos ng TLS na inilagay sa harap ng OpenVPN ay makapagbubunyag ng tunay na pangalan ng server sa isang mahusay na harapan, ngunit kapag naka-configure din ang panig ng kliyente para sa karagdagang layer na iyon. Hindi nakukuha ng mga umiiral na profile ang gawi na iyon sa pamamagitan lamang ng pagturo sa parehong address.

Patunayan ang pumipili bago magtayo

Pangalanan ang field na makikilala sa isang backend, pagkatapos ay tiyakin na talagang ipinapadala ito ng kliyente; kung address ang sagot, tumatayo ang plano, at kung pangalan ng server ito sa loob ng pakikipagkamay na hindi kailanman nakakarating sa tagapakinig, walang gawaing DNS ang makakapagligtas nito. Tatlong utos ang mabilis na nagpapasya sa panig na nakikinig.

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

Ang linyang openssl ay nagbibigay ng sertipiko lamang kung saan may nagtatapos ng TLS sa address na iyon; laban sa native na tagapakinig ng OpenVPN ito ay natigil o nabigo, at iyon mismo ang sagot sa kung ano ang ibinubunyag ng panlabas na layer. Ang linyang journal, na binabasa sa bawat backend, ay nagpapakita kung aling instance ang tumanggap ng session. Ang mga log ng harapan ay nagtatala ng inuri at hindi kailanman ng nilayon, kaya ang backend pa rin ang tanging awtoridad sa kung saan dumapo ang gumagamit.

Tapusin sa dalawang profile na nilayong makarating sa magkaibang server, ikonekta ang mga ito nang isa-isa at itala ang log ng backend para sa bawat isa. Kung kapwa lumitaw ang dalawang session sa parehong journal, nawawala ang pumipili at hindi mali ang configuration, at ang pagwawasto ay isang address o port na kayang puntiryahin ng kliyente. Hindi makakatulong ang pag-edit ng patakaran sa routing, dahil kailanman ay walang ibinigay na anumang iruruta sa patakaran. Kapag tunay na ang paghahati, isulat ito sa tabi ng mga profile upang ang susunod na tao ay hindi magdagdag ng ikalawang alias at umasang ito ang gagawa ng trabaho.