Velocizzare OpenVPN su un router Openwrt. Versione alternativa senza saldatore ed estremismi hardware

Velocizzare OpenVPN su un router Openwrt. Versione alternativa senza saldatore ed estremismi hardware

Ciao a tutti, ho letto recentemente vecchio articolo su come velocizzare OpenVPN su un router trasferendo la crittografia su un componente hardware separato, che è saldato all'interno del router stesso. Ho un caso simile per l'autore: TP-Link WDR3500 con 128 megabyte di RAM e un processore scadente che non è completamente in grado di far fronte alla crittografia del tunnel. Tuttavia, non volevo assolutamente entrare nel router con un saldatore. Di seguito è riportata la mia esperienza nello spostamento di OpenVPN su un componente hardware separato con backup sul router in caso di incidente.

Compito

C'è un router TP-Link WDR3500 e un Orange Pi Zero H2. Vogliamo che Orange Pi crittografi i tunnel come al solito e, se succede qualcosa, l'elaborazione della VPN tornerà al router. Tutte le impostazioni del firewall sul router dovrebbero funzionare come prima. E in generale, l'aggiunta di hardware aggiuntivo dovrebbe essere trasparente e impercettibile a tutti. OpenVPN funziona su TCP, l'adattatore TAP è in modalità bridge (server-bridge).

Soluzione

Invece di connettermi tramite USB, ho deciso di utilizzare una porta del router e collegare tutte le sottoreti che dispongono di un bridge VPN all'Orange Pi. Si scopre che l'hardware si bloccherà fisicamente nelle stesse reti del server VPN sul router. Successivamente, installiamo esattamente gli stessi server sull'Orange Pi e configuriamo una sorta di proxy sul router in modo che invii tutte le connessioni in entrata al server esterno e, se l'Orange Pi è morto o non disponibile, allora all'Orange Pi server di fallback interno. Ho preso HAProxy.

Si scopre così:

  1. Arriva un cliente
  2. Se il server esterno non è disponibile, come prima, la connessione va al server interno
  3. Se disponibile, il cliente viene accettato da Orange Pi
  4. La VPN su Orange Pi decodifica i pacchetti e li reinserisce nel router
  5. Il router li instrada da qualche parte

Esempio di implementazione

Quindi, supponiamo di avere due reti sul router: principale(1) e ospite(2), per ognuna di esse esiste un server OpenVPN per la connessione esterna.

Configurazione di rete

Dobbiamo instradare entrambe le reti attraverso una porta, quindi creiamo 2 VLAN.

Sul router, nella sezione Rete/Switch, creare le VLAN (ad esempio 1 e 2) e abilitarle in modalità tagged sulla porta desiderata, aggiungere alle reti corrispondenti eth0.1 ed eth0.2 appena create (ad esempio aggiungerli al bridge).

Su Orange Pi creiamo due interfacce VLAN (ho Archlinux ARM + netctl):

/etc/netctl/vlan-main

Description='Main VLAN on eth0'
Interface=vlan-main
Connection=vlan
BindsToInterfaces=eth0
VLANID=1
IP=no

/etc/netctl/vlan-guest

Description='Guest VLAN on eth0'
Interface=vlan-guest
Connection=vlan
BindsToInterfaces=eth0
VLANID=2
IP=no

E creiamo subito per loro due ponti:

/etc/netctl/br-main

Description="Main Bridge connection"
Interface=br-main
Connection=bridge
BindsToInterfaces=(vlan-main)
IP=dhcp

/etc/netctl/br-guest

Description="Guest Bridge connection"
Interface=br-guest
Connection=bridge
BindsToInterfaces=(vlan-guest)
IP=dhcp

Abilita l'avvio automatico per tutti e 4 i profili (abilitazione netctl). Ora, dopo il riavvio, Orange Pi si bloccherà sulle due reti richieste. Configuriamo gli indirizzi di interfaccia su Orange Pi in Leasing statici sul router.

ip addr show

