Clientul dumneavoastră OpenVPN ar trebui să folosească nobind sau un port fix?

Două profiluri care diferă printr-o singură linie se comportă diferit în momentul în care un al doilea client pornește pe același gazdă. Unul poartă nobind și ia orice port local pe care îl dă nucleul; celălalt rezervă 1194, iar a doua instanță moare cu o adresă deja folosită. Acea linie decide cine alege portul sursă, ceea ce la rândul său decide dacă profilul poate coexista cu orice altceva pe mașină. Trei întrebări rezolvă problema, iar prima răspunde pentru majoritatea profilurilor înainte de a ajunge la celelalte două.

Ce omite de fapt nobind

Implicit clientul leagă un socket local înainte de a apela, iar portul local este 1194 dacă profilul nu spune altceva. nobind elimină acea rezervare, așa că stiva alocă un port nefolosit la momentul conexiunii. Este o excepție, nu o valoare implicită, iar un client fără linie păstrează 1194, motiv pentru care o a doua instanță nefixată intră în conflict. Majoritatea profilurilor de client livrate poartă directiva din acest motiv, iar faptul că un fișier exemplu face ceva nu este același lucru cu mecanismul care o face implicit.

Ce nu se schimbă este partea îndepărtată. Serverul ascultă în continuare acolo unde profilul spune că ascultă, iar portul de destinație din configurație rămâne portul de destinație. Un port sursă dinamic schimbă adresa de retur a socketului propriu și nimic din cea a serverului.

De asemenea, nu ascunde nimic. Adresa dumneavoastră publică este ceea ce calea o traduce, pachetul traversează în continuare rețeaua locală, iar cine administrează acea rețea vede în continuare un flux. nobind nu este nici funcție de confidențialitate, nici ocolire a paravanului.

Trei condiții care o decid

O întrebare le decide pe celelalte două, așa că răspundeți la ea înainte de a edita ceva. Dacă partenerul se conectează în exterior, celelalte întrebări doar rafinează o decizie deja luată. Dacă acceptă conexiuni de intrare, nicio ajustare a portului local nu îl face accesibil.

Acest partener inițiază conexiunea? Dacă se conectează în exterior, un port sursă dinamic este inofensiv și de obicei preferabil, pentru că răspunsul urmează același flux înapoi. Dacă așteaptă conexiuni de intrare, un port dinamic îl face inaccesibil dacă ceva din față nu publică portul. Acel singur răspuns separă fiecare profil de client de fiecare profil de server.

Calea filtrează după portul sursă? O regulă strictă scrisă pentru un port cunoscut impune un port local explicit, iar profilul ar trebui să noteze ce regulă îndeplinește. Majoritatea rețelelor filtrează doar după destinație, așa că această condiție este mai rară decât prima. Unde se aplică, ea prevalează asupra preferinței pentru un port dinamic.

Mai multe instanțe împart gazda? Un singur port fix nu poate deservi două dintre ele, iar o instanță repornită poate găsi 1194 încă în stare de închidere. Porturile dinamice elimină acel conflict fără a schimba nimic altceva. Dacă nu puteți răspunde cu încredere, presupuneți că da și lăsați nucleul să aleagă.

Unde un port fixat este răspunsul corect

Unele rețele filtrează atât după portul sursă, cât și după destinație, așa că un operator poate fi scris o regulă care lasă să treacă doar traficul dintr-un port cunoscut. Fixarea portului local este atunci corectă, iar profilul ar trebui să poarte un comentariu care numește regula îndeplinită. Fixarea pentru simetrie cu portul serverului nu este un motiv, pentru că cele două numere nu au nimic de-a face unul cu celălalt. Dacă fixarea există doar pentru că un șablon o avea, ștergeți-o.

Altfel, un port fixat cumpără necazuri: doi clienți pe o singură mașină nu pot ține amândoi 1194, iar al doilea eșuează cu o eroare care indică portul, nu profilul. Un container care repornește rapid lovește același zid. Reparația este directiva pe care profilurile livrate o conțineau deja.

Serverul și clientul nu sunt simetrice

manualul OpenVPN 2.6 așază nobind lângă lport, ceea ce este argumentul într-o singură linie: o opțiune spune că alege nucleul, cealaltă spune că alegeți dumneavoastră. Un port local dinamic funcționează doar pentru partenerul care apelează, pentru că partea care răspunde nu poate cunoaște portul dinainte. De aceea copierea unui profil de client pe un server produce un ascultător la care nimeni nu poate ajunge.

Pe o gazdă cu mai multe interfețe de rețea, adresa este o decizie separată de port. Legarea unei adrese locale anume și legarea unui port anume sunt două setări diferite, iar un server cu două legături ascendente fixează de obicei ambele. Un client care le fixează pe ambele a preluat aceeași rigiditate fără niciun beneficiu.

Rezumatul este despre roluri, nu despre securitate: cine apelează poate fi flexibil în privința propriei surse, iar cine răspunde nu poate. Niciuna dintre alegeri nu schimbă ce află cealaltă parte despre identitatea dumneavoastră. De aceea directiva apare în exemplele de client și aproape niciodată în cele de server.

Verificați portul ales de nucleu

După conectare, citiți socketul și nu configurația, pentru că configurația declară intenția, iar socketul declară ce s-a întâmplat. Faptele care merită notate sunt portul local, punctul final îndepărtat și dacă ceva mai ascultă. Pe o gazdă Linux toate trei sunt la o comandă distanță.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

Un client cu nobind afișează un port local înalt și portul îndepărtat configurat, ceea ce este forma așteptată. Un server afișează un socket care ascultă pe portul său configurat, iar dacă acel socket lipsește, profilul fie nu este un ascultător, fie nu a reușit să lege. Când există un flux dar pachetele nu se întorc, comparați portul sursă ales cu orice filtru de porturi de pe cale înainte de a edita profilul. Schimbați un lucru, reconectați-vă și citiți socketul din nou.