Betjening af OpenVPN over TCP og UDP fra én vært
Før 2.7 binder én proces én transport. Sammenlign et brokoblet TAP-par, to TUN-undernet og en delt pulje, og match derefter hver profil til sin lytter.
Netværk, der kun tillader TCP 443, findes side om side med netværk, der uden problemer sender UDP igennem, og én server skal betjene begge. En profil med proto udp svarer den anden gruppe og fejler på den første, og at ændre samme konfiguration til at sige proto tcp opretter ikke en anden lytter. Direktivet vælger én transport til én proces. Alt andet følger af den begrænsning.
Enten kører du mere end én proces, eller du kører en version, der kan binde flere sockets på én gang.
Før 2.7 binder én proces én transport
Fællesskabsversionen af OpenVPN binder den socket, som proto beskriver, og det direktiv vælger én transport til instansen. TCP og UDP er separate stakke, så det samme portnummer kan være optaget af begge på samme tid, men ikke af én proces. 2.6-linjen giver dig derfor én transport pr. daemon. OpenVPN 2.7 fjernede den begrænsning for servere, som kan binde flere sockets gennem flere --local i én proces.
Kontroller versionen, før du designer omkring et af de to svar, fordi 2.7-opstillingen er en anden driftsmodel med sin egen konfigurationssyntaks. En vejledning skrevet til 2.6 beskriver to processer, selv når den ikke siger det.
Tre måder at køre to instanser på
Med TAP-grænseflader kører du én instans pr. transport og brokobler de to tap-enheder på værten. Begge klientgrupper ender i samme broadcast-domæne, hvilket lader én adressepulje dække dem og holder broadcastafhængige protokoller kørende. Med TUN er brokobling ikke tilgængelig, så den enkleste opdeling giver hver instans sit eget undernet og lader routing holde de to klientgrupper adskilt. En tredje mulighed bevarer én pulje ved at lade hver instans kalde et learn-address -script, der installerer en /32-rute til klienten gennem den instans' enhed.
Netop den tredje opstilling er den, folk beder om, og den, der kræver mest omhu, fordi scriptet bliver en del af datastien og skal håndtere tilføjelses-, opdaterings- og sletningshændelser korrekt.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Hold de to instanser adskilt
Hver instans har også brug for en separat port eller adresse, en separat statusfil og en separat logdestination. To daemoner, der skriver til én statusfil, giver output, som ikke kan læses under en hændelse, hvilket er præcis, når du har brug for det. Hvis en anden instans binder en bestemt adresse, skal den adresse findes på værten, når processen starter; ellers afslutter den med en bindfejl, før den siger noget om nøgler.
Navngiv enhederne og profilerne, så transporten er tydelig af filnavnet . Den næste operatør bør ikke skulle åbne en konfiguration for at finde ud af, hvilken der er TCP.
Match profilen til lytteren
En server, der kører proto tcp , forventer en klientprofil med proto tcp-client , og en profil, der stadig bærer proto udp mod den lytter timeout uden en fejl, som brugeren kan handle på . Behold to profiler, hvis udrulningen tilbyder begge transporter, og mærk dem, så support kan se, hvilken der blev prøvet. Selve portnummeret beskriver ikke transporten.
Firewallregler følger samme opdeling: en regel for UDP 1194 siger intet om TCP 1194, og en regel for én adresse dækker ikke den anden lytter.
Læs serverens eget billede først
Start med ss -lntup på serveren, og bekræft, at både en TCP- og en UDP-lytter vises. Forbind derefter én klient af hver slags, og tjek statusoutputtet for to poster med forskellige adresser. Hvis sockets findes, og ingen klient kommer, afviser stien eller firewallen pakkerne, før daemonen ser dem.
En socket, der aldrig vises, er et konfigurations- eller bindproblem, og en socket, der vises, men aldrig logger en forbindelse, er et filtreringsproblem. Fra klienten ser de to identiske ud, og derfor kommer serverens eget billede først. Husk, at TCP bærer head-of-line-blokering, så at tilbyde det er en tilgængelighedsforanstaltning, ikke en opgradering for klienter med en ren UDP-sti.