computers | the sin within

Azi ma dadui si io un pic cu un MaxBook si prima impresie este ca e foarte misto. Cel putin daca ai sa te plimbi mult, este fantastic, nici nu-l simti in mana.

2015-05-07 21.33.57.jpg

Image 1 of 3

La muzeul de istorie din Bucuresti exista o mini-expozitie cu calculatoare/computere vechi. Am vazut Apple din ala din primele exemplare color, primul computer portabil (care arata ca geamantanul meu), unul cat un frigider, un Amstrad (cred ca cu 386) si alte cele.

2015-05-01 13.15.15.jpg

Image 1 of 27

Sambata am fost pe la DreamHack 2015 si erau acolo niste oameni carea avea live demo de Oculus Rift.

Si bineinteles ca mi-am pus un din ala pe mecla si m-am apucat sa il utilizez sa vad cum e.

E freaky dupa ce se calibreaza si se prinde cum e asezat si in functie de cum te uiti e ca si cum ai fi acolo in mediul ala digital.

N-am stat mai mult de un minut cu el pe ochi, dar cand l-am dat jos m-a luat o ameteala si o greata ceva de speriat. A durat vreo 4-5 ore pana mi-a trecut. Cred ca s-a dereglat ceierul de tot de la ala.

Dar este misto si daca il fac sa nu mai ametesti o sa ruleze la vizualizare de date si la jocuri daca i-ar pune si niste manusi cu acelasi tip de senzori sa le poti vedea si in realitatea virtuala.

about_mac_storage

Tare mi-as dori sa stiu unde sunt filmele alea de zice Mac-ul ca le am pe HDD. Macar sa le vad si eu daca tot le am…

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:

l2tp_network

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:

l2tp_ping_pc1_to_pc2

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:

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

DNS-ul este unul din protocoalele care reprezinta coloana verterbrala a Internetului. Cand a fost inventat, securitatea nu a fost luata in calcul pentru ca s-a mers pe ideea ca toti utilizatorii o sa fie cinstiti, lucru care s-a dovedit un pic fals. DNS-ul a fost abuzat de tot felul de oameni pentru diverse scopuri, mai mult sau mai putin oneroase.

Cele mai intalnite abuzuri asupra lui sunt “cache poisoning” si Man-in-the-Middle (MITM).

Pentru a face protocolul rezilient asupra acestor doua tipuri majore de atacuri si pentru a putea lansa noi servicii sigura bazate pe DNS, un grup de oameni destepti s-au gandit sa adauge si securitate la protocol. Pentru ca e relativ mult de vorbit despre partea de securitate si ideile nu vin toate o data, exista vreo 3 RFC-uri mari care acopera specificatiile de DNSSEC: 4033, 4034 si 4035.

Pe scurt, o autoritate centrala va garanta in jos “zonele” de DNS pana la ultimul domeniu astfel incat daca un server de DNS care stie de DNSSEC trebuie sa rezolve un nume de host sau de domeniu, va putea verifica foarte usor ca raspunsurile primite nu au fost modificate in tranzit de catre o terta parte.

DNSSEC foloseste doua tipuri de chei:

KSK sau Key Signing Key: este cheia cu care sunt semnate inregistrarile de tip DNSKEY. O data create aceste chei, se creaza si inregistrarile de tip DS care for fi publicate in zona domeniului parinte astfel incat sa se realizeze cum trebuie “chain of trust”.
ZSK sau Zone Signing Key: este cheia cu care sunt semnate toate inregistrarile (zona) unui server de DNS autoritativ.

Ca si tipuri de inregistrari, atunci cand avem DNSSEC, avem:

RRSIG: reprezinta semnatura digitala pentru o inregistrare in DNS.
DNSKEY: reprezinta cheia publica pe care resolver-ul de DNS o foloseste pentru a verifica autenticitatea raspunsului primit
DS sau Delegation Signer: reprezinta informatii despre cheile folosite de un domeniu pentru semnarea lor. Inregistrarile de tip DS se pun doar in domeniul parinte si fac referinta la subdomeniul pentru care sunt folosite. Aceste inregistrari reprezinta un HASH al cheilor de semnare efective pentru micsora transferul de date pentru validarea unei semnaturi.
NSEC: reprezinta un pointer la urmatoarele inregistrari dintr-o zona si la tipuri de inregistrari existente. Este folosit pentru a valida existenta sau inexistenta inregistrarilor dintr-un domeniu.
NSEC3: la fel ca NSEC, insa cu o modificare pentru sporirea rezilientei protocolului si pentru a face imposibila enumerarea tuturor inregistrarilor dintr-o zona de DNS
NSEC3PARAM: este folosit de serverele autoritative pentru a decide ce alte inregistrari pot fi trimise unui client care efectueaza interogari pe langa tipul de inregistrare solicitat explicit.

