Cateodata vrei sa ai aceeasi retea Layer2 in doua locatii diferite din diverse motive precum stretched clusters, servere care au nevoie de L2 pentru comunicare intre ele si alte dude de genul asta.

Initial ma uitasem pe Google ca tot omul si singurele raspunsuri erau legate de OpenVPN cu TAP device pus cumva un bridge si teoretic ar fi mers treaba. Practic nu am gasit cum sa car VLAN-uri in mod elegant prin el si am renuntat la idee o vreme.

Dupa aia m-am apucat io de facut cercetari cu internetul paralel si din comanda in comanda am ajuns sa aflu ca in distro-urile recente de Linux exista suport pentru L2TPv3 sau pseudowires, cum i se mai zice.

Si mi s-a aprins beculetul. De ce sa ma screm cu OpenVPN si TAP si alte cacaturi de genul cand cel mai simplu e sa fac mai multe pseudowires bridge-uite pe VLAN-uri? Pe care le pot transporta lejer peste IPSec pentru securitate.

Setup-ul de proba este asa:

L-am facut in VMware, de aia se vad acolo notatii cu vmnet. Si am facut atatea retele pentru a fi sigur ca nu se duc pachetele aiurea si trec pe unde trebuie, sa nu imi scape ceva si dupa aia sa ma fac de ras ca nu mai stiu retelistica :))

In VMware (Workstation/Fusion), o retea de tip VMNet este echivalenta unui switch chior. In felul asta am simulat ca as avea multe echipamente si fiecare conectate in cate un switch dedicat.

OS-ul pe care am facut stuff-ul este CentOS 7. Mai exista suport pentru L2TPv3 si in ultima versiune de Ubuntu si probabil si in alte distributii.

Adresare IP:

• router
  • eth0: 10.200.100.1/30
  • eth1: 10.200.100.5/30
  • eth2: 10.200.100.9/30
• gw-a
  • eth0: 10.200.100.2/30
  • eth1: spre PC1, nu are adresa IP alocata
• gw-b
  • eth0: 10.200.100.6/30
  • eth1: spre PC2, nu are adresa IP alocata
• gw-c
  • eth0: 10.200.100.10/30
  • eth1: spre PC3, nu are adresa IP alocata
• pc1
  • eth0: 10.200.101.1/24
• pc2
  • eth0: 10.200.101.2/24
• pc3
  • eth0: 10.200.101.3/24

Scopul final este sa fac cele 3 PC-uri sa se poata “pingui” intre ele ca si cand ar fi infipte in acelasi switch.

Prima oara, se face legatura intre gw-a si gw-b, astfel:

gw-a

# modprobe l2tp_eth
# ip l2tp add tunnel local 10.200.100.2 remote 10.200.100.6 tunnel_id 1000 peer_tunnel_id 1000 encap udp udp_sport 5001 udp_dport 6001
# ip l2tp add session tunnel_id 1000 session_id 1000 peer_session_id 1000

gw-b

# modprobe l2tp_eth
# ip l2tp add tunnel local 10.200.100.6 remote 10.200.100.2 tunnel_id 1000 peer_tunnel_id 1000 encap udp udp_sport 6001 udp_dport 5001
# ip l2tp add session tunnel_id 1000 session_id 1000 peer_session_id 1000

Pentru fiecare sesiune, se creeaza cate o interfata numita l2tpethX. Aceste interfete se creeaza in ordinea adaugarii sesiunilor, asa ca mare grija la ce se intampla dupa aia cu ele.

Acum ca tunelul este ridicat si la fel si o sesiune, trebuie configurata partea de Layer2:

gw-a

# ip link set l2tpeth0 up
# ip link add br0 type bridge
# ip lnk set l2tpeth0 master br0
# ip link set eth1 master br0
# ip link set br0 up

gw-b

# ip link set l2tpeth0 up
# ip link add br0 type bridge
# ip link set l2tpeth0 master br0
# ip link set eth1 master br0
# ip link set br0 up

Verificam ca totul functioneaza cum trebuie:

Ce-am facut a fost sa creez un bridge intre interfata L2TP si interfata eth1 care este in acelasi vmnet cu PC1, respectiv PC1 si din punct de vedere logic, acestea se afla an aceeasi retea Layer 2.

Pentru distractie, am extins un pic ideea si am facut un tunel si o sesiune intre gw-b si gw-c, astfel:

gw-b

# modprobe l2tp_ip
# ip l2tp add tunnel tunnel_id 2000 peer_tunnel_id 2000 local 10.200.100.6 remote 10.200.100.10 encap ip
# ip l2tp add session tunnel_id 2000 session_id 2000 peer_session_id 2000

gw-c

# modprobe l2tp_eth
# modprobe l2tp_ip
# ip l2tp add tunnel tunnel_id 2000 peer_tunnel_id 2000 local 10.200.100.10 remote 10.200.100.6 encap ip
# ip l2tp add session tunnel_id 2000 session_id 2000 peer_session_id 2000

