Dalawang LAN sa NetBird: aling mga peer ang nagruruta at sino ang puwedeng magsalita

Isang workstation sa kanlurang LAN ang nagbukas ng browser, nag-type ng address ng isang application sa silangang LAN at naghintay hanggang mag-time out. Sinasabi ng bawat screen ng NetBird na konektado ang mga peer, na totoo at hindi ang punto: ang pagiging nasa isang overlay network ay hindi katulad ng pagkakaroon ng dalawang lokal na subnet sa isang network. Ang paglalakbay sa ibaba ay nagsisimula sa workstation na iyon at nagtatapos sa isang kahilingang sadyang tinatanggihan ng disenyo, at bawat hintuan ay isang bagay na binabasa mula sa aparato, hindi hinuhulaan. Asahan na ang kulang na piraso ay isang ruta o patakaran, hindi ang overlay.

Basahin muna ang kabiguan mula sa workstation

Bago buksan ang management console, alamin kung ano talaga ang ipinapadala ng workstation. Ang sarili nitong routing table ang nagpapasya kung ang packet ay pupunta sa gateway ng site, sa lokal na interface o wala, at nakikita ang desisyong iyon nang walang anumang overlay tool. Ang makina na walang ruta para sa malayong prefix ay mabibigo gaano man kaganda ang listahan ng peer. Ang saklaw ng overlay at ang sariling prefix ng site ay magkaibang address space, at isa lamang sa mga ito ang na-configure ng pagpapatala.

Pagkatapos, ihiwalay ang paglutas ng pangalan sa maabot, dahil pareho silang iniuulat ng browser bilang isang timeout. Ulitin ang kahilingan ayon sa address mula sa makinang tumatakbo ang NetBird client, pagkatapos mula sa ordinaryong workstation na hindi. Kung magtagumpay ang rehistradong makina at mabigo ang ordinaryo, nasa lokal na routing ang agwat; kung parehong mabigo, magpatuloy sa pagbasa bago magbago ng ruta.

Pumili ng isang routing peer bawat site

Ang routing peer ay isang host na kumakatawan sa LAN nito sa overlay, kaya pumili ng Linux machine na may matatag na maabot sa subnet kaysa sa desk workstation ng iba. Iparehistro ito sa normal na proseso at ilagay sa group na pinangalanan ayon sa role, dahil ang network resource at patakaran ay parehong tumutukoy sa group na iyon. Ang isang representante bawat site ay nananatiling madaling basahin; ang kuyog ng mga volunteer na nag-aanunsyo ng parehong prefix ay ginagawang debugging session ang bawat susunod na tanong. Ang address ng peer sa lokal na segment ay kasinghalaga ng identity nito sa overlay, dahil ang address na iyon ang nagiging susunod na hop na sinasabi sa bawat ordinaryong device.

Isulat ang plano bago hawakan ang console, dahil ang mga pangalan at prefix ang lugar kung saan lumilihis ang mga disenyong ito: prefix, gateway, peer address at group, bawat site. Kanluran ang 10.52.0.0/24 na pinaglilingkuran ng 10.52.0.5 at silangan ang 10.63.0.0/24 na pinaglilingkuran ng 10.63.0.5; ang dalawang group ay west-routers at east-routers, at walang prefix na maaaring mag-overlap sa isa pa, sa saklaw ng overlay o sa ibang rutadong destinasyon.

Gawin ang resource, panatilihin ang masking

Sa deployed dashboard, gumawa ng isang network resource bawat site at ikabit dito ang routing-peer group ng site na iyon. Ang resource ay ang prefix at ang group ay ang host na sumasagot para dito, at pareho silang dapat umiiral bago maanunsyo ang anuman. Kumpirmahin na ang deployed self-hosted na bersyon ay may Networks workflow, dahil ang mas lumang interface na may katulad na pangalan ng route object ay ibang feature.

