Di cosa ho bisogno per aggiungere un adattatore IPsec virtuale?


8

Sto cercando di impostare manualmente una connessione IPsec dalla console con iproute2. Ciò di cui ho bisogno è un'interfaccia virtuale (nella migliore delle ipotesi, un indirizzo IP virtuale potrebbe anche essere sufficiente) che IPsec trasforma tutto ciò che entra (ESP / TUNNEL MODE) e lo passa a eth0 (sul mio sistema chiamato em1). Dall'altro, un peer prende il pacchetto dal suo stesso eth e lo decifra e lo passa a un'interfaccia virtuale dall'altra parte. Quindi voglio stabilire un tunnel IPsec "normale".

Non ho alcun problema con la politica e la SA, e la configurazione è stata semplice usando i normali indirizzi Ethernet dei sistemi in modalità trasporto, ovvero

ip xfrm policy add src 198.51.100.1 dst 198.51.100.2 dir out tmpl proto esp
ip xfrm state  add src 198.51.100.1 dst 198.51.100.2 spi 24501 proto esp enc des 0xAABBCCDDEEFF0011
ip xfrm state  add src 198.51.100.2 dst 198.51.100.1 spi 24501 proto esp enc des 0xAABBCCDDEEFF0022

e una configurazione avversaria sul peer funziona abbastanza bene.

Ora ho provato a impostare un IP virtuale e un percorso verso l'altro sistema con

ip address add 10.0.0.0 dev em1
ip route add to 10.0.0.2 via 10.0.0.1

e ancora viceversa dall'altra parte. Questo funziona di nuovo bene. Quindi ho modificato la politica IPsec e SA

ip xfrm policy add src 10.0.0.1 dst 10.0.0.2 dir out tmpl src 198.51.100.1 dst 198.51.100.2 proto esp mode tunnel
ip xfrm state  add src 10.0.0.1 dst 10.0.0.2 spi 24501 proto esp enc des 0xAABBCCDDEEFF0011
ip xfrm state  add src 10.0.0.2 dst 10.0.0.1 spi 24501 proto esp enc des 0xAABBCCDDEEFF0022

Quando provo ora al tcpingpeer non ricevo risposta e setkey -PDmi dice che la politica di sicurezza non è mai stata attivata. Ora sto cercando di fabbricare un'interfaccia virtuale funzionante per gestire il tunnel IPsec, ma non so come collegarlo all'interfaccia fisica e come ottengo il kernel per applicare la politica di sicurezza.

Per me è fondamentale che io possa risolverlo con iproute2, poiché alla fine voglio farlo da un programma C ++ e ho già le classi appropriate che rilasciano i comandi Netlink nello stesso stile del ipcomando (quello che posso fare con ip, I anche può fare nel mio codice). In effetti, la prima parte funziona già dal mio programma e voglio usare le stesse funzioni dell'API Netlink per il resto.

Aggiornamento Ho capito che lo stato doveva essere impostato con gli indirizzi del tunnel, così come lo sono le SA funzionanti

ip xfrm state  add src 10.0.0.1 dst 10.0.0.2 spi 24501 proto esp enc des 0xAABBCCDDEEFF0011
ip xfrm state  add src 10.0.0.2 dst 10.0.0.1 spi 24501 proto esp enc des 0xAABBCCDDEEFF0022

mentre la politica rimane la stessa. Ora la politica è attivata e vedo un pacchetto trasformato su una porta di fiuto. Anche iptables sull'altra macchina ha bloccato il pacchetto e l'ho disabilitato per i test.

Quindi, l'unica direzione sembra funzionare ora, ma non ho ancora ricevuto risposta. Inoltre non so se il problema sia ancora in qualche modo la parte di trasformazione, routing o interfaccia. La mia soluzione preferita sarebbe ancora quella che includa un'interfaccia virtuale, ma non ho idea di come collegarla a una fisica, figuriamoci se la trasformazione funzionasse in quel modo.

Risposte:


1

Normalmente quello che usi è un tunnel, creato usando ip tunnel add. Il dispositivo tunnel offre un dispositivo virtuale che incapsula i pacchetti IP all'interno di altri pacchetti IP. Quindi il pacchetto incapsulato può essere crittografato tramite IPsec.

Ad esempio, puoi creare un tunnel GRE usando:

ip tunnel add mytunnel mode gre remote 198.51.100.2
ip addr add 10.0.0.1 peer 10.0.0.2/31 dev mytunnel

Quindi è possibile configurare IPSec per crittografare i pacchetti GRE (o in generale o solo per quella destinazione).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.