Moet jou OpenVPN-kliënt nobind of 'n vaste poort gebruik?

Twee profiele wat met 'n enkele reël verskil, gedra hulle anders sodra 'n tweede kliënt op dieselfde gasheer begin. Die een dra nobind en neem enige plaaslike poort wat die kernel uitdeel; die ander reserveer 1194, en die tweede instansie faal met 'n adres wat reeds in gebruik is. Daardie reël bepaal wie die bronpoort kies, wat weer bepaal of die profiel saam met enigiets anders op die masjien kan bestaan. Drie vrae besleg dit, en die eerste beantwoord die meeste profiele voordat jy by die ander twee uitkom.

Wat nobind werklik oorslaan

Standaard bind die kliënt 'n plaaslike sok voor dit uitbel, en die plaaslike poort is standaard 1194 tensy die profiel anders sê. nobind verwyder daardie reservering, so die stapel ken 'n ongebruikte poort tydens verbinding toe. Dit is 'n uitsluiting eerder as 'n standaard, en 'n kliënt sonder die reël hou 1194, wat presies is waarom 'n onvasgepen tweede instansie bots. Die meeste kliëntprofiele wat verskeep word, dra die opdrag om daardie rede, en 'n voorbeeldlêer wat iets doen is nie dieselfde as dat die meganisme dit verstek maak nie.

Wat nie verander nie, is die ander kant. Die bediener luister steeds waar die profiel sê hy luister, en die bestemmingspoort in die konfigurasie is steeds die bestemmingspoort. 'n Dinamiese bronpoort verander die terugkeeradres van jou eie sok en niks aan dié van die bediener nie.

Dit verberg ook niks. Jou openbare adres is wat die pad daarvan maak, die pakket steek steeds die plaaslike netwerk oor, en wie daardie netwerk bestuur sien steeds 'n stroom. nobind is nóg 'n privaatheidfunksie nóg 'n omseiling van die firewall.

Drie voorwaardes wat dit beslis

Een vraag beslis die ander twee, so beantwoord dit voordat jy enigiets wysig. As die eweknie uitbel, verfyn die oorblywende vrae net 'n besluit wat reeds geneem is. As dit inkomende verbindings aanvaar, maak geen hoeveelheid plaaslike-poortinstelling dit bereikbaar nie.

Begin hierdie eweknie die verbinding? As dit uitbel, is 'n dinamiese bronpoort onskadelik en gewoonlik verkieslik, want die antwoord volg dieselfde stroom terug. As dit op inkomende verbindings wag, maak 'n dinamiese poort dit onbereikbaar tensy iets voor dit die poort publiseer. Daardie een antwoord skei elke kliëntprofiel van elke bedienerprofiel.

Filtreer die pad op bronpoort? 'n Streng reël wat vir een bekende poort geskryf is, dwing 'n eksplisiete plaaslike poort, en die profiel moet aanteken watter reël dit bevredig. Die meeste netwerke filtreer net op bestemming, so hierdie voorwaarde is skaarser as die eerste. Waar dit wel geld, oorheers dit die voorkeur vir 'n dinamiese poort.

Deel verskeie instansies die gasheer? Een vaste poort kan nie twee van hulle bedien nie, en 'n herbegin instansie kan 1194 steeds in 'n sluitende toestand vind. Dinamiese poorte verwyder daardie konflik sonder om enigiets anders te verander. As jy hierdie een nie met sekerheid kan antwoord nie, neem aan ja en laat die kernel kies.

Waar 'n vasgepen poort die regte antwoord is

Sommige netwerke filtreer op bronpoort sowel as bestemming, so 'n operateur het dalk 'n reël geskryf wat net verkeer van een bekende poort deurlaat. Om die plaaslike poort vas te pen is dan korrek, en die profiel moet 'n opmerking dra wat die reël noem wat dit bevredig. Vaspen vir simmetrie met die bedienerpoort is nie 'n rede nie, want die twee getalle het niks met mekaar te doen nie. As die vaspenning net bestaan omdat 'n sjabloon dit gehad het, verwyder dit.

Anders koop 'n vasgepen poort moeilikheid: twee kliënte op een masjien kan nie albei 1194 hou nie, en die tweede een faal met 'n fout wat na die poort wys eerder as na die profiel. 'n Houer wat vinnig herbegin, tref dieselfde muur. Die herstelling is die opdrag wat die verskeepte profiele reeds bevat het.

Bediener en kliënt is nie simmetries nie

OpenVPN 2.6-handleiding plaas nobind langs lport, wat die argument in een reël is: een opsie sê die kernel kies, die ander sê jy doen dit. 'n Dinamiese plaaslike poort werk net vir die eweknie wat uitbel, want die antwoordende kant kan nie die poort vooraf weet nie. Dis waarom die kopiëring van 'n kliëntprofiel na 'n bediener 'n luisteraar lewer wat niemand kan bereik nie.

Op 'n gasheer met verskeie netwerkaansluitings is die adres 'n aparte besluit van die poort. Om 'n spesifieke plaaslike adres te bind en om 'n spesifieke poort te bind is twee verskillende instellings, en 'n bediener met twee opwaartse skakels pen gewoonlik albei vas. 'n Kliënt wat albei vaspen, het dieselfde rigiditeit aangeneem sonder enige voordeel.

Die samevatting gaan oor rolle eerder as sekuriteit: wie uitbel kan buigsaam wees oor sy eie bron, en wie antwoord kan nie. Nie een keuse verander wat die ander kant oor jou identiteit leer nie. Dis ook waarom die opdrag in kliëntvoorbeelde opduik en byna nooit in bedienerprofiele nie.

Verifieer die poort wat die kernel gekies het

Lees ná verbinding die sok eerder as die konfigurasie, want die konfigurasie stel die bedoeling en die sok stel wat gebeur het. Die feite wat die moeite werd is om aan te teken, is die plaaslike poort, die afgeleë eindpunt, en of enigiets nog luister. Op 'n Linux-gasheer is al drie een opdrag weg.

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

'n Kliënt met nobind wys 'n hoë plaaslike poort en die gekonfigureerde afgeleë poort, wat die verwagte vorm is. 'n Bediener wys 'n luisterende sok op sy gekonfigureerde poort, en as daardie sok ontbreek, is die profiel óf nie 'n luisteraar nie óf het versuim om te bind. Wanneer 'n stroom bestaan maar geen pakkette terugkom nie, vergelyk die gekose bronpoort met enige poortfilter op die pad voordat jy die profiel wysig. Verander een ding, herverbind, en lees die sok weer.