Ar kiekvienam OpenVPN peerui reikia remote eilutės? Ne visai

Dvi peer konfigūracijos lyginamos greta, vienoje yra remote eilutė, kitoje – ne, ir išvada tokia, kad viena iš jų sulaužyta. Ši išvada pakankamai dažnai klaidinga, kad verta ją išardyti. Direktyva aprašo, kur reikia siųsti pirmąjį paketą. Ji nepasirenka, ar procesas veikia kaip inicijuojantis klientas, ar kaip laukianti vartų sistema, ir nenusprendžia, kuri pusė įrodo savo tapatybę kitai.

Ką remote iš tikrųjų nustato

remote įrašas nurodo mazgą, pasirinktinai prievadą ir transportą, ir pasirinktinai kelis tokius įrašus, kurie bandomi iš eilės.

Jo nebuvimas turi apibrėžtą, o ne neapibrėžtą reikšmę: procesas laukia ir nereaguoja į paketus iš adreso, nebent tas peer autentifikuojasi. Todėl vartų sistema, aptarnaujanti keliaujančius naudotojus, neturi priežasties iš anksto įvardyti nė vieno iš jų.

Skaitykite įrašą kaip adresų santykį. Ar tolimajam galui galima pasitikėti, atsako sertifikatai ir tikrinimo parinktys, o ne tai, kad adresas buvo užrašytas.

Atsakymą lemia trys išdėstymai

Keliaujančiam klientui reikia paskirties, nes jis turi inicijuoti ir be jos nežino, kur yra vartai. Daugelio klientų vartams nereikia paskirties kiekvienam naudotojui, nes klientai atvyksta ir autentifikuojasi. Sąmoninga dviejų peerų jungtis su žinomais galais gali turėti paskirtį vienoje pusėje, abiejose arba nė vienoje, priklausomai nuo to, kuri pusė inicijuoja.

Fiksuoto kliento adreso įklijavimas į bendrus vartus yra klaida, kylanti iš tų kategorijų ignoravimo. Ji veikia tam vieninteliam peerui, kurio adresas buvo užregistruotas, ir klaidina visus kitus.

Niekas direktyvoje nepaverčia konfigūracijos daugelio klientų serveriu, ir niekas jos buvime netrukdo serverio vaidmeniui. OpenVPN 2.6 žinynas atskirai dokumentuoja pasirinktinius argumentus ir elgseną be remote, o tai užuomina apie tai, kiek jie nepriklausomi.

Transporto vaidmenys yra kita ašis

TCP atveju viena pusė laukia, o kita skambina. Tai atskiros direktyvos nuo paskirties, o jas sumaišius gaunama pora, kurioje abi laukia arba abi skambina.

Yra ir TCP šaltinio filtro vaidmuo, todėl plokščias teiginys, kad serveris niekada negali turėti remote, yra klaidingas.

UDP atveju nėra ryšio, kurį reikėtų užmegzti, todėl abu galai naudoja atitinkamą UDP transportą, o direktyva tik nurodo, kur taikytis. Autentifikuoto peer adreso pakeitimus tvarko speciali elgsena, o ne papildomų įrašų pridėjimas. Teisingas transportas yra sąlyga, kad paskirtis ką nors reikštų, o sumaišius abu gaunamos konfigūracijos, kurios atrodo įtikinamai ir niekada neužbaigia rankos paspaudimo.

Kodėl nebuvimas remote nėra atviros durys

Procesas be paskirties vis tiek atmeta srautą iš peerų, kurie nesitvirtina, ir tai ta dalis, kurią žmonės praleidžia, kai trūkstamą eilutę skaito kaip klausytoją, atvirą visiems.

Autentifikavimas ir paskirtis yra nepriklausomi, o pirmasis yra tas, kuris svarbus pasitikėjimui.

Atvirkštinė klaida pavojingesnė. Fiksuotas šaltinio adresas gali atrodyti kaip prieigos kontrolė, nes jis konkretus ir lengvai tikrinamas, bet jis nieko neįrodo apie tai, kas yra kitame gale. Išlaikykite sertifikatų tikrinimą ir tapatybės patikras, kurios sieja sertifikatą su jo vaidmeniu. Pakeisti jas adresų sutapimu reiškia iškeisti tikrą kontrolę į jos išvaizdą.

Užrašykite, ką konfigūracija daro prielaidą

Kiekvienai pusei užrašykite tris dalykus: kaip pirmasis paketas pasiekia peerą, kuri pusė gali priimti transportą ir ką kiekviena pusė tikrina apie kitą.

Tos prielaidos ir yra dizainas. Direktyvos tėra jų rašyba.

Jei du failai skiriasi, patikrinkite, ar jie išreiškia skirtingas prielaidas, o ne manykite, kad vienas yra klaidingas. Simetriška failų pora nėra nei būtina, nei pakankama veikiančiam tuneliui, o asimetrija dažnai yra ta dalis, kuri leidžia topologijai veikti.