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 :))