Bör din OpenVPN-klient använda nobind eller en fast port?

Två profiler som skiljer sig på en enda rad beter sig olika i samma stund som en andra klient startar på samma värd. Den ena bär nobind och tar vilken lokal port som helst som kärnan tilldelar; den andra reserverar 1194, och den andra instansen dör med en adress som redan används. Den raden avgör vem som väljer källporten, vilket i sin tur avgör om profilen kan samexistera med något annat på maskinen. Tre frågor avgör saken, och den första svarar för de flesta profiler innan du når de två andra.

Vad nobind egentligen hoppar över

Som standard binder klienten en lokal socket innan den ringer ut, och den lokala porten är 1194 om inte profilen säger annat. nobind tar bort den reservationen, så stacken tilldelar en oanvänd port vid anslutningen. Det är ett undantag, inte ett standardvärde, och en klient utan raden håller 1194, vilket är precis varför en icke-låst andra instans kolliderar. De flesta levererade klientprofiler bär direktivet av det skälet, och att en exempelfil gör något är inte samma sak som att mekanismen gör det som standard.

Det som inte ändras är den bortre sidan. Servern lyssnar fortfarande där profilen säger att den lyssnar, och målporten i konfigurationen är fortfarande målporten. En dynamisk källport ändrar returadressen för din egen socket och ingenting hos serverns.

Den döljer inte heller något. Din offentliga adress är det som vägen översätter den till, paketet korsar fortfarande det lokala nätet, och den som driver nätet ser fortfarande ett flöde. nobind är varken en integritetsfunktion eller en kringgång av brandväggen.

Tre villkor som avgör det

En fråga avgör de andra två, så svara på den innan du redigerar något. Om motparten ringer ut förfinar de återstående frågorna bara ett beslut som redan är fattat. Om den tar emot inkommande anslutningar gör ingen justering av den lokala porten den nåbar.

Inleder den här motparten anslutningen? Om den ringer ut är en dynamisk källport ofarlig och vanligtvis att föredra, eftersom svaret följer samma flöde tillbaka. Om den väntar på inkommande anslutningar gör en dynamisk port den oåtkomlig om inte något framför publicerar porten. Det enda svaret skiljer varje klientprofil från varje serverprofil.

Filtrerar vägen på källport? En strikt regel skriven för en känd port tvingar fram en uttrycklig lokal port, och profilen bör notera vilken regel den uppfyller. De flesta nät filtrerar bara på mål, så detta villkor är ovanligare än det första. Där det gäller har det företräde framför preferensen för en dynamisk port.

Delar flera instanser värden? En enda fast port kan inte betjäna två av dem, och en omstartad instans kan hitta 1194 fortfarande i ett stängande tillstånd. Dynamiska portar tar bort den konflikten utan att ändra något annat. Om du inte kan svara på detta med säkerhet, anta ja och låt kärnan välja.

Där en låst port är rätt svar

Vissa nät filtrerar både på källport och mål, så en operatör kan ha skrivit en regel som bara släpper igenom trafik från en känd port. Att låsa den lokala porten är då korrekt, och profilen bör bära en kommentar som namnger regeln den uppfyller. Låsning för symmetri med serverporten är inte ett skäl, eftersom de två talen inte har något med varandra att göra. Om låsningen bara finns för att en mall hade den, ta bort den.

Annars köper en låst port problem: två klienter på en maskin kan inte båda hålla 1194, och den andra misslyckas med ett fel som pekar på porten i stället för profilen. En container som startar om snabbt träffar samma vägg. Reparationen är det direktiv som de levererade profilerna redan innehöll.

Server och klient är inte symmetriska

OpenVPN 2.6-handboken placerar nobind bredvid lport, vilket är argumentet på en rad: ett val säger att kärnan väljer, det andra säger att du gör det. En dynamisk lokal port fungerar bara för den motpart som ringer ut, eftersom den svarande sidan inte kan känna till porten i förväg. Därför ger kopiering av en klientprofil till en server en lyssnare som ingen kan nå.

På en värd med flera nätverksgränssnitt är adressen ett beslut skilt från porten. Att binda en bestämd lokal adress och att binda en bestämd port är två olika inställningar, och en server med två uppströmslänkar låser vanligtvis båda. En klient som låser båda har tagit på sig samma stelhet utan någon fördel.

Sammanfattningen handlar om roller, inte om säkerhet: den som ringer ut kan vara flexibel med sin egen källa, och den som svarar kan inte. Ingen av valen ändrar vad den andra änden får veta om din identitet. Det är också därför direktivet dyker upp i klientexempel och nästan aldrig i serverexempel.

Kontrollera porten som kärnan valde

Efter anslutning, läs socketen i stället för konfigurationen, eftersom konfigurationen anger avsikten och socketen anger vad som hände. Fakta som är värda att notera är den lokala porten, den fjärran ändpunkten och om något fortfarande lyssnar. På en Linux-värd är alla tre en kommando bort.

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

En klient med nobind visar en hög lokal port och den konfigurerade fjärrporten, vilket är den förväntade formen. En server visar en lyssnande socket på sin konfigurerade port, och om den socketen saknas är profilen antingen ingen lyssnare eller kunde inte binda. När det finns ett flöde men inga paket kommer tillbaka, jämför den valda källporten med alla portfilter på vägen innan du redigerar profilen. Ändra en sak, anslut igen och läs socketen på nytt.