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!