Skal din OpenVPN-klient bruge nobind eller en fast port?

To profiler, der adskiller sig med én linje, opfører sig forskelligt i det øjeblik, en anden klient starter på samme vært. Den ene bærer nobind og tager enhver lokal port, kernen uddeler; den anden reserverer 1194, og den anden instans dør med en adresse, der allerede er i brug. Den linje afgør, hvem der vælger kildeporten, hvilket igen afgør, om profilen kan eksistere sammen med noget andet på maskinen. Tre spørgsmål afgør det, og det første besvarer de fleste profiler, før du når de to andre.

Hvad nobind egentlig springer over

Som standard binder klienten en lokal socket, før den ringer ud, og den lokale port er 1194, medmindre profilen siger andet. nobind fjerner den reservation, så stakken tildeler en ubrugt port ved forbindelsen. Det er en fravalg, ikke en standard, og en klient uden linjen holder 1194, hvilket netop er grunden til, at en ikke-fastlåst anden instans kolliderer. De fleste leverede klientprofiler bærer direktivet af den grund, og at en eksempelfil gør noget, er ikke det samme som, at mekanismen gør det som standard.

Det, der ikke ændrer sig, er den fjerne side. Serveren lytter stadig, hvor profilen siger, den lytter, og destinationsporten i konfigurationen er stadig destinationsporten. En dynamisk kildeport ændrer returadressen på din egen socket og intet ved serverens.

Det skjuler heller intet. Din offentlige adresse er, hvad stien oversætter den til, pakken krydser stadig det lokale netværk, og den, der driver netværket, ser stadig en strøm. nobind er hverken en privatlivsfunktion eller en omgåelse af firewallen.

Tre betingelser, der afgør det

Et spørgsmål afgør de to andre, så besvar det, før du redigerer noget. Hvis modparten ringer ud, finpudser de resterende spørgsmål kun en beslutning, der allerede er taget. Hvis den accepterer indgående forbindelser, gør ingen justering af den lokale port den tilgængelig.

Indleder denne modpart forbindelsen? Hvis den ringer ud, er en dynamisk kildeport uskadelig og normalt at foretrække, fordi svaret følger samme strøm tilbage. Hvis den venter på indgående forbindelser, gør en dynamisk port den utilgængelig, medmindre noget foran offentliggør porten. Det ene svar adskiller enhver klientprofil fra enhver serverprofil.

Filtrerer stien på kildeport? En streng regel skrevet til én kendt port tvinger en eksplicit lokal port, og profilen bør notere, hvilken regel den opfylder. De fleste netværk filtrerer kun på destination, så denne betingelse er sjældnere end den første. Hvor den gælder, tilsidesætter den præferencen for en dynamisk port.

Deler flere instanser værten? En enkelt fast port kan ikke betjene to af dem, og en genstartet instans kan finde 1194 stadig i en lukkende tilstand. Dynamiske porte fjerner den konflikt uden at ændre noget andet. Hvis du ikke kan besvare dette med sikkerhed, antag ja og lad kernen vælge.

Hvor en fastlåst port er det rigtige svar

Nogle netværk filtrerer på både kildeport og destination, så en operatør kan have skrevet en regel, der kun lukker trafik igennem fra én kendt port. At fastlåse den lokale port er så korrekt, og profilen bør bære en kommentar, der navngiver den regel, den opfylder. Fastlåsning for symmetri med serverporten er ikke en grund, fordi de to tal ikke har noget med hinanden at gøre. Hvis fastlåsningen kun findes, fordi en skabelon havde den, skal du slette den.

Ellers køber en fastlåst port problemer: to klienter på én maskine kan ikke begge holde 1194, og den anden fejler med en fejl, der peger på porten i stedet for på profilen. En container, der genstarter hurtigt, rammer samme mur. Rettelsen er det direktiv, som de leverede profiler allerede indeholdt.

Server og klient er ikke symmetriske

OpenVPN 2.6-manualen placerer nobind ved siden af lport, hvilket er argumentet på én linje: én valgmulighed siger, at kernen vælger, den anden siger, at du gør. En dynamisk lokal port virker kun for den modpart, der ringer ud, fordi den svarande side ikke kan kende porten på forhånd. Derfor giver det en lytter, som ingen kan nå, at kopiere en klientprofil over på en server.

På en vært med flere netværksgrænseflader er adressen en beslutning adskilt fra porten. At binde en bestemt lokal adresse og at binde en bestemt port er to forskellige indstillinger, og en server med to opstrømsforbindelser fastlåser normalt begge. En klient, der fastlåser begge, har påtaget sig samme stivhed uden nogen fordel.

Sammenfatningen handler om roller, ikke om sikkerhed: den, der ringer ud, kan være fleksibel med sin egen kilde, og den, der svarer, kan ikke. Ingen af valgene ændrer, hvad den anden ende lærer om din identitet. Det er også derfor, direktivet dukker op i klienteksempler og næsten aldrig i servereksempler.

Kontroller porten, som kernen valgte

Læs socketten efter forbindelsen i stedet for konfigurationen, fordi konfigurationen angiver hensigten, og socketten angiver, hvad der skete. De fakta, der er værd at notere, er den lokale port, det fjernede endepunkt og hvorvidt noget stadig lytter. På en Linux-vært er alle tre én kommando væk.

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

En klient med nobind viser en høj lokal port og den konfigurerede fjernport, hvilket er den forventede form. En server viser en lyttende socket på sin konfigurerede port, og hvis den socket mangler, er profilen enten ikke en lytter eller kunne ikke binde. Når der findes en strøm, men ingen pakker kommer tilbage, skal du sammenligne den valgte kildeport med ethvert portfilter på stien, før du redigerer profilen. Ændr én ting, genopret forbindelsen, og læs socketten igen.