{{>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