In caz ca se intreaba cineva ce e cu encap ip de mai sus, L2TPv3 pe Linux suporta doua tipuri de encapsulari: UDP si IP:

• IP (proto 115) este folosit atunci cand exista conectivitate directa intre gateway-uri si overhead-ul trebuie sa fie minim.
• UDP este folosit atunci cand poate exista un NAT la mijloc, sau exista vreun dispozitiv precum un firewall care are ceva impotriva pachetelor IP care sunt diferite de UDP/TCP/ICMP, ca se mai intampla.

Acum, se seteaza bridge-ul pe gw-c:

# ip link set l2tpeth0 up
# ip link add br0 type bridge
# ip link set l2tpeth0 master br0
# ip link set eth1 master br0
# ip link set br0 up

Pe gw-b deja exista un bridge si tot ce trebuie sa facem este sa adaugam si interfata generata de noua sesiune la acelasi bridge:

# ip link set l2tpeth1 master br0

Si voila, acum si PC3 se afla in acelasi LAN cu PC1 si PC2:

Asta teoretic ar fi un fel de point-to-multipoint (p2mp) dar de fapt este un fel de mesh multipoint mesh, ca oricine poate vorbi cu oricine, si se poate extinde destul de mult. Din documentatie, tunnel_id e de la 1 la 4 miliarde, la fel si session_id. Presupun ca o sa ramana Linuxul fara interfete pana se termina ID-urile de alocat :)

Cateva note:

• L2TPv3 pe Linux inseamna doar tunele statice, fara absolut nici un control al starii. Adica n-ai cum sa monitorizezi din protocol starea tunelelor si a sesiunilor.
• Cu putina creativitate, tinand cont ca poti activa STP pe bridge, poti sa ai mai multe cai catre un gateway si sa lasi STP-ul sa aiba grija sa nu ai loop-uri la Layer 2.
• Pentru transport de VLAN-uri, se pune tag si pe interfata de L2TP cat si pe interfata de retea, iar apoi sa baga ambele intr-un bridge dedicat.

Sunt curios cat CPU haleste treaba asta cu encapsularea/decapsularea si cam cat ar fi penalitatea de performanta pe un sistem modern (2014+) intr-o combinatie de L2TPv3 peste IPSec.

That’s all, folks!

Ziceam in postul de mai devreme ca io stiu scripting pentru basic stuff, dar gasii o solutie care pare sa faca ce trebuie:

#!/bin/bash
let j=0
let t=1
let s=20
let k=0
p=(`echo {a..z}{a..z}{a..z}`)
for c in `seq 0 62`; do
 for i in `seq 0 4 255`; do
  ip tunnel add g${p[$c]}$t mode gre local 10.15.1.2 remote 10.16.1.2 ttl 255 key 1$k$c$i
  ip addr add 10.$s.0.$[$i+1]/30 peer 10.$s.0.$[$i+2]/30 dev g${p[$c]}$t
  ip link set dev g${p[$c]}$t up
 j=$[$j+1]
 c=$[$c+1]
 done
let j=0
t=$[$t+1]
s=$[$s+1]
k=$[$k+1]
done

La rulare (daca adaug echo in fata comenzilor de iproute2) zice asa:

sh s | grep key | uniq | wc -l
    4032

Unde s este numele scriptului. Logic, nu? :))

Si cheile sunt unice, ca la asta imi era tarsala sa nu se incalece pe undeva:

sh s | grep key | cut -d" " -f 14 | uniq | wc -l
    4032

Posibil BUG:

Din motive care imi scapa, din cand in cand, cand vrea sa adauge un tunel, kernelul intoarce ca nu poate adauga gre0 desi scriptul incearca cu totul alt nume. Se intampla cam de 5 ori la 4023 de iteratii si drept urmare adauga doar 4027 de tunele (ceea ce oricum este mai mult decat nevoie pe o singura masina)

Rulat cu set -x, outputul arata asa cand ii da cu virgula:

+ j=17
+ c=61
+ for i in '`seq 0 4 255`'
+ ip tunnel add gacj45 mode gre local 10.15.1.2 remote 10.16.1.2 ttl 255 key 1446168
add tunnel "gre0" failed: File exists
+ ip addr add 10.64.0.69/30 peer 10.64.0.70/30 dev gacj45
Cannot find device "gacj45"
+ ip link set dev gacj45 up
Cannot find device "gacj45"

N-am nici o idee de ce face asta, ca pare totul ok ca si comenzi date. Se strica de la ip tunnel add si normal ca restul de comenzi nu merg ca numele ala de cap de tunel nu exista.

Si ca sa sterg turma de tunele, ii dau in cap cu asta:

for i in `ip a l | grep NONE | cut -d" " -f2 | cut -d"@" -f1`; do ip tunnel del $i; done

Now beware of my newly acquired mad scripting skillz :))

