Projet

Général

Profil

OpenVPN » Historique » Version 46

Version 45 (julien Bresciani, 08/03/2021 13:50) → Version 46/48 (julien Bresciani, 08/03/2021 13:57)

{{>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. Performances
h3. [[Benchmark VPN]]. VPN]]

h3. recherche de débit debit openvpn, statut status en mars 2021. 2021

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

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

Les
openvpn

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

Tests effectués sur les liens VPN 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 OPENVPN en utilisant la commande :
<pre><code class="text">
ping -M do -s 1472 free.fr
</code></pre>
La 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 mtu d openvpn qui a aussi une directive pour decouvrir le MTU mtu sur le lien : @--mtu-test@. --mtu-test.
les résultats resultats des tests de MTU mtu d openvpn sont disponibles après apres lancement dans les log.

Pour >Pour les sites tunlng (fibre GPON avec ONT intégré a la box Bouygues 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 recherche de débit, 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 dépend depend probablement du débit théorique debit theorique des lignes sur lesquelles on évolue evolue mais surtout de leur latence.

Les tests sur tunukr montrent un passage du débit debit de 120 mbits/s a 250 300 mbits/s en mettant les buffers d openvpn a zéro. zero. les options d openvpn pour réaliser realiser 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 apres avoir bougé de nombreuses options d openvpn dont @--tcp-nodelay --tcp-queue-limit 256@ dont il faudrait étudier 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 défaut. defaut.
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 l'interfacee ou autre (a noter d ailleurs qu openvpn modifie cette valeur lors de son démarrage même demarrage meme si l'interface existe déjà).
apres avoir augmenté le txqueuelen, on arrive a des débits debits entre 400 et 600mbits/s soit 80 a 100 pourcent de ce qui est dispo en bande passante réelle. reelle.

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

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

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