Iwanang bukas ang masking. Hinihiling ito ng gabay ng NetBird para sa site-to-site sa ayos na ito, at ang patayin ito para manatiling nakikita ang bawat orihinal na address ay hindi ang parehong disenyo na may isang hop na mas kaunti; binabago nito kung ano ang nakikita ng source checks at patakaran ng overlay. Ang kahihinatnan ay dapat sabihin nang tuwiran: ang tumatanggap na serbisyo ay nagtatala ng routing peer bilang source, hindi ang indibidwal na workstation. Kung ang allow list o audit ng serbisyong iyon ay umaasa sa address ng workstation, alinman sa asahan ay magbabago o ang identity ay dapat ipatupad sa hangganan ng site bago ang pagsasalin.

Bigyan ng awtoridad ang mga nag-uumpisa, hindi ang mga prefix

Ang ruta ay nagpapamaabot sa isang address at ang patakaran ang nagpapasya kung sino ang puwedeng gumamit nito; ito ay dalawang magkahiwalay na object na may magkahiwalay na may-ari. Isulat ang patakaran paatras mula sa workload: aling group ang nag-uumpisa, aling resource ang target at aling TCP service ang kailangan. Ang network na nag-aanunsyo ng dalawang prefix sa bawat rehistradong peer ay lumikha ng maabot at wala pang niresolba.

Pagkatapos, basahin kung ano pa ang pinapayagan na, dahil ang makitid na bagong patakaran ay hindi binabawi ang malawak na lumang patakaran na nasa itaas nito. Kapag ang silangan ay kailangan ding magsimula ng koneksyon pakanluran, isulat ang direksyong iyon bilang sarili nitong patakaran; ang return traffic ng session na binuksan ng kanluran ay ibang tanong kaysa pagpayag ng bagong session pakanluran. Kung ilang workstation sa kanluran lang ang dapat makarating sa application sa silangan, piliin ang mga ito sa hangganan ng site bago ang pagsasalin at panatilihin ang sariling authentication ng application. Dinadala ng routing peer ang LAN traffic bilang buong site at hindi bilang per-user overlay identity, kaya ang per-user accounting ay dapat manggaling sa ibang lugar.

Ituro sa bawat gateway ang susunod na hop, pagkatapos subukan ang pagtanggi

Hindi kailanman nakikita ng mga ordinaryong device ang overlay, kaya kailangan ng sarili nilang gateway ng static na ruta na itinuturo ang malayong prefix sa LAN address ng routing peer. Ito ang hakbang na nilalaktawan ng mga tao, dahil gumagana na ang lahat ng nakikita sa loob ng NetBird habang nag-time out pa rin ang mga ordinaryong workstation. Pinapanatili ng gateway ang default na ruta nito tulad ng dati; ang prefix na ito ay dagdag, hindi kapalit.

Ang dalawang paglalarawan ng ruta ay kabilang sa gateway configuration ng bawat site, hindi sa override sa host. Pareho silang ordinaryong static na ruta, at wala sa kanila ang gumagalaw sa default na ruta:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

Subukan gamit ang application na talagang kailangan ng proyekto, mula sa ordinaryong workstation, at itala ang tatlong bagay: ang susunod na hop na pinili sa sender side, ang patakarang tumugma at ang source address na naitala ng serbisyo. Subukan din ang pagtanggi, dahil ang disenyong hindi kailanman tumanggi sa anuman ay may hindi kilalang gilid, at ang pagtanggi ang tanging ebidensyang gumagana ang patakaran at hindi ang routing. Kapag ang silangan ay kailangan ding magsimula, magsimula ng bagong koneksyon mula sa panig na iyon sa halip na ipagpalagay na susunod ang ikalawang direksyon. Planuhin din ang restart, upgrade at pagpapalit ng routing peer, dahil ang isang host ay naging dependency ng site.

Ang mga pribadong pangalan ay nangangailangan ng sariling disenyo ng resolver, dahil ang maabot ay hindi gumagawa ng DNS record at ang gumaganang IP path na may sirang pangalan ay binabasa nang eksakto tulad ng sirang path. Kung ang routing peer ay tumatakbo sa loob ng cloud network, suriin din ang forwarding at firewall rules ng provider, dahil hindi ito binabalewala ng pagpapatala. Itago ang mga obserbasyon ng test sa tabi ng plano, dahil ang susunod na magde-debug nito ay gugustuhin ang tumugmang patakaran at naitalang source address, hindi ang paglalarawan ng topology.