Servir OpenVPN per TCP i UDP des d'un sol amfitrió
Abans de la 2.7, un procés enllaça un sol transport. Compareu una parella TAP pontada, dues subxarxes TUN i un pool compartit, i feu coincidir cada perfil amb el seu escoltador.
Les xarxes que només permeten TCP 443 conviuen amb xarxes que deixen passar UDP sense problemes, i un servidor ha de servir les dues. Un perfil amb proto udp respon al segon grup i falla al primer, i editar la mateixa configuració per dir proto tcp no crea un segon escoltador. La directiva tria un transport per a un procés. Tota la resta se'n deriva.
O executeu més d'un procés, o executeu una versió que pot enllaçar diversos sockets alhora.
Abans de la 2.7, un procés enllaça un sol transport
La versió comunitària d' OpenVPN enllaça el socket que descriu proto , i aquesta directiva tria un sol transport per a la instància. TCP i UDP són piles separades, així que el mateix número de port pot ser ocupat pels dos alhora, però no per un sol procés. Per això la línia 2.6 us dona un transport per dimoni. OpenVPN 2.7 va eliminar aquesta limitació per als servidors, que poden enllaçar diversos sockets mitjançant diverses --local en un sol procés.
Comproveu la versió abans de dissenyar al voltant de qualsevol de les dues respostes, perquè el muntatge de la 2.7 és un model operatiu diferent amb la seva pròpia sintaxi de configuració. Una guia escrita per a la 2.6 descriu dos processos encara que no ho digui.
Tres maneres d'executar dues instàncies
Amb interfícies TAP, executeu una instància per transport i pontueu els dos dispositius tap a l'amfitrió. Els dos conjunts de clients acaben al mateix domini de difusió, cosa que permet que un sol pool d'adreces els cobreixi i manté en funcionament els protocols que depenen de la difusió. Amb TUN no hi ha pont, així que la divisió més simple dona a cada instància la seva pròpia subxarxa i deixa que l'encaminament mantingui els dos conjunts de clients separats. Una tercera opció manté un sol pool fent que cada instància cridi un script learn-address que instal·la una ruta /32 per al client a través del dispositiu d'aquella instància.
Aquesta tercera disposició és la que la gent demana i la que necessita més cura, perquè l'script passa a formar part del camí de dades i ha de gestionar correctament els esdeveniments d'addició, actualització i supressió.
| 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 |
Manteniu les dues instàncies separades
Cada instància també necessita un port o una adreça a part, un fitxer d'estat a part i una destinació de registre a part. Dos dimonis que afegeixen al mateix fitxer d'estat produeixen una sortida que no es pot llegir durant un incident, que és exactament quan la necessiteu. Si una segona instància enllaça una adreça concreta, aquesta adreça ha d'existir a l'amfitrió quan arrenca el procés; si no, surt amb un error d'enllaç abans de dir res sobre claus.
Anomeneu les unitats i els perfils de manera que el transport sigui evident pel nom del fitxer . El següent operador no hauria de haver d'obrir una configuració per saber quin és TCP.
Feu coincidir el perfil amb l'escoltador
Un servidor que executa proto tcp espera un perfil de client amb proto tcp-client , i un perfil que encara porta proto udp contra aquest escoltador esgota el temps sense cap error sobre el qual l'usuari pugui actuar . Manteniu dos perfils si el desplegament ofereix els dos transports, i etiqueteu-los perquè el suport pugui veure quin s'ha provat. El número de port sol no descriu el transport.
Les regles del tallafoc segueixen la mateixa divisió: una regla per a UDP 1194 no diu res sobre TCP 1194, i una regla per a una adreça no cobreix l'altre escoltador.
Llegiu primer la visió del servidor
Comenceu amb ss -lntup al servidor i confirmeu que apareixen tant un escoltador TCP com un d'UDP. Després connecteu un client de cada tipus i reviseu la sortida d'estat per trobar-hi dues entrades amb adreces diferents. Si els sockets existeixen i no arriba cap client, el camí o el tallafoc rebutja els paquets abans que el dimoni els vegi.
Un socket que no apareix mai és un problema de configuració o d'enllaç, i un socket que apareix però no registra mai cap connexió és un problema de filtratge. Des del client tots dos semblen idèntics, per això la visió del mateix servidor va primer. Tingueu en compte que TCP porta bloqueig de cap de línia, així que oferir-lo és una mesura d'abastabilitat, no una millora per als clients amb un camí UDP net.