Divi DNS vārdi, viens OpenVPN ports: kas patiešām izvēlas
Divi resursdatora vārdi, kas norāda uz vienu adresi, joprojām nonāk pie viena klausītāja. Tik klienta sūtītais lauks var izvēlēties backend, un standarta OpenVPN tādu nesūta.
Divi A ieraksti, viena adrese, viens dēmons: lai kādu vārdu lietotājs ievadītu, pienākošā pakete ir identiska, un procesam, kas piesaistīts portam 1194, nav ar ko abus atšķirt. Tā nav kļūdaina konfigurācija, kas gaida labojumu; tā ir robeža tam, ko var izteikt vārda meklējums. Viss, kas izvēlas starp divām OpenVPN instancēm, ir jābūt vērtībai, ko klients ievieto savienojumā un ko priekšgals var nolasīt atpakaļ, un standarta OpenVPN klients šādu vērtību atklāti neievieto. Tālāk ir par to, kur tas jūs atstāj, un kuri izkārtojumi patiešām sadala satiksmi.
Sāciet ar to, ko atgriež atrisinātājs
Klients jautā par vpn-a.example un saņem adresi; šī adrese plus ports ir viss, uz ko tas zvana. Vārds tiek iztērēts lokāli, meklējuma laikā, un tas nekad nekļūst par lauku uz vada, tāpēc klausītājs otrā galā nevar redzēt, kura etiķete tika izmantota. Novirziet vpn-a.example un vpn-b.example uz vienu resursdatoru, un abi meklējumi dos vienu un to pašu galamērķi, tāpēc dēmons abus savienojumus iesūc vienā instancē, nereģistrējot atšķirību. Uz adresi balstīti profili uzvedas tieši tāpat kā uz vārdu balstīti, tā paša iemesla dēļ.
Tas arī aizver vilinošu apiešanas paņēmienu saimi: papildu aizstājvārdi, sertifikāta izvēle katram vārdam vienā ligzdā vai ugunsmūra noteikums, kas piesaistīts vaicātajam vārdam. Neviens no tiem nevar darboties ar informāciju, kas jau bija izmesta, pirms pirmā pakete atstāja klientu. Ja diviem serveriem jāpaliek atsevišķiem, sadalījumam jāceļo kopā ar pašu savienojumu, tas nozīmē adresi, portu vai lietderīgās kravas lauku, ko definē protokols.
Vienīgais skaitāmais atlasītājs brauc paketes iekšpusē
HTTP to risina ar Host galveni, bet TLS ar servera vārda paplašinājumu ClientHello, un tā viena adrese apkalpo daudzas vietnes aiz viena klausītāja. Abi darbojas tāpēc, ka vada protokols nes pieprasījumu konkrētam pakalpojumam. Būtiskais fakts par OpenVPN ir tāds, ka neviens no šiem laukiem nav slānī, kuru pārbauda starpniekierīce.
Standarta izkārtojumā TLS rokasspiediens, kas aizsargā vadības kanālu, notiek pēc ārējās sesijas izveides un tiek pārnests tās iekšienē, tāpēc klausītājs, kas to sesiju nav pabeidzis, redz necaurspīdīgu plūsmu. Tas joprojām var pateikt, ka tas ir OpenVPN, jo sākuma baitu opkods un kadrējums ir atpazīstami, bet servera vārds, ja tāds ir, atrodas šifrētajā daļā. Dizains, kas cer nolasīt virtuālo resursdatoru no ārējās paketes, lasa lauku, ko protokols tur nekad neraksta. Tas izriet no tā, kā tunelis ir uzbūvēts, nevis no spraugas, ko varētu aizvērt gudrāka modeļa saskaņošana.
Kur protokola sadalītājs apstājas
Multipleksors tāda veida, kādu dokumentē sslh projekts, klausās vienā portā, pārbauda sākuma baitus un nodod savienojumu tam backend, kas runā atpazītajā protokolā. Tā ir reāla vērtība, kad vienam portam vienlaikus jāapkalpo SSH, HTTPS un OpenVPN.
sslh tur atsevišķu zondi katram protokolam, un tā TLS zonde var izvilkt servera vārdu vai ALPN vērtību no īsta ClientHello. Standarta OpenVPN atpazīšana ir cita klasifikācija nekā TLS paplašinājuma lasīšana, un abi nesavienojas, jo klients, kas nekad nesūta ClientHello uz klausošo ligzdu, atstāj zondi bez nekā lasāma. Tāpēc noteikums, kas atbilst OpenVPN, atbild „šis ir OpenVPN klients“ un tālāk neiet. Divi OpenVPN backend aiz šī noteikuma nav atšķirami, priekšgalam nav pamata izvēlei, un katra sesija nonāk vienā vietā. Multipleksēšana dala vienu portu starp dažādiem pakalpojumiem; tā neveic virtuālo mitināšanu vienā pakalpojumā.
Izkārtojumi, kas patiešām sadala divus serverus
Lētākais godīgais sadalījums ir otra publiskā adrese, viena uz instanci, un esošie profili jau nes nepieciešamo, jo norāda uz dažādām adresēm. Nākamais ir cits ports tajā pašā adresē, kas neizmaksā neko vairāk par skaitli katrā profilā. TCP un UDP tur atsevišķas portu tabulas, tāpēc 1194/tcp un 1194/udp ir nesaistītas ligzdas un pa vienai no katras var pastāvēt vienā resursdatorā; tas ir transporta sadalījums, nevis maršrutēšana pēc vārda, un to bieži ar to jauc. Abi varianti iztur ugunsmūra pārskatu, jo noteikums atbilst kaut kam, kas paketē patiešām ir.
Ja nepieciešamā robeža iet starp lietotāju grupām, nevis starp divām implementācijām, to var noklāt viena instance ar atšķirīgām klienta konfigurācijām, savu sertifikātu apstrādi un skaidru piekļuves politiku. Tas pērk politiku servera iekšienē, nevis izolāciju starp serveriem, un tās ir dažādas prasības. Izolācijai, kurai jāiztur kompromitēšana, joprojām vajadzīga adrese vai ugunsmūra mala.
OpenVPN priekšā novietots TLS terminators var atklāt īstu servera vārdu spējīgam priekšgalam, bet tikai tad, ja arī klienta puse ir konfigurēta šim papildu slānim. Esošie profili neiegūst šo uzvedību tikai ar novirzīšanu uz to pašu adresi.
Pierādiet atlasītāju pirms būvēšanas
Nosauciet lauku, kas identificēs backend, pēc tam apstipriniet, ka klients to patiešām sūta; ja atbilde ir adrese, plāns pastāv, un ja tas ir servera vārds rokasspiediena iekšienē, kas nekad nesasniedz klausītāju, nekāds DNS darbs to neglābs. Trīs komandas ātri izšķir klausīšanās pusi.
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 rinda dod sertifikātu tikai tur, kur kaut kas šajā adresē pabeidz TLS; pret standarta OpenVPN klausītāju tā iestrēgst vai neizdodas, un tas pats par sevi ir atbilde par to, ko atklāj ārējais slānis. journal rinda, nolasīta katrā backend, parāda, kura instance pieņēma sesiju. Priekšgala žurnāli fiksē to, kas tika klasificēts, un nekad to, kas bija paredzēts, tāpēc backend paliek vienīgā instance, kas zina, kur lietotājs nolaidās.
Pabeidziet ar diviem profiliem, kas paredzēti dažādu serveru sasniegšanai, savienojiet tos pa vienam un pierakstiet katra backend žurnālu. Ja abas sesijas parādās tajā pašā žurnālā, atlasītāja trūkst, nevis tas ir nepareizi konfigurēts, un labojums ir adrese vai ports, uz kuru klients var mērķēt. Maršrutēšanas noteikuma rediģēšana nepalīdzēs, jo noteikumam nekad netika dots nekas, pēc kā maršrutēt. Kad sadalījums ir reāls, pierakstiet to blakus profiliem, lai nākamais cilvēks nepievienotu otru aizstājvārdu un negaidītu, ka tas veiks darbu.