{{>toc}}

h1. OpenVPN

h2. Port sharing

Apache and nginx
http://www.davidwesterfield.net/2012/08/openvpn-sharing-a-tcp-port-with-ssl-on-nginx-and-apache-yeah-its-possible/

port-share 127.0.0.1 4443

http://www.greenie.net/ipv6/openvpn.html
https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23

https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux

h2. Certificats

Via mherrb : la page de man 'ssl(8)' d'OpenBSD explique bien comment faire un certificat auto-signé qui marchera pour OpenVPN:
http://www.openbsd.org/cgi-bin/man.cgi?query=ssl&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

h2. Server

<pre>
# cat /etc/default/openvpn
...
AUTOSTART="ttnn-tap ttnn-tap6 ttnn-tap-tcp ttnn-tap-tcp6"
...
# cat /etc/openvpn/ttnn-tap.conf
dev tap0udp
port 11195
proto udp

ca ttnn/ca.crt
cert ttnn/h1.crt
key ttnn/h1.key # This file should be kept secret
dh ttnn/dh1024.pem

mode server
tls-server

persist-key
persist-tun

client-config-dir ccd

client-to-client
comp-lzo yes
keepalive 10 60

verb 3
log-append log/openvpn-tap.log
status status/openvpn-tap.txt

# cat /etc/openvpn/ttnn-tap6.conf
dev tap6udp
port 11196
proto udp6

ca ttnn/ca.crt
cert ttnn/h1.crt
key ttnn/h1.key # This file should be kept secret
dh ttnn/dh1024.pem

mode server
tls-server

persist-key
persist-tun

client-config-dir ccd

client-to-client
comp-lzo yes
keepalive 10 60

verb 3
log-append log/openvpn-tap6.log
status status/openvpn-tap6.txt

# cat /etc/openvpn/ttnn-tap-tcp.conf
dev tap0tcp
port 443
proto tcp-server

ca ttnn/ca.crt
cert ttnn/h1.crt
key ttnn/h1.key # This file should be kept secret
dh ttnn/dh1024.pem

mode server
tls-server

persist-key
persist-tun

client-config-dir ccd

client-to-client
comp-lzo yes
keepalive 10 60

verb 3
log-append log/openvpn-tap-tcp.log
status status/openvpn-tap-tcp.txt

# keys generated with id ip-X-Y-Z-T, files:
# ip-91-224-149-165.crt
# ip-91-224-149-165.csr
# ip-91-224-149-165.key

# cat /etc/openvpn/ccd/ip-91-224-149-165
ifconfig-push 91.224.149.165 255.255.255.0
push "route-gateway 91.224.149.254"
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"

# bridge
brctl addbr br0
brctl addif br0 eth0
ip link set br0 up
ip link set br0 address 52:54:10:00:00:11 #force MAC to avoid MAC changes

openvpn --mktun --dev tap0udp
openvpn --mktun --dev tap0tcp
openvpn --mktun --dev tap6udp

brctl addif br0 tap0udp
ip link set tap0udp up

brctl addif br0 tap0tcp
ip link set tap0tcp up

brctl addif br0 tap6udp
ip link set tap6udp up

</pre>

Pour ignorer les push IP et route du serveur coté client openvpn il suffit de mettre "tls-client" a la place de "client" l'option --client est un raccourci pour --tls-client --pull et --pull est ce qui accepte les directives serveur.

h2. Client

<pre>
# cat /etc/openvpn/ttnn.conf
client
dev tap

### from outside with UDP available
#proto udp
#remote openvpn.tetaneutral.net 11195

### from outside with no UDP
proto tcp
remote openvpn.tetaneutral.net 443
# 91.224.149.211 443

# from outside using IPv6 over UDP
#proto udp6
#remote openvpn6.tetaneutral.net 11196

ca ttnn/ca.crt
cert ttnn/ip-91-224-149-165.crt
key ttnn/ip-91-224-149-165.key

persist-key
persist-tun

script-security 2

comp-lzo yes
keepalive 10 60

verb 3
log-append log/openvpn.log
</pre>

h2. point a point

Version tun :

<pre>
# Sur le serveur IPv4 publique A.B.C.D
openvpn --mktun --dev-type tun --dev tuntst
ip link set tuntst up
openvpn --dev-type tun --dev tuntst --proto udp --daemon --keepalive 10 120 --secret tst.key --port 1234

# Sur le client client
openvpn --mktun --dev-type tun --dev tuntst
ip link set tuntst up
openvpn --dev-type tun --dev tuntst --proto udp --daemon --keepalive 10 120 --secret tst.key --lport 0 --remote A.B.C.D 1234
</pre>

Pour le routage IPv6 et le NAT IPv4 sur le serveur :

<pre>
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
ip -6 route add 2a03:7220:808X:YZ01::1/128 dev tuntst

echo 1 > /proc/sys/net/ipv4/ip_forward
ip route add 10.10.10.10/32 dev tuntst
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
</pre>

Then on the client

<pre>
ip -6 addr add 2a03:7220:808X:YZ01::1/128 dev tuntst
ip -6 route add default tuntst
ip addr add 10.10.10.10/32 dev tuntst
# TODO default route
</pre>

h2. Point-à-point avec routage d'un bloc d'IP.

[[Partage ADSL OpenVPN]]

h2. Performances
h3. [[Benchmark VPN]]

h3. recherche de debit openvpn, status en mars 2021

sur le tunnel tunukr ~120 mbits en continu via tests iperf sur nucnagios.tetaneutral.net à travers le vpn . 500 a 600 mbits/s pour le meme test hors du tunnel
sur le tunnel tunlng ~ 50 mbits en continu via tests iperf sur nucnagios.tetaneutral.net à travers le vpn . 500 a 600 mbits/s pour le meme test hors du tunnel
d autres tests (wget , speedtest-cli) corroborent ces resultats.

h3. recherche de debit, hypothese1 : tester le CPU de la machine faisant tourner openvpn

>Les les tests de cpu montrent que dans notre cas, le lien étant non chiffré, il n y a aucun problème de CPU sur le shuttle de tunukr , un dual celeron @1.6ghz , openvpn prends 50 pourcent d un seul CPU.
>Ne Ne pas oublier par contre qu'openvpn2 est monothread. un test pour passer le gouverneur des fréquences CPU en mode performance ne montre aucune variation de débit.

h3. recherche de debit, hypothese2 : tester la MTU pour fixer la taille des paquets openvpn.

> Tests tests effectués sur les liens vpn de tunukr (Toulouse quartier bagatelle) et aussi tunlng (Launaguet) afin de débrider le débit.
>Vérifications vérifications que le MTU est correct sur le lien fibre supportant OPENVPN en utilisant la commande :
<pre><code class="text">
ping -M do -s 1472 free.fr
</code></pre>
la commande envoie un ping avec une demande explicite de non fragmentation du paquet (-M do), 1472 correspond a la taille maxi que l'on peut faire passer sur un lien de MTU 1500 (1472 + 20 octets IPV4 + 8 octets ICMP = 1500).
si le ping passe vous recevez une réponse classique de la part de la commande, si le ping ne passe pas vous recevrez une réponse de ce style :
<pre><code class="text">
local error: message too long, mtu=1492.
</code></pre>

> Cela </code></pre>ping:
cela vous donnera une idée de la MTU de la ligne utilisée et vous permettra d utiliser les options --mssfix --fragment et toutes les options de mtu d openvpn qui a aussi une directive pour decouvrir le mtu sur le lien : --mtu-test.
les resultats des tests de mtu d openvpn sont disponibles apres lancement dans les log.

>Pour
pour les sites tunlng (fibre GPON avec ONT intégré a la box bouygues et tunukr (fibre FTTH free P2P avec convertisseur externe a freebox) , nous avons pu valider que la MTU est de 1500 sur les deux sites.
dans ce cas aucune manip sur la

h3. recherche de debit, hypothese3 : lien "bufferbloated":https://en.wikipedia.org/wiki/Bufferbloat

beaucoup de recherches sur les perfos d openvpn montrent des soucis a cause des buffers internes d openvpn, la proposition de certains est de les agrandir, d autres est de les supprimer, cela depend probablement du debit theorique des lignes sur lesquelles on evolue mais surtout de leur latence.
les tests sur tunukr montrent un passage du debit de 120 mbits/s a 250 300 mbits/s en mettant les buffers d openvpn a zero. les options d openvpn pour realiser ceci sont: @--sndbuf 0 --rcvbuf 0@
la charge CPU n ayant pas monté, on sent que puique l'on et en mode non chiffré, on doit pouvoir faire mieux , apres avoir bougé de nombreuses options d openvpn dont @--tcp-nodelay --tcp-queue-limit 256@ dont il faudrait etudier les effets plus fins, nous avons testé d agrandir la txqueue de l'interface TUN openvpn.
la queue de transmission des paquets c est le "qlen" que l'on voit au bout dune commande @ip address@ ou @ip link@
@tunukr: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 100@ la valeur de la queue settée par openvpn est de 100 par defaut.
pour changer la taille de la queue : @ip link set tunukr txqueuelen 1000@
cette commande a un effet direct , pas besoin de redemarrer l'interafe ou autre (a noter d ailleurs qu openvpn modifie cette valeur lors de son demarrage meme si l'interface existe déjà).
apres avoir augmenté le txqueuelen, on arrive a des debits entre 400 et 600mbits/s soit 80 a 100 pourcent de ce qui est dispo en bande passante reelle.

h3 recherche de debit , conclusion :

nous avons multiplié par 3-4 le debit du tunnel openvpn tunukr via cette manip et multiplié par 10 le debit sur le tunnel tunlng, sans effet de bord sur 48-72h (pas de deconnections, lags, variations brutales de debits).
les directives d openvpn les plus importantes pour atteindre ce gain sont : @--sndbuf 0 --rcvbuf 0@ et @--txqueuelen 1000@ qui permet a openvpn d ajuster au demarrage la valeur de la queue de l'interface tun à la volée (setter la queue via la commande IP et ensuite demarrer openvpn sans le @--txqueuelen 1000@ ... openvpn remettra la queue a 100 qui est la valeur par defaut d openvpn).

h2. Proxmox

http://www.nedproductions.biz/wiki/configuring-a-proxmox-ve-2.x-cluster-running-over-an-openvpn-intranet
http://blog.developpeur-neurasthenique.fr/auto-hebergement-configurer-un-cluster-proxmox-2-sans-multicast.html

h2. Links

* https://community.openvpn.net/openvpn/changeset/150fb45047c5482858b32a669de4097e66dec1c7 "Allow 'lport 0' setup for random port binding"
* https://vador.fdn.fr/wiki/travaux:vpn_misc:doc#configurer_sa_machine_pour_utiliser_l_offre_vpn_de_fdn
* https://wiki.ldn-fai.net/wiki/Tuto_Serveur_OpenVPN