Moet je OpenVPN-client nobind of een vaste poort gebruiken?
nobind laat de kernel de bronpoort kiezen voor een client die naar buiten verbindt. Drie voorwaarden bepalen of je dat wilt, of liever een vastgezette lokale poort.
Twee profielen die één regel verschillen, gedragen zich anders op het moment dat een tweede client op dezelfde host start. De ene draagt nobind en neemt elke lokale poort die de kernel toewijst; de andere reserveert 1194, en de tweede instantie sterft met een adres dat al in gebruik is. Die regel bepaalt wie de bronpoort kiest, wat weer bepaalt of het profiel met iets anders op de machine kan samengaan. Drie vragen beslechten het, en de eerste beantwoordt de meeste profielen voordat je bij de andere twee komt.
Wat nobind echt overslaat
Standaard bindt de client een lokale socket voordat hij belt, en de lokale poort is 1194 tenzij het profiel anders zegt. nobind verwijdert die reservering, zodat de stack bij het verbinden een ongebruikte poort toewijst. Het is een uitzondering, geen standaard, en een client zonder de regel houdt 1194, en dat is precies waarom een niet-vastgezette tweede instantie botst. De meeste meegeleverde clientprofielen dragen de richtlijn om die reden, en dat een voorbeeldbestand iets doet is niet hetzelfde als dat het mechanisme het standaard doet.
Wat niet verandert, is de andere kant. De server luistert nog steeds waar het profiel zegt dat hij luistert, en de doelpoort in de configuratie is nog steeds de doelpoort. Een dynamische bronpoort verandert het retour-adres van je eigen socket en niets aan dat van de server.
Het verbergt ook niets. Je openbare adres is wat het pad er van maakt, het pakket gaat nog steeds door het lokale netwerk, en wie dat netwerk beheert ziet nog steeds een stroom. nobind is geen privacyfunctie en geen firewallomzeiling.
Drie voorwaarden die het beslissen
Eén vraag beslist de andere twee, dus beantwoord hem voordat je iets bewerkt. Als de peer naar buiten belt, verfijnen de overige vragen alleen een al genomen besluit. Als hij inkomende verbindingen accepteert, maakt geen enkele aanpassing van de lokale poort hem bereikbaar.
Initieert deze peer de verbinding? Als hij naar buiten belt, is een dynamische bronpoort onschadelijk en meestal te verkiezen, omdat het antwoord dezelfde stroom terug volgt. Als hij op inkomende verbindingen wacht, maakt een dynamische poort hem onbereikbaar tenzij iets ervoor de poort publiceert. Dat ene antwoord scheidt elk clientprofiel van elk serverprofiel.
Filtert het pad op bronpoort? Een strikte regel die voor één bekende poort is geschreven, dwingt een expliciete lokale poort af, en het profiel moet vastleggen aan welke regel het voldoet. De meeste netwerken filteren alleen op bestemming, dus deze voorwaarde komt minder vaak voor dan de eerste. Waar het geldt, gaat het voor op de voorkeur voor een dynamische poort.
Delen meerdere instanties de host? Eén vaste poort kan er niet twee bedienen, en een herstarte instantie kan 1194 nog in een sluitende toestand aantreffen. Dynamische poorten nemen dat conflict weg zonder iets anders te veranderen. Als je dit niet met zekerheid kunt beantwoorden, neem dan aan van wel en laat de kernel kiezen.
Waar een vaste poort het juiste antwoord is
Sommige netwerken filteren zowel op bronpoort als op bestemming, dus een operator heeft misschien een regel geschreven die alleen verkeer van één bekende poort doorlaat. De lokale poort vastzetten is dan juist, en het profiel hoort een opmerking te bevatten die de regel noemt waaraan het voldoet. Vastzetten om symmetrie met de serverpoort is geen reden, want de twee getallen hebben niets met elkaar te maken. Als het vastzetten er alleen is omdat een sjabloon het had, verwijder het.
Anders koopt een vaste poort problemen: twee clients op één machine kunnen niet allebei 1194 vasthouden, en de tweede faalt met een fout die naar de poort wijst in plaats van naar het profiel. Een container die snel herstart, loopt tegen dezelfde muur. De reparatie is de richtlijn die de meegeleverde profielen al bevatten.
Server en client zijn niet symmetrisch
OpenVPN 2.6-handleiding plaatst nobind naast lport, wat het argument in één regel is: de ene optie zegt dat de kernel kiest, de andere zegt dat jij het doet. Een dynamische lokale poort werkt alleen voor de peer die naar buiten belt, omdat de antwoordende kant de poort niet vooraf kan kennen. Daarom levert het kopiëren van een clientprofiel naar een server een luisteraar op die niemand kan bereiken.
Op een host met meerdere netwerkinterfaces is het adres een beslissing los van de poort. Een specifiek lokaal adres binden en een specifieke poort binden zijn twee verschillende instellingen, en een server met twee uplinks zet meestal beide vast. Een client die beide vastzet, heeft dezelfde starheid aangenomen zonder enig voordeel.
De samenvatting gaat over rollen, niet over beveiliging: wie naar buiten belt kan flexibel zijn over zijn eigen bron, en wie antwoordt kan dat niet. Geen van beide keuzes verandert wat de andere kant over je identiteit leert. Daarom duikt de richtlijn op in clientvoorbeelden en bijna nooit in servervoorbeelden.
Controleer de poort die de kernel koos
Lees na het verbinden de socket in plaats van de configuratie, want de configuratie geeft de bedoeling aan en de socket wat er is gebeurd. De feiten die het noteren waard zijn, zijn de lokale poort, het externe eindpunt en of er nog iets luistert. Op een Linux-host zijn alle drie één commando verwijderd.
ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn
Een client met nobind toont een hoge lokale poort en de geconfigureerde externe poort, wat de verwachte vorm is. Een server toont een luisterende socket op zijn geconfigureerde poort, en als die socket ontbreekt, is het profiel ofwel geen luisteraar ofwel kon het niet binden. Als er een stroom is maar er komen geen pakketten terug, vergelijk dan de gekozen bronpoort met elk poortfilter op het pad voordat je het profiel bewerkt. Verander één ding, verbind opnieuw en lees de socket weer.