Tunneldigger, nova VPN rešitev EN

Omrežje wlan slovenija je v letošnjem letu doživelo pospešeno rast. Rast je povezana tudi z začetkom vedno večje uporabe TP-Link ruterjev v omrežju, ki predstavljajo kakovostno, a cenovno ugodno alternativo drugim routerjem. Težava je, da imajo manj prostega flash pomnilniškega prostora, ki ne zadostuje za namestitev programa OpenVPN, ki smo ga do sedaj uporabljali za vzpostavitev tunelov preko Interneta, na lokacijah kjer neposredna brezžična povezava med točkami ni mogoča. Zato smo se lotili iskanja drugačne rešitve, pri čemer smo najprej uporabili obstoječe možnosti (#149, #919). Nekaj časa smo tudi preizkušali n2n, vendar smo ga opustili, saj ni bil dovolj zanesljiv, obenem pa so se pojavljale težave z MTU pri nekaterih povezavah.

Pri iskanju ustrezne rešitve so se naše ključne zahteve nanašale predvsem na enostavno vzpostavitev, visoko prepustnost oziroma delovanje ter omejitev dodatnega dela, ki ga mora program opraviti zaradi preklapljanja kontekstov med kernel in uporabniškim načinom delovanja. Zadnje je namreč predstavljalo dodatno težavo tako pri OpenVPN kot pri n2n. Za veliko točk, vzpostavljenih na FTTH (povezave preko optike), se je kot omejujoč dejavnik za prepustnost tunela pokazal procesor routerja in ne Internetna povezava, in sicer prav zaradi tega preklapljanja. To je zahtevalo pristop, ki deluje le v kernel načinu delovanja, in po posvetovanju na Linux kernel poštnem seznamu smo se odločili, da se prava rešitev nahaja v smeri uporabe L2TPv3. Ker je celotno omrežje odprtega značaja in kot tako deluje preko odprtih brezžičnih povezav, kriptiranje podatkov na tunelih ne doda pretirano k varnosti, zato smo se lahko izognili tudi dodatnemu delu, ki bi sicer bilo potrebno za kriptiranje podatkov.

Kmalu smo ugotovili, da manjka komponenta za upravljanje s tuneli. Za L2TPv2 je sicer na voljo odprtokodni broker, vendar verzija 2 podpira zgolj prenos sej PPP, potrebovali pa smo pravo L2 rešitev. Verzija 3 podpira t.i. ethernet pseudowire, kar je natančno to, kar smo potrebovali, vendar žal ni na voljo takšne odprtokodne broker/klient kombinacije, ki bi podpirala omenjeno verzijo. Zato smo se odločili, da naredimo lastno rešitev, in smo ustvarili Tunneldigger. Preberi več za kratek oris arhitekture.

Naša rešitev je sestavljena iz preprostega nadzornega protokola, ki se uporablja pri določanju parametrov novega tunela, kot so uporabljeni porti tunela in PMTU. Določanje uporabljenih portov je potrebno, saj so vzpostavljene točke ponavadi skrite za prevajalci spletnih naslovov, zato se zunanji porti različni od portov na točki. Nadzorni protokol ni kompatibilen z L2TPv3, saj smo potrebovali zgolj nekaj preprostih lastnosti delovanja in ne celotnega delovanja protokola.

Tako nadzorna kot podatkovna sporočila gredo preko iste UDP povezave skozi uporabo novega kernela L2TPv3 APIja, ki uporablja netlink kot IPC vmesnik. Vmesnik se uporablja tudi za konfiguracijo novih tunelov in vzpostavitev sej, ki ustvarjajo virtualne ethernet vmesnike. Dvosmerne periodične PMTU meritve se izvajajo nad nadzornim kanalom za avtomatsko zaznavanje ustreznih vrednosti PMTU, s katerimi se konfigurira vmesnike. Uporaba istega kanala za testiranje PMTU povečuje verjetnost, da bodo podatkovni paketi potovali po enaki poti in bodo tako imeli enak MTU na poti.

Kernel implementacija L2TPv3 ima tudi svoje omejitve, saj ne more vzpostaviti dveh tunelov na enakem UDP portu, četudi imata ta določena različna identifikatorje. To funkcionalnost smo potrebovali, saj so točke velikokrat za požarnimi zidovi, ki omogočajo prenos paketov UDP le do porta 53 (ter odgovorom iz istega naslova). Zato smo uporabili nekaj NAT magije na strani brokerja. Tako so tuneli notranje povezani z različnimi porti, medtem ko od zunaj na izgled uporabljajo isti port, paketi pa so prepisani glede na vir/destinacijo IP naslova in porta. To omogoča lažji prehod preko požarnih zidov.

Po kar nekaj preigravanja in preizkušanja ter še več debugiranja smo končno razvili rešitev, ki jo trenutno uporabljemo na številnih točkah v omrežju. Z vidika delovanja in omrežne kompatibilnosti se je pokazala kot dobra rešitev, veliko boljša od vseh prejšnjih. Za razvoj uporabljamo GitHub. Če imaš kakšno vprašanje, kar vprašaj na development poštnem seznamu.