4: vlan-main@eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-main state UP group default qlen 1000
    link/ether 02:42:f0:f8:23:c8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::42:f0ff:fef8:23c8/64 scope link 
       valid_lft forever preferred_lft forever

5: vlan-guest@eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-guest state UP group default qlen 1000
    link/ether 02:42:f0:f8:23:c8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::42:f0ff:fef8:23c8/64 scope link 
       valid_lft forever preferred_lft forever

6: br-main: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:c7:0f:89:71:6e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.3/24 brd 192.168.1.255 scope global dynamic noprefixroute br-main
       valid_lft 29379sec preferred_lft 21439sec
    inet6 fe80::50c7:fff:fe89:716e/64 scope link 
       valid_lft forever preferred_lft forever

7: br-guest: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ee:ea:19:31:34:32 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.3/24 brd 192.168.2.255 scope global br-guest
       valid_lft forever preferred_lft forever
    inet6 fe80::ecea:19ff:fe31:3432/64 scope link 
       valid_lft forever preferred_lft forever

Configurazione di una VPN

Successivamente, copiamo le impostazioni per OpenVPN e le chiavi dal router. Di solito le impostazioni si trovano in /tmp/etc/openvpn*.conf

Per impostazione predefinita, openvpn in esecuzione in modalità TAP e server-bridge mantiene la sua interfaccia inattiva. Perché tutto funzioni, è necessario aggiungere uno script che venga eseguito quando la connessione viene attivata.

/etc/openvpn/main.conf

dev vpn-main
dev-type tap

client-to-client
persist-key
persist-tun
ca /etc/openvpn/main/ca.crt
cert /etc/openvpn/main/main.crt
cipher AES-256-CBC
comp-lzo yes
dh /etc/openvpn/main/dh2048.pem
ifconfig-pool-persist /etc/openvpn/ipp_main.txt
keepalive 10 60
key /etc/openvpn/main/main.key
port 443
proto tcp
push "redirect-gateway"
push "dhcp-option DNS 192.168.1.1"
server-bridge 192.168.1.3 255.255.255.0 192.168.1.200 192.168.1.229
status /tmp/openvpn.main.status
verb 3

setenv profile_name main
script-security 2
up /etc/openvpn/vpn-up.sh

/etc/openvpn/vpn-up.sh

#!/bin/sh

ifconfig vpn-${profile_name} up
brctl addif br-${profile_name} vpn-${profile_name}

Di conseguenza, non appena avviene la connessione, l'interfaccia vpn-main verrà aggiunta a br-main. Per la griglia ospite - allo stesso modo fino al nome dell'interfaccia e all'indirizzo nel server-bridge.

Richieste di instradamento esternamente e proxy

A questo punto Orange Pi è già in grado di accettare connessioni e connettere i client alle reti richieste. Non resta che configurare il proxying delle connessioni in entrata sul router.

Trasferiamo i server VPN del router su altre porte, installiamo HAProxy sul router e configuriamo:

/etc/haproxy.cfg

global
        maxconn 256
        uid 0
        gid 0
        daemon

defaults
        retries 1
        contimeout 1000
        option splice-auto

listen guest_vpn
        bind :444
        mode tcp
        server 0-orange 192.168.2.3:444 check
        server 1-local  127.0.0.1:4444 check backup

listen main_vpn
        bind :443
        mode tcp
        server 0-orange 192.168.1.3:443 check
        server 1-local  127.0.0.1:4443 check backup

Godere

Se tutto è andato secondo i piani, i clienti passeranno a Orange Pi, il processore del router non si surriscalderà più e la velocità della VPN aumenterà in modo significativo. Allo stesso tempo, tutte le regole di rete registrate sul router rimarranno rilevanti. In caso di incidente, l'Orange Pi cadrà e HAProxy trasferirà i client sui server locali.

Grazie per l'attenzione, suggerimenti e correzioni sono benvenuti.

Fonte: habr.com

Aggiungi un commento