Å betjene OpenVPN over TCP og UDP fra én vert
Én prosess binder én transport før 2.7. Sammenlign et broet TAP-par, to TUN-subnett og en delt pool, og koble deretter hver profil til sin lytter.
Nettverk som bare tillater TCP 443, lever side om side med nettverk som slipper UDP uhindret gjennom, og én server må betjene begge. En profil med proto udp svarer den andre gruppen og feiler på den første, og å redigere samme konfigurasjon til å si proto tcp lager ikke en ny lytter. Direktivet velger én transport for én prosess. Alt annet følger av den begrensningen.
Enten kjører du flere enn én prosess, eller du kjører en versjon som kan binde flere sokler samtidig.
Én prosess binder én transport før 2.7
Fellesskapets OpenVPN binder soklen som proto beskriver, og det direktivet velger én transport for instansen. TCP og UDP er separate stabler, så samme portnummer kan være opptatt av begge samtidig, men ikke av én prosess. 2.6-linjen gir deg derfor én transport per daemon. OpenVPN 2.7 fjernet den begrensningen for servere, som kan binde flere sokler gjennom flere --local utsagn i én prosess.
Kontroller versjonen før du designer rundt noen av svarene, fordi 2.7-oppsettet er en annen driftsmodell med sin egen konfigurasjonssyntaks. En veiledning skrevet for 2.6 beskriver to prosesser selv når den ikke sier det.
Tre måter å kjøre to instanser på
Med TAP-grensesnitt kjører du én instans per transport og broer de to tap-enhetene på verten. Begge klientgruppene ender i samme kringkastingsdomene, noe som lar én adressepool dekke dem og holder kringkastingsavhengige protokoller i gang. Med TUN er broing ikke tilgjengelig, så den enkleste delingen gir hver instans sitt eget subnett og lar rutingen holde de to klientgruppene fra hverandre. Et tredje alternativ beholder én pool ved å la hver instans kalle et learn-address-skript som installerer en /32-rute for klienten gjennom den instansens enhet.
Det tredje oppsettet er det folk spør om og det som trenger mest omhu, fordi skriptet blir en del av datastien og må håndtere hendelser for legg til, oppdater og slett riktig.
| 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 instansene atskilt
Hver instans trenger også en egen port eller adresse, en egen statusfil og et eget loggmål. To daemoner som skriver til samme statusfil gir utdata som ikke kan leses under en hendelse, og det er nettopp da du trenger dem. Hvis en andre instans binder en bestemt adresse, må den adressen finnes på verten når prosessen starter; ellers avsluttes den med en bindfeil før den sier noe om nøkler.
Gi enhetene og profilene navn slik at transporten er åpenbar fra filnavnet. Den neste operatøren skal ikke måtte åpne en konfigurasjon for å vite hvilken som er TCP.
Koble profilen til lytteren
En server som kjører proto tcp forventer en klientprofil med proto tcp-client, og en profil som fortsatt har proto udp mot den lytteren går ut på tid uten en feil brukeren kan gjøre noe med. Behold to profiler hvis utrullingen tilbyr begge transportene, og merk dem slik at støtten vet hvilken som ble prøvd. Portnummeret alene beskriver ikke transporten.
Brannmurregler følger samme deling: en regel for UDP 1194 sier ingenting om TCP 1194, og en regel for én adresse dekker ikke den andre lytteren.
Les serverens eget bilde først
Start med ss -lntup på serveren og bekreft at både en TCP- og en UDP-lytter vises. Koble deretter til én klient av hver type og sjekk statusutdata for to oppføringer med ulike adresser. Hvis soklene finnes og ingen klient kommer, avviser stien eller brannmuren pakkene før daemonen ser dem.
En sokkel som aldri vises er et konfigurasjons- eller bindproblem, og en sokkel som vises men aldri logger en tilkobling er et filtreringsproblem. De to ser like ut fra klienten, og derfor kommer serverens eget bilde først. Husk at TCP bærer hodelinjelblokkering, så å tilby det er et tilgjengelighetstiltak og ikke en oppgradering for klienter med en ren UDP-sti.