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