Una din chestiile la care ma gandeam cu ideaa mea este scalabilitatea tunelelor GRE, in sensul de cate se pot termina pe o masina normala.

Asa ca m-am apucat de treaba:

[gw-a] <---> [router] <---> [gw-b]

• gw-a:
  • eth0: 10.15.1.2/24
• gw-b:
  • eth0: 10.16.1.2/24
• router:
  • eth0: 10.15.1.1/24
  • eth1: 10.16.1.1/24

Fiecare tunel are asociate adrese dintr-un /30 si are si cheie setata. Cand se foloseste GRE cu cheie, cheia este folosita la identificarea precisa a traficului in cazul in care ai mai multe tunele cu aceeasi masina sau chiar si cu masini distincte (cheia se adauga la tupla de asocieri).

 Pe gw-a punem prima adresa IP din subnet:

#!/bin/bash
let j=0
for i in `seq 0 4 255`; do
 ip tunnel add gta$i mode gre local 10.15.1.2 remote 10.16.1.2 ttl 255 key 10$i
 ip addr add add 10.20.0.$[$i+1]/30 peer 10.20.0.$[$i+2]/30 dev gta$i
 ip link set dev gta$i up
 j=$j+1
done

Pe gw-b punem a doua adresa IP din subnet:

#!/bin/bash
let j=0
for i in `seq 0 4 255`; do
 ip tunnel add gta$i mode gre local 10.16.1.2 remote 10.15.1.2 ttl 255 key 10$i
 ip addr add add 10.20.0.$[$i+2]/30 peer 10.20.0.$[$i+1]/30 dev gta$i
 ip link set dev gta$i up
 j=$j+1
done

Cu asta ridicam cate 64 de tunele o data. Pentru eu stiu scripting cat sa fac chestii relativ basic, se editeaza fisierul de script si se incrementeaza asa:

• a din numele interfetei de tunel se schimba in b, c si tot asa
• key 10$i se muta in 11$i si tot asa (11, 12, 13 etc.)
• subnetul se incrementeaza si el 10.20 devine 10.21, si tot asa

O sa fac un update cand ma prind cum pot modifica totul programtic si sa pot ridica toate interfetele o data.

Exista un catch: indexul unei interfete nu poate depasi 254, adica nu poti avea eth255 ca da oroare, asa ca am venit cu hack-ul de mai sus: 64 de gta, 64 de gtb si tot asa. Ideal ar fi fost pana la 254, da nu stiu cum :)

Eu am testat pana la vreo 1216 interfete de tunel ridicate (vreo 19 iteratii de script), cu cheie si tot ce trebuie, dupa care m-am plictisit, dar cred ca merge pana pe la vreo 4094 de interfete de tunel. Bine ar fi sa mearga si mai sus, dar pana la urma intr-un setup complet cred ca intai ramai fara CPU si latime de banda :)

Anyway, ideea e ca pe o masina cu putina memorie (eu am testat cu 1GB RAM in ideea ca fiecare interface descriptor mai haleste ceva kernel memory, da nu stiu cat, asa ca presupun ca merge si in 512MB toata jucaria) se pot ridica foarte usor vreo 1000+ de tunele GRE si deci si vreo 1000+ de tunele VPN cu diversi.

Quagga tine cateva sute de mii de rute in BGP fara probleme (ultima oara cand m-am dat cu el pe post de router in Internet a dus vreo 300k prefixe – full routing table pe vremea aia).

Pentru scalabilitate se pot face un numar oarecare de HUB-uri care discuta intre ele, iar fiecare client se conecteaza la unul sau mai multe HUB-uri daca se vrea si un fel de redundanta ceva.

Daca nu mi-a dat undeva cu virgula, setup-ul asta este scalabil pentru tot Internetul, CPU si latime de banda sa avem :)

Partea si mai buna: este interoperabil cu orice alt vendor de stie de GRE-over-IPSec si BGP peste.

Din punct de vedere al securitatii:

• Nu mai exista optiunea de a intercepta traficul in tranzit, trebuie facut la sursa sau pe HUB-uri. Asta face viata unui atacator mult mai grea, mai ales daca HUB-urile se afla in teritorii neprietenoase.
• Traficul primit pe VPN trebuie tratat ca orice alt trafic (de exemplu ca un alt ISP), nu e mai de incredere decat junk-ul din Internet, asa ca trebuie aplicate aceleasi protectii.
• Din route-map-uri pe HUB-uri se pot controla anunturile facute de clienti astfel incat sa nu existe posibilitatea de a anunta prefixe aiurea in scopuri de “traffic hijacking”.
• Pentru ca tot traficul catre anumite destinatii se duce pe VPN, un atacator nu-si poate da seama cine cu cine vorbeste, cat si pe ce protocoale. Nexam metadata, nexam analize statistice, totul este la gramada. E ca la ToR, vezi ca intra da nu stii unde se duce :))