Are fiecare peer OpenVPN nevoie de o linie remote? Nu chiar
remote indică unde merge primul pachet; nu alege rolul de client, server sau TLS. Citiți aranjamentul înainte de a-l copia pe ambele părți.
Două configurații de peer sunt comparate alături, una are o linie remote și cealaltă nu, iar concluzia este că una dintre ele este stricată. Această inferență este greșită suficient de des încât să merite analizată. Directiva descrie unde trebuie trimis primul pachet. Nu selectează dacă procesul acționează ca un client care inițiază sau ca o poartă care așteaptă și nu decide care parte își dovedește identitatea celeilalte.
Ce specifică de fapt remote
O intrare remote numește un host, opțional un port și un transport, și opțional mai multe astfel de intrări încercate în ordine.
Absența ei are un sens definit, nu nedefinit: procesul așteaptă și nu acționează asupra pachetelor de la o adresă decât dacă acel peer se autentifică. Prin urmare, o poartă care deservește utilizatori în roaming nu are niciun motiv să numească vreunul dintre ei în avans.
Citiți intrarea ca o relație de adrese. Dacă se are încredere în capătul îndepărtat răspund certificatele și opțiunile de verificare, nu faptul că s-a scris o adresă.
Trei aranjamente decid răspunsul
Un client în roaming are nevoie de o destinație, pentru că trebuie să inițieze și fără ea nu știe unde este poarta. O poartă pentru mulți clienți nu are nevoie de destinație pe utilizator, pentru că clienții sosesc și se autentifică. O legătură deliberată între doi peers cu capete cunoscute poate avea destinație pe o parte, pe ambele sau pe niciuna, în funcție de partea care inițiază.
Lipirea unei adrese fixe de client într-o poartă generală este greșeala care decurge din ignorarea acelor categorii. Funcționează pentru singurul peer a cărui adresă a fost înregistrată și îi induce în eroare pe toți ceilalți.
Nimic din directivă nu transformă o configurație într-un server pentru mulți clienți, iar nimic din prezența ei nu împiedică un rol de server. Referința OpenVPN 2.6 documentează separat argumentele opționale și comportamentul fără remote, ceea ce este un indiciu despre cât de independente sunt.
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
Rolurile de transport sunt altă axă
În TCP o parte așteaptă, iar cealaltă stabilește conexiunea. Sunt directive separate de destinație, iar amestecarea lor produce o pereche în care ambele așteaptă sau ambele stabilesc conexiunea.
Există și un rol de filtru de sursă TCP, motiv pentru care afirmația plată că un server nu poate conține niciodată remote este greșită.
În UDP nu există conexiune de stabilit, așa că ambele capete folosesc transportul UDP corespunzător, iar directiva spune doar unde să țintești. Schimbările de adresă ale unui peer autentificat sunt tratate de un comportament dedicat, nu prin adăugarea mai multor intrări. Transportul corect este o condiție prealabilă pentru ca destinația să însemne ceva, iar confundarea celor două produce configurații care par plauzibile și nu finalizează niciodată un handshake.
De ce un remote absent nu este o ușă deschisă
Un proces fără destinație refuză în continuare traficul de la peers care nu se autentifică, iar aceasta este partea pe care oamenii o ratează când citesc linia absentă ca un ascultător deschis pentru oricine.
Autentificarea și destinația sunt independente, iar prima este cea care contează pentru încredere.
Eroarea inversă este mai periculoasă. O adresă de sursă fixă poate părea un control de acces pentru că este specifică și ușor de verificat, dar nu dovedește nimic despre cine este la celălalt capăt. Păstrați verificarea certificatelor și verificările de identitate care leagă un certificat de rolul său. Înlocuirea lor cu o potrivire de adresă schimbă un control real pe aparența lui.
Notați ce presupune configurația
Pentru fiecare parte, notați trei lucruri: cum ajunge primul pachet la peer, care parte poate accepta transportul și ce verifică fiecare parte despre cealaltă.
Acele presupuneri sunt proiectarea. Directivele sunt doar ortografia lor.
Dacă cele două fișiere diferă, verificați dacă exprimă presupuneri diferite în loc să presupuneți că unul este greșit. O pereche simetrică de fișiere nu este nici necesară, nici suficientă pentru un tunel funcțional, iar asimetria este adesea partea care face o topologie să funcționeze.