{{>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 débit openvpn, statut 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 même 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 même test hors du tunnel.

d autres tests (wget , speedtest-cli) corroborent ces résultats.

h3. Recherche de débit, hypothese1 : tester le CPU de la machine faisant tourner openvpn.

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 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 débit, hypothese2 : tester la MTU pour fixer la taille des paquets openvpn.

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 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 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 résultats des tests de MTU d openvpn sont disponibles après lancement dans les log.

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 débit, 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 dépend probablement du débit théorique des lignes sur lesquelles on évolue mais surtout de leur latence.

Les tests sur tunukr montrent  un passage du débit de 120 mbits/s a 250 300 mbits/s en mettant les buffers d openvpn a zéro. les options d openvpn pour réaliser ceci sont: @--sndbuf 0 --rcvbuf 0@

La charge CPU n ayant pas monté, on sent que puisque l'on et en mode non chiffré, on doit pouvoir faire mieux , après avoir bougé de nombreuses options d openvpn dont @--tcp-nodelay --tcp-queue-limit 256@ dont il faudrait étudier 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 défaut.

pour changer la taille de la queue : @ip link set tunukr txqueuelen 1000@.

Cette commande a un effet direct , pas besoin de redémarrer l'interface ou autre (a noter d ailleurs qu openvpn modifie cette valeur lors de son démarrage même si l'interface existe déjà).

apres avoir augmenté le txqueuelen, on arrive a des débits entre 400 et 600mbits/s soit 80 a 100 pourcent de ce qui est dispo en bande passante réelle.

h3. Recherche de débit , conclusion et configuration: 

Nous avons multiplié par 3-4 le débit du tunnel openvpn tunukr via cette manip et multiplié par 10 le débit sur le tunnel tunlng, sans effet de bord sur 48-72h (pas de déconnections, lags, variations brutales de débits).

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 démarrage 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).

la configuration retenue a l issue de ces tests pour lancer openvpn dans le /etc/rc.local est : 

<pre><code class="c">

openvpn --dev tunukr --dev-type tun --lport 0 --persist-tun --cipher none --auth none --remote 91.224.148.1 65114 --verb 4 --mute 20 --mtu-test --sndbuf 0 --rcvbuf 0 --tcp-nodelay --tcp-queue-limit 256 --txqueuelen 1000 --proto udp --daemon --log-append /root/vpn-65114.log --keepalive 10 60

</code></pre>

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. Liens.

* 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