“Trust anchors” reprezinta mecanismul prin care un server de DNS are incredere in anumite semnaturi pentru domenii. Echivalentul ar fi “root hints” sau in PKI: lista autoritatilor de certificare in care are incredere (Trusted Root CAs).

Acum, partea practica :)

dnssec_1

Si pentru ca mi-am dorit mereu un TLD, o sa-l numesc .imacandi. pentru postul asta si o sa avem asa:

[root "."] =>

[TLD "imacandi."] =>

[domeniu "sin.imacandi."]

Plus un resolver pe langa astea care are doar cheia publica a “.” si va face rezolvare recursiva pentru $hostname.sin.imacandi.net.

Servere si adrese IP:

dns-s-1 (root server) / 172.16.155.101
dns-s-2 (ns for .imacandi.) / 172.16.155.102
dns-s-3 (ns for sin.imacandi.) / 172.16.155.103
dns-s-5 (resolver) / 172.16.155.108

(da stiu ca pe poza sunt mai multe servere, da m-a luat desenatul pe dinainte si dupa aia mi-am dat seama ca ma pot descurca si cu mai putine)

Ca si software voi folosi BIND 9.9.4 pe CentOS 7 (default).

Prima oara semnam “.”

root@dns-s-1 named]# dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE .
Generating key pair....+++ ...................+++ 
K.+007+64334
[root@dns-s-1 named]# dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE .
Generating key pair...................................................++ ......................................................................................................................................................++ 
K.+007+28638

[root@dns-s-1 named]# for key in `ls K*key`; do echo "\$INCLUDE $key" >> named.ca ; done
[root@dns-s-1 named]# cat named.ca 
$TTL 3600
@       IN      SOA     dns-s-1.root-servers.net.      hostmaster.root-servers.net.
(                       2012071200 ; serial number YYMMDDNN
                        28800           ; Refresh
                        7200            ; Retry
                        864000          ; Expire
                        3600             ; Min TTL
)
                NS      dns-s-1.root-servers.net.
$ORIGIN .
dns-s-1.root-servers.net. 3600 IN A 172.16.155.101
$INCLUDE K.+007+28638.key
$INCLUDE K.+007+64334.key

[root@dns-s-1 named]# dnssec-signzone -A -3 $(head -c 1000 /dev/urandom | sha1sum | cut -b 1-16) -N INCREMENT -o . -t named.ca

Verifying the zone using the following algorithms: NSEC3RSASHA1.
Zone fully signed:
Algorithm: NSEC3RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                         ZSKs: 1 active, 0 stand-by, 0 revoked
named.ca.signed
Signatures generated:                       10
Signatures retained:                         0
Signatures dropped:                          0
Signatures successfully verified:            0
Signatures unsuccessfully verified:          0
Signing time in seconds:                 0.022
Signatures per second:                 447.407
Runtime in seconds:                      0.026

Modificam /etc/named.conf astfel:

zone "." {
   type master;
   file "named.ca.signed";
};

Apoi restartam named si in loguri o sa zica urmatoarele (printre altele):

Mar 28 14:13:34 dns-s-1 named[2338]: zone ./IN: loaded serial 2012071201 (DNSSEC signed)

Acum avem “.” semnat (self-signed ca e root, nu exista autoritate mai mare ca .)

Dupa “.” urmeaza crearea unui TLD (Top Level Domain), si anume imacandi. Pentru asta adaugam urmatoarele inregistrari in zona “.”:

imacandi. IN NS ns1.dns.imacandi.
ns1.dns.imacandi. IN A 172.16.155.102

Acum ca zona a fost modificata, trebuie re-semnata si dupa aceea reincarcata de BIND.

dnssec-signzone -A -3 $(head -c 1000 /dev/urandom | sha1sum | cut -b 1-16) -N INCREMENT -o . -t named.ca
[root@dns-s-1 named]# rndc reload
server reload successful

Acum trecem pe dns-s-2 si cream configurarile necesare pentru noua zona, chain of trust cu “.” si importul inregistrarilor de tip DS in “.”.

In primul rand, modificam /etc/named.conf astfel:

trusted-keys {
"." 257 3 7 "AwEAAa8SV9IPDSXr+THXuogKOGxCvERdRf39cJ9spETd22AgVRYTI1Tr C57FXGtcC+tGa0AYs9chGsZ8eNwGD76YdnydD8CT+tLfokbVHih0ewQz RiobvXE4UY7HycrnC+ZY9yToM4ktKSsX1YWFsNGcIBn60c5J39LbAJ/i bB2+TCvdJNE4jrHkP4pf/onXJvG/RMFllShMtmOqgn1y79yJGTwoO2ab Rbm4kV3qDKiLtfrmyLqJTGbKf+R98NTpe1ufPnQCDwV13xlNRlsok8Gz cFDjTNf6ZepQ2wF8CzpDYHK7/tANCEFgR0vOzYkb8VkkaEzMUCYOveqp wy8e+isoDtoBA1e48awEYo3o+YN1DVEbCoR4Xbdy4cf+qkXv0nS8QNar 0RHSjghmsQddDVMoFaYLWv8lqSCd1uQufSnMd1okv3nEyKIwWBB3xG5r x7GJpqMtqA4BRWcv28tGgPkbFaWMkjVPqUIBgyk87fAB+a1H51uy0J1K Q+99U+8/41m6mnNoa2kjxJL53dYcf0DO4eUgsRY2LcO6etk/XbHm9/+M GOfes0pmPJ8V3Yb2V1J5WV62sYaPrvw+jh3h2V5RvNW+QHZ6U5M73eWZ w8vYyygYl3sWHy03vX4mQnq2XsMJ0CDvR+XLWG98RpItYG65LwhiayRP +dDhJpSyOY3aeXLD";
};
zone "imacandi." IN {
 type master;
 file "imacandi.";
 };

In zona “imacandi.” se trec urmatoarele:

$TTL 3600
@       IN      SOA     ns1.dns.imacandi.     hostmaster.dns.imacandi. (
                        2012071203 ; serial number YYMMDDNN
                        28800           ; Refresh
                        7200            ; Retry
                        864000          ; Expire
                        3600             ; Min TTL
)
                NS      ns1.dns.imacandi.
ns1.dns.imacandi. 3600 IN A 172.16.155.102
$ORIGIN imacandi.
sin IN NS dns1.sin.imacandi.
dns1.sin IN A 172.16.155.103

Dupa ce avem configurata zona, trecem la crearea cheilor KSK si ZSK si dupa aia semnam zona.

[root@dns-s-2 named]# dnssec-keygen -a RSASHA256 -b 2048 -n ZONE imacandi.
Generating key pair.............+++ ....+++ 
Kimacandi.+008+03645
[root@dns-s-2 named]# dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE imacandi.
Generating key pair.......................................................................+++ ..................+++ 
Kimacandi.+008+35377

Adaugam cheile in fisierul de zona:

$INCLUDE Kimacandi.+008+03645
$INCLUDE Kimacandi.+008+35377

Si semnam zona:

[root@dns-s-2 named]# dnssec-signzone -N INCREMENT -o imacandi. -t imacandi.
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
imacandi..signed
Signatures generated:                        8
Signatures retained:                         0
Signatures dropped:                          0
Signatures successfully verified:            0
Signatures unsuccessfully verified:          0
Signing time in seconds:                 0.009
Signatures per second:                 833.159
Runtime in seconds:                      0.012

Dupa semnare, luam datele despre DS si le adaugam in zona parinte:

imacandi. IN DS 35377 8 1 16085596E91E80E95E70FA8EABE646A25499967E
imacandi. IN DS 35377 8 2 818FB42E72B000DCD9621F9F78D85845C25BAC44566CD4B687543C1B A874B6C5

Si re-semnam zona parinte.

Pe dns-s-3 am creat zona sin.imacandi.

zone "sin.imacandi" IN {
 type master;
 file "sin.imacandi.signed";
 };

Dupa aceea am creat cheile de semnare:

[root@dns-s-3 named]# dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE sin.imacandi
Generating key pair............................................+++ ..................................+++ 
Ksin.imacandi.+007+43763
[root@dns-s-3 named]# dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE sin.imacandi
Generating key pair.......++ ................++ Ksin.imacandi.+007+02085

Le-am adaugat in zona si dupa am semnat zona:

[root@dns-s-3 named]# dnssec-signzone -A -3 $(head -c 1000 /dev/urandom | sha1sum | cut -b 1-16) -N INCREMENT -o sin.imacandi -t sin.imacandi
Verifying the zone using the following algorithms: NSEC3RSASHA1.
Zone fully signed:
Algorithm: NSEC3RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                         ZSKs: 1 active, 0 stand-by, 0 revoked
sin.imacandi.signed
Signatures generated:                       12
Signatures retained:                         0
Signatures dropped:                          0
Signatures successfully verified:            0
Signatures unsuccessfully verified:          0
Signing time in seconds:                 0.022
Signatures per second:                 543.084
Runtime in seconds:                      0.026

Iar pentru validare, in configuratia lui BIND am adaugat cheia pentru “.” pe dns-s-3 in named.conf:

trusted-keys {
"." 257 3 7 "AwEAAa8SV9IPDSXr+THXuogKOGxCvERdRf39cJ9spETd22AgVRYTI1Tr C57FXGtcC+tGa0AYs9chGsZ8eNwGD76YdnydD8CT+tLfokbVHih0ewQz RiobvXE4UY7HycrnC+ZY9yToM4ktKSsX1YWFsNGcIBn60c5J39LbAJ/i bB2+TCvdJNE4jrHkP4pf/onXJvG/RMFllShMtmOqgn1y79yJGTwoO2ab Rbm4kV3qDKiLtfrmyLqJTGbKf+R98NTpe1ufPnQCDwV13xlNRlsok8Gz cFDjTNf6ZepQ2wF8CzpDYHK7/tANCEFgR0vOzYkb8VkkaEzMUCYOveqp wy8e+isoDtoBA1e48awEYo3o+YN1DVEbCoR4Xbdy4cf+qkXv0nS8QNar 0RHSjghmsQddDVMoFaYLWv8lqSCd1uQufSnMd1okv3nEyKIwWBB3xG5r x7GJpqMtqA4BRWcv28tGgPkbFaWMkjVPqUIBgyk87fAB+a1H51uy0J1K Q+99U+8/41m6mnNoa2kjxJL53dYcf0DO4eUgsRY2LcO6etk/XbHm9/+M GOfes0pmPJ8V3Yb2V1J5WV62sYaPrvw+jh3h2V5RvNW+QHZ6U5M73eWZ w8vYyygYl3sWHy03vX4mQnq2XsMJ0CDvR+XLWG98RpItYG65LwhiayRP +dDhJpSyOY3aeXLD";
};

Iar pe dns-s-2 am adaugat inregistrarile de tip DS si am resemnat zona imacandi.:

sin.imacandi. IN DS 2085 7 1 E1B11E776525C73D7E7484817F57F4F9BDDFAB53
sin.imacandi. IN DS 2085 7 2 FC19462CA30C80691DAF2FFB6847130F7384BB9DAA82199FFDA60415 90976C45

Acum situatia este in felul urmator: dns-s-1 este autoritativ pentru “.” si contine inregistrari de tip DS pentru “imacandi.”, dns-s-2 este autoritativ pentru “imacandi.” si contine inregistrari de tip DS pentru “sin.imacandi.”, dns-s-3 este autoritativ pentru “sin.imacandi.” si contine inregistrari de tip A pentru teste.

Un query recursiv pe dns-s-2 pentru un host numit bumblebee.sin.imacandi. care este definit in zona de pe dns-s-3 arata asa:

[root@dns-s-3 named]# dig +dnssec -t A bumblebee.sin.imacandi. @172.16.155.102 +multiline
; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7_0.1 <<>> +dnssec -t A bumblebee.sin.imacandi. @172.16.155.102 +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14987
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bumblebee.sin.imacandi. IN A
;; ANSWER SECTION:
bumblebee.sin.imacandi. 3521 IN A 172.16.155.104
bumblebee.sin.imacandi. 3521 IN RRSIG A 7 3 3600 (
20150427161417 20150328161417 43763 sin.imacandi.
E9AQRx+ns1ZrmoPw+TduURzS8cGBAftivGEBBh1W75/u
yZ24tGQQ6bmmYQK84YO39qj2JDLANH06212Co0/emBjJ
Ug//YU+06nwT/fRu8vp/VL1u/8F3rSAGT5KSai1cFnjM
Tt/c+urWzAmw9CzxwBO4QE9NCth8jT35tblfUSuTN0xy
lOeTnTPqXvyTYNRm0HxygqIgEDC4K3PdDbZbYAT02djj
/S8upDBZydJb3KuuHRvIZ6n4k0SKAyKChdCABFEGgM/M
qPozD0gU52nYuUlR0fbfY844eqQfnRMNJvfIcY3xYb3h
yidsFSwqgxs0vynCriefAVu/IxpAptlHpw== )

Important este flag-ul AD din raspuns care inseamna Authenticated Data, asta inseamna ca serverul care raspunde poate verifica tot lantul si “chain of trust” este intact.

Mai sunt cateva aspecte pe care intentionez sa le exemplific intr-un post urmator candva:

semnare automata a zonelor
pentru paranoici: interfatarea cu un HSM si stocarea cheilor private pe el
update-ul automat al zonelor + semnarea automata

Cam asta e din categoria ce mai face sin sambata cand ploua afara :)

Se pare ca la partea cu un singur ASN puneam problema gresit:

Initial aveam asa pe vpn-hub spre vpn-gw-a:

route-map A permit 1
 match origin igp
 set ip next-hop 192.168.168.1

route-map-ul era aplicat asa:

neighbor 192.168.168.2 route-map A out

Care teoretic ar fi trebuit sa schimbe next-hop din anunturi in ce i-am zis io mai sus.

Cu un hint de la gabim ca nu trebuie sa fac match pe nimic ci doar sa setez ip next-hop, asa ca am lasat doar varianta cu set ip next-hop. Dar tot fara noroc.

Ma mai scarpinai un pic si ajunsei la alta combinatie care se pare ca merge: pun route-map pe in pe gateway-uri si nu mai fac nimic pe vpn-hub, lucru care se pare ca merge. Plus bonus points ca setand next-hop ca peer-address ma doare la bachetzi cine e peer-ul, deci pot sa fac template.

route-map set-nh permit 1
 set ip next-hop peer-address

Care se aplica asa:

neighbor 192.168.168.1 remote-as 4200000000
neighbor 192.168.168.1 route-map set-nh in

Iar pe vpn-hub arata in felul urmator:

neighbor 192.168.168.2 remote-as 4200000000
neighbor 192.168.168.2 route-reflector-client

Pentru confirmare ca functioneaza treaba:

vpn-gw-a# sh ip bgp 172.16.3.0/24
BGP routing table entry for 172.16.3.0/24
Paths: (1 available, best #1, table Default-IP-Routing-Table)
 Not advertised to any peer
 Local
192.168.168.1 (metric 1) from 192.168.168.1 (192.168.168.10)
 Origin IGP, metric 0, localpref 100, valid, internal, best
 Originator: 192.168.168.10, Cluster list: 192.168.168.9
 Last update: Sat Mar 21 21:55:27 2015

zebra instaleaza ruta corect:

[root@vpn-gw-a ~]# ip r l 172.16.3.0/24
172.16.3.0/24 via 192.168.168.1 dev to-hub  proto zebra

Ping:

[root@vpn-gw-a ~]# ping 172.16.3.1 -I172.16.1.1 -c3
PING 172.16.3.1 (172.16.3.1) from 172.16.1.1 : 56(84) bytes of data.
64 bytes from 172.16.3.1: icmp_seq=1 ttl=63 time=1.99 ms
64 bytes from 172.16.3.1: icmp_seq=2 ttl=63 time=1.37 ms
64 bytes from 172.16.3.1: icmp_seq=3 ttl=63 time=1.37 ms

--- 172.16.3.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 1.376/1.582/1.993/0.290 ms

De asta imi place mie BGP-ul, ca poti sa-l violezi in cele mai oribile moduri (ca ce-am facut mai sus e viol cu perversiuni) si tot functioneaza bine :))

Pe vpn-hub pot sa pun un peer-group imens in care ii strang pe toti, iar pe gateway-uri peer-address. Asa iti vin ideile, facand stuff :)

Teoretic, ar fi mers route-map-ul si pe vpn-hub cum il pusesem inainte, insa se pare ca implementare de quagga nu face stuff cand pui route-map pe out. Dar bine ca merge pe in.

Asa ca pot folosi un singur ASN indiferent de cati neighbor-i am. Acum as putea sa-mi pun un pahar de vin ca am intuit ca se poate, doar ca a durat ceva pana m-am prins si cum.

In mod traditional pentru schimbul de informatii considerate sensibile intre doua companii, indiferent de aplicatie, se stabileste o conexiune IPSec (da, stiu ca mai exista si OpenVPN dar nu se pune ca nu este suportat comercial pentru interoperare). Si treaba asta merge OK cand ai nu numar rezonabil de parteneri, dupa aia nu mai este chiar asa distractiv.

Cand ai o companie mare cu multe locatii, atunci se ajunge la configuratii de tipul Hub-and-Spoke fie configurate manual fie automat folosind DMVPN/GETVPN in functie de necesitati si situatie individuala.

Acum, cum impaci capra cu varza, sa ai o configuratia din asta dar intre companii, un fel de serviciu de IPSec-as-a-Service, ceva de genul:

ipsec-aas-v1_1

Unde VPN HUB este un la “provider” iar gateway-urile de VPN sunt la “clienti”. Si asta se poate extinde pana terminam alfabetul si o luam cu VPN Gateway AA pana la VPN Gateway ZZZZZ.

Cum ar functiona toata treaba asta fara sa se strice si sa fie scalabila? Teoretic ar fi in felul urmator:

IPSec intre capete
GRE over IPSec
BGP over GRE
se accepta doar adrese de IP sau subnet-uri “publice”

De ce BGP? Pai pentru ca:

permite o filtrare mult mai buna a rutelor si a anunturilor, astfel incat sa nu se poata anunta prefixe inexistente sau sa se poata face hijacking
pot anunta sau importa selectiv prefixe
pot folosi si pentru IPv4 cat si pentru IPv6
este mult mai scalabil decat OSPF care este folosit in mod traditional pentru “route based VPNs”

Ideea de baza ar fi in felul urmator:

Vreau sa comunic securizat cu un numar oarecare de entitati cu care am treaba insa nu vreau sa fac tunele VPN cu fiecare in parte
Prefer sa am un singur tunel facut care sa-mi dea acces la restul de tunele
Sa pot publica servicii “secure only” accesibile doar celor din clubul asta
Sa fie greu de detectat de catre o entitate ostila cine cu cine discuta si cat de mult

Pentru validare mi-am facut un setup de test care arata cam asa:

Setarile sunt facute astfel:

vpn-hub
- eth0: 10.15.0.1/24
internet-router
- eth0: 10.16.0.1/24
- eth1: 10.15.0.2/24
vpn-gw-a
- eth0: 10.16.0.2/24
- eth1: 172.16.1.1/24
vpn-gw-b
- eth0: 10.16.0.3/24
- eth1: 172.16.2.1/24
vpn-gw-c
- eth0: 10.16.0.4/24
- eth1: 172.16.3.1/24

internet-router este o masina care sa simuleze “internetul” in sensul de un hop intermediar intre gateway-urile de VPN si concentrator.

Prima oara am setat tunele VPN (pentru test le-am facut cu PSK ca e mai usor):

vpn-hub /etc/ipsec.conf

conn to-vpn-gw-a
 authby=secret
 auto=start
 type=transport
 left=10.15.0.1
 leftnexthop=10.15.0.2
 right=10.16.0.2
 rightnexthop=10.16.0.1

conn to-vpn-gw-b
 authby=secret
 auto=start
 type=transport
 left=10.15.0.1
 leftnexthop=10.15.0.2
 right=10.16.0.3
 rightnexthop=10.16.0.1

conn to-vpn-gw-c
 authby=secret
 auto=start
 type=transport
 left=10.15.0.1
 leftnexthop=10.15.0.2
 right=10.16.0.4
 rightnexthop=10.16.0.1

vpn-hub /etc/ipsec.secrets

10.15.0.1 10.16.0.2: PSK "supersecret"
10.15.0.1 10.16.0.3: PSK "supersecret"
10.15.0.1 10.16.0.4: PSK "supersecret"

vpn-gw-a /etc/ipsec.conf

conn to-vpn-hub
 authby=secret
 auto=start
 type=transport
 left=10.16.0.2
 leftnexthop=10.16.0.1
 right=10.15.0.1
 rightnexthop=10.15.0.2

vpn-gw-a /etc/ipsec.secrets

10.16.0.2 10.15.0.1: PSK "supersecret"

vpn-gw-b /etc/ipsec.conf

conn to-hub
 authby=secret
 auto=start
 type=transport
 right=10.15.0.1
 rightnexthop=10.15.0.2
 left=10.16.0.3
 leftnexthop=10.16.0.1

vpn-gw-b /etc/ipsec.secrets

10.16.0.3 10.15.0.1: PSK "supersecret"

vpn-gw-c /etc/ipsec.conf

conn to-hub
 authby=secret
 auto=start
 type=transport
 right=10.15.0.1
 rightnexthop=10.15.0.2
 left=10.16.0.4
 leftnexthop=10.16.0.1

vpn-gw-c /etc/ipsec.secrets

10.16.0.4 10.15.0.1: PSK "supersecret"

vpn-hub ipsec status

stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0}
"to-vpn-gw-a": 10.15.0.1<10.15.0.1>[+S=C]---10.15.0.2...10.16.0.1---10.16.0.2<10.16.0.2>[+S=C]; erouted; eroute owner: #2
"to-vpn-gw-a":     myip=unset; hisip=unset;
"to-vpn-gw-a":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; nat_keepalive: yes
"to-vpn-gw-a":   policy: PSK+ENCRYPT+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,32; interface: eth0;
"to-vpn-gw-a":   dpd: action:clear; delay:0; timeout:0;
"to-vpn-gw-a":   newest ISAKMP SA: #16; newest IPsec SA: #2;
"to-vpn-gw-a":   IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
"to-vpn-gw-b": 10.15.0.1<10.15.0.1>[+S=C]---10.15.0.2...10.16.0.1---10.16.0.3<10.16.0.3>[+S=C]; erouted; eroute owner: #7
"to-vpn-gw-b":     myip=unset; hisip=unset;
"to-vpn-gw-b":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; nat_keepalive: yes
"to-vpn-gw-b":   policy: PSK+ENCRYPT+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,32; interface: eth0;
"to-vpn-gw-b":   dpd: action:clear; delay:0; timeout:0;
"to-vpn-gw-b":   newest ISAKMP SA: #18; newest IPsec SA: #7;
"to-vpn-gw-b":   IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
"to-vpn-gw-c": 10.15.0.1<10.15.0.1>[+S=C]---10.15.0.2...10.16.0.1---10.16.0.4<10.16.0.4>[+S=C]; erouted; eroute owner: #11
"to-vpn-gw-c":     myip=unset; hisip=unset;
"to-vpn-gw-c":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; nat_keepalive: yes
"to-vpn-gw-c":   policy: PSK+ENCRYPT+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,32; interface: eth0;
"to-vpn-gw-c":   dpd: action:clear; delay:0; timeout:0;
"to-vpn-gw-c":   newest ISAKMP SA: #17; newest IPsec SA: #11;
"to-vpn-gw-c":   IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
#2: "to-vpn-gw-a":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 19862s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate
#2: "to-vpn-gw-a" [email protected] [email protected] ref=0 refhim=4294901761
#16: "to-vpn-gw-a":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 211s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
#4: "to-vpn-gw-b":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 19643s; isakmp#3; idle; import:admin initiate
#4: "to-vpn-gw-b" [email protected] [email protected] ref=0 refhim=4294901761
#15: "to-vpn-gw-b":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 393s; lastdpd=-1s(seq in:0 out:0); idle; import:not set
#7: "to-vpn-gw-b":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 20348s; newest IPSEC; eroute owner; isakmp#6; idle; import:not set
#7: "to-vpn-gw-b" [email protected] [email protected] ref=0 refhim=4294901761
#18: "to-vpn-gw-b":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 3022s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set
#10: "to-vpn-gw-c":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 21719s; isakmp#9; idle; import:not set
#10: "to-vpn-gw-c" [email protected] [email protected] ref=0 refhim=4294901761
#17: "to-vpn-gw-c":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 1169s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
#11: "to-vpn-gw-c":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 21348s; newest IPSEC; eroute owner; isakmp#8; idle; import:admin initiate
#11: "to-vpn-gw-c" [email protected] [email protected] ref=0 refhim=4294901761

type=transport din /etc/ipsec.conf pentru fiecare conexiune in parte inseamna ca o “conexiune” IPSec se va stabili doar intre IP-urile gateway-urilor.

Acum ca totul e OK la partea de criptare, se seteaza tunelele GRE intre gatewa-uri si hub:

vpn-gw-a

ip tunnel add to-hub mode gre remote 10.15.0.1 local 10.16.0.2 ttl 255
ip addr add 192.168.168.2/30 peer 192.168.168.1/30 dev to-hub
ip link set to-hub up

vpn-gw-b

ip tunnel add to-hub mode gre remote 10.15.0.1 local 10.16.0.3 ttl 255
ip addr add 192.168.168.2/30 peer 192.168.168.1/30 dev to-hub
ip link set to-hub up

vpn-gw-c

ip tunnel add to-hub mode gre remote 10.15.0.1 local 10.16.0.4 ttl 255
ip addr add 192.168.168.2/30 peer 192.168.168.1/30 dev to-hub
ip link set to-hub up

vpn-hub

ip tunnel add to-gw-a mode gre remote 10.16.0.2 local 10.15.0.1 ttl 255
ip addr add 192.168.168.1/30 peer 192.168.168.2/30 dev to-gw-a
ip link link set to-gw-a up

ip tunnel add to-gw-b mode gre remote 10.16.0.3 local 10.15.0.1 ttl 255
ip addr add 192.168.168.5/30 peer 192.168.168.6/30 dev to-gw-b
ip link link set to-gw-b up

ip tunnel add to-gw-c mode gre remote 10.16.0.4 local 10.15.0.1 ttl 255
ip addr add 192.168.168.9/30 peer 192.168.168.10/30 dev to-gw-c
ip link link set to-gw-c up

Tunelele GRE sunt necesare pentru a putea ruta peste orice avem nevoie fara a crea SA-uri suplimentare in IPSec pentru fiecare subnet sau adresa IP individuala si abstractizeaza partea de transport. Din punct de vedere IP un gateway are conexiune directa cu hub-ul si atat.

Ultima partea este configurarea Quagga pentru a avea partea de BGP functionala.

vpn-hub /etc/quagga/bgpd.conf

router bgp 4200000000
 bgp router-id 192.168.168.9
 neighbor 192.168.168.2 remote-as 4200000001
 neighbor 192.168.168.2 next-hop-self
 neighbor 192.168.168.10 remote-as 4200000003
 neighbor 192.168.168.10 next-hop-self

vpn-gw-a /etc/quagga/bgpd.conf

router bgp 4200000001
 bgp router-id 192.168.168.2
 network 172.16.1.0/24
 neighbor 192.168.168.1 remote-as 4200000000

vpn-gw-c

router bgp 4200000003
 bgp router-id 192.168.168.10
 network 172.16.3.0/24
 neighbor 192.168.168.9 remote-as 4200000000

Configurarea de pe vpn-gw-b lipseste ca mi-am dat seama in timp ce scriam ca de fapt este OK de demonstrat si cu doar doua gateway-uri :)

vpn-gw-c sh ip bgp

BGP table version is 0, local router ID is 192.168.168.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.1.0/24    192.168.168.9                          0 4200000000 4200000001 i
*> 172.16.3.0/24    0.0.0.0                  0         32768 i

Total number of prefixes 2

vpn-gw-a sh ip bgp

BGP table version is 0, local router ID is 192.168.168.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.1.0/24    0.0.0.0                  0         32768 i
*> 172.16.3.0/24    192.168.168.1                          0 4200000000 4200000003 i

Total number of prefixes 2

vpn-hub sh ip bgp

BGP table version is 0, local router ID is 192.168.168.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.1.0/24    192.168.168.2            0             0 4200000001 i
*> 172.16.3.0/24    192.168.168.10           0             0 4200000003 i

Total number of prefixes 2

Daca de pe vpn-gw-a dau un ping spre vpn-gw-c (ping 172.16.3.1 -I172.16.1.1) in tcpdump pe vpn-hub am sa vad urmatoarele:

20:03:55.112851 IP 10.16.0.2 > 10.15.0.1: ESP(spi=0xbe68e78f,seq=0x338), length 132
20:03:55.112906 IP 10.15.0.1 > 10.16.0.4: ESP(spi=0xac29a868,seq=0x30f), length 132
20:03:55.113404 IP 10.16.0.4 > 10.15.0.1: ESP(spi=0xfdb78f7d,seq=0x2b7), length 132
20:03:55.113434 IP 10.15.0.1 > 10.16.0.2: ESP(spi=0xc07aaa19,seq=0x370), length 132

Adica ajunge pachetul de la vpn-gw-a la vpn-hub, vpn-hub il trimite la vpn-gw-c, vpn-gw-c raspunde la vpn-hub si vpn-hub da mai departe la vpn-gw-a.

Adica merge cum trebuie toata jucaria :)

Ce mai am de studiat, ca inca mi-o iau in freza:

sa folosesc un singur ASN. Am incercat tot felul de combinatii sa fac gateway-urile RR Client pentru vpn-hub insa n-a vrut sa schimbe next-hop nici batut. Nici macar pus in mod explicit cu neighbor X:X:X:X next-hop-self. Ca sa nu incalec ce este acum, am dat-o pe ASN-uri de 32biti reservate, ca alea ar ajunge sa conectez tot internetul la un mega VPN :))
sa trec prin IPSec doar GRE, dar din pacate ii da cu virgula lui OpenSWAN daca ii zic rightprotoport=47 (cu asta nu vrea nici batut) sau rightprotoport=47/%any (moare cu un mesaj dubios legat de “unable to route”)

Alte chestii mai putin importante:

sa vad cum trebuie salvate setarile corect cum vrea CentOS pentru toate optiunile (interfete, GRE, OpenSWAN, Quagga)
trecut pe certificate digitale pentru autentificarea gateway-urilor si IKEv2 pentru schimbul de chei cu niste algoritmi de criptare bine definiti
experimentat si un pic cu IPSec pentru IPv6, dar la cum arata acum parca vad ca o sa trec IPv6-le peste GRE-ul deja existent si scap usor (sper)
sa conving o multime de oameni sa-mi dea bani sa le fiu broker de VPN :))

PS:

am uitat o caruta de chestii, ma uitam (si in continuare ma uit) ca vaca la OpenSWAN si nu mai stiam (stiu) de unde sa-l iau
ce misto e sa ai mult RAM in laptop, poti sa-ti faci maisini virtuale pana te ia plictisul

Dupa ce-o sa-mi treaca durerea de cap de o am, o sa sap mai cu talent in OpenSWAN sa vad cum il fac sa mearga cat mai sigur si cat mai simplu, eventual automatizat un pic.

the sin within

assumption is the mother of all fuckups

Tag Archives: computers

macbook

2015-05-07 21.33.57.jpg

la muzeu

2015-05-01 13.15.15.jpg

oculus rift

mac stuff

p2p/mp layer2 networking over layer3

scriptul

“internet” paralel (3)

dnssec (1)

“internet” paralel (2)

“internet” paralel (1)