ProHoster > Blog > Lajmet e internetit > Lëshimi i Nebula 1.9, një sistem për krijimin e rrjeteve P2P me mbështetje për overlay

Lëshimi i Nebula 1.9, një sistem për krijimin e rrjeteve P2P me mbështetje për overlay

Lëshimi i projektit Nebula 1.9 ofron një set mjetesh për ndërtimin e rrjeteve të mbrojtura overlay, të cilat lejojnë bashkimin e hosteve të shpërndara fizikisht në një rrjet të veçantë të izoluar, që funksionon mbi rrjetin global. Projekti është i destinuar për krijimin e rrjeteve të veta overlay për çdo nevojë, p.sh., për bashkimin e kompjuterëve korporativë në zyrat e ndryshme, serverëve në qendra të të dhënave të ndryshme ose mjediseve virtuale tek ofrues të ndryshëm të shërbimeve në cloud. Kodi është i shkruar në gjuhën Go dhe shpërndahet nën licencën MIT. Projekti është i themeluar nga kompania Slack, e cila zhvillon mesazherin e saj të emërtuar po ashtu. Përkrahja është ofruar për punë në Linux, FreeBSD, macOS, Windows, iOS dhe Android.

Nyjet nĂ« rrjetin Nebula ndĂ«rveprojnĂ« midis tyre drejtpĂ«rdrejt nĂ« modin P2P — ndĂ«rsa ndodhin nevoja pĂ«r transferimin e tĂ« dhĂ«nave midis nyjeve, krijohen drejtpĂ«rdrejt VPN- lidhjet. Identiteti i çdo hosti nĂ« rrjet konfirmohet nga njĂ« certifikatĂ« digjitale, dhe kyçja nĂ« rrjet kĂ«rkon autentifikim — çdo pĂ«rdorues merr njĂ« certifikatĂ« qĂ« konfirmon adresĂ«n IP nĂ« rrjetin Nebula, emrin dhe anĂ«tarĂ«sinĂ« nĂ« grupet e hosteve. Certifikatat nĂ«nshkruhen nga njĂ« autoritet brenda organizatĂ«s, i vendosur nga krijuesi i çdo rrjeti tĂ« veçantĂ« nĂ« kapacitetin e tij dhe qĂ« pĂ«rdoret pĂ«r tĂ« vĂ«rtetuar kompetencat e hosteve qĂ« kanĂ« tĂ« drejtĂ« tĂ« lidhen me njĂ« rrjet tĂ« veçantĂ« overlay, i lidhur me autoritetin.

Për krijimin e një kanali të sigurt të autentikuar në Nebula përdoret një protokoll tuneli i brendshëm, i bazuar në protokollin e shkëmbimit të çelësave Diffie-Hellman dhe enkriptimin AES-256-GCM. Implementimi i protokollit mbështetet në primitivë të gatshme dhe të verifikuara, të ofruara nga struktura Noise, e cila përdoret gjithashtu në projekte të tilla si WireGuard, Lightning dhe I2P. Kërkohet që projekti të ketë kaluar një audit të pavarur të sigurisë.

Për të zbuluar node të tjera dhe për të koordinuar lidhjet me rrjetin, krijohen node të veçanta "lighthouse", me adresa IP globale të cilat janë të fikse dhe të njohura nga pjesëmarrësit e rrjetit. Node pjesëmarrëse nuk kanë lidhje me jashtën, ato identifikohen përmes certifikatave. Pronarët e hosteve nuk mund të bëjnë ndryshime në certifikatat e nënshkruara dhe, për dallim nga rrjetet tradicionale IP, nuk mund të shndërrohen në një host tjetër thjesht duke ndryshuar adresën IP. Gjatë krijimit të një tuneli, identiteti i hostit konfirmohet nga një çelës privat individual. adresën IP, ata identifikohen nga certifikatat. Pronaret e hosteve nuk mund të bëjnë ndryshime në certifikatat e nënshkruara dhe, ndryshe nga rrjetet tradicionale IP, nuk mund të imitojnë një host tjetër vetëm duke ndërruar adresën IP. Kur krijohet një tunel, identiteti i hostit konfirmohet me një çelës privat unik.

Rrjeti i krijuar i jep një gamë të caktuar adresash intranet (p.sh., 192.168.10.0/24) dhe ndodh lidhja e adresave të brendshme me certifikatat e hosteve. Ofron mekanizma të ndryshëm për kalimin përmes translaterëve të adresave (NAT) dhe për firewall-eve. Organizimi i rrugëtimit përmes rrjetit overlay të trafikut nga hoste të palëve të treta, që nuk bëjnë pjesë në rrjetin Nebula (unsafe route), është i mundur. Nga anëtarët e rrjetit overlay mund të formohen grupe, p.sh., për ndarjen e serverëve dhe stacioneve të punës që u nënshtrohen shqyrtimeve të veçanta të filtrimit të trafikut.

Krijimi i firewall-eve pĂ«r ndarjen e aksesit dhe filtrimin e trafikut midis nyjave nĂ« rrjetin overlay Nebula mbĂ«shtetet. PĂ«r filtrimin aplikohet ACL me lidhje etiketes. Çdo host nĂ« rrjet mund tĂ« pĂ«rcaktojĂ« rregullat e veta tĂ« filtrimit sipas hosteve, grupeve, protokolleve dhe porteve tĂ« rrjetit. NĂ« kĂ«tĂ« rast, hostet filtrohen jo sipas adresave IP, por sipas identifikatorĂ«ve tĂ« hosteve tĂ« verifikuar me njĂ« nĂ«nshkrim digjital, tĂ« cilĂ«t nuk mund tĂ« falsifikohen pa kompromentimin e autoritetit, qĂ« koordinon funksionin e rrjetit.

Në lëshimin e ri:

  • Shtimi i njĂ« konfigurimi tĂ« ri default_local_cidr_any, i cili ndryshon sjelljen gjatĂ« pĂ«rpunimit tĂ« nĂ«nrrjeteve "local_ip" nĂ« rregullat e firewall-it pĂ«r parandalimin e lehtĂ«simit tĂ« papĂ«rshtatshĂ«m tĂ« trafikut ndaj hosteve tĂ« listuar nĂ« bllokun unsafe_routes. NĂ« versionin 1.9, konfigurimi Ă«shtĂ« vendosur nĂ« "true", por nĂ« lĂ«shimin e ardhshĂ«m 1.10 do tĂ« zĂ«vendĂ«sohet me "false", gjĂ« qĂ« do tĂ« çojĂ« nĂ« pĂ«rfshirjen e nĂ«nrrjeteve lokale nĂ« aplikimin e rregullave tĂ« firewall-it ndaj hosteve, qĂ« janĂ« tĂ« qasshĂ«m pĂ«rmes rrugĂ«ve tĂ« pasigurta (pĂ«r hapjen e aksesit ndaj kĂ«tyre hosteve, do tĂ« kĂ«rkohet specifikimi i detyrueshĂ«m i local_cidr).
  • Ofruar njĂ« imazh zyrtar pĂ«r sistemin Docker, qĂ« lejon ndĂ«rtimin e shpejtĂ« tĂ« njĂ« rrjeti overlay mbi bazĂ«n e Nebula ose njĂ« nyje pĂ«r tĂ«.
  • Shtuar ndĂ«rtimet eksperimentale pĂ«r arkitekturĂ«n Loong64.
  • Implementuar njĂ« skenar shĂ«rbimi pĂ«r sistemin e inicializimit OpenRC.
  • NĂ« procesin e sfondit SSH Ă«shtĂ« shtuar mbĂ«shtetje pĂ«r autentifikimin me certifikata tĂ« verifikuara nga autoriteti (sshd.trusted_cas). Realizuar mundĂ«sinĂ« e integrimit tĂ« çelĂ«save tĂ« hosteve nĂ« bllokun e konfigurimeve sshd.host_key.
  • Siguruar mbĂ«shtetje pĂ«r rinisjen e konfigurimeve "tun.unsafe_routes".
  • E hequr mbĂ«shtetjen pĂ«r konfigurimin e vjetĂ«ruar local_range, pĂ«r tĂ« cilin duhet tĂ« pĂ«rdoret preferred_ranges.
  • PĂ«r ndĂ«rtimin tani kĂ«rkohet mjeti go 1.22. KĂ«rkesat minimale pĂ«r versionet e Windows janĂ« rritur nĂ« Windows 10 dhe Windows Server 2016.

Burimi: opennet.ru

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster