NetBird પર બે LAN: કયા પીઅર રૂટ કરે છે અને કોણ બોલી શકે છે

પશ્ચિમ LAN પરનું વર્કસ્ટેશન બ્રાઉઝર ખોલે છે, પૂર્વ LAN પરની એપ્લિકેશનનું સરનામું લખે છે અને સમય સમાપ્ત થાય ત્યાં સુધી રાહ જુએ છે. NetBird ની દરેક સ્ક્રીન કહે છે કે પીઅર્સ જોડાયેલા છે, જે સાચું છે અને મુદ્દાની બહાર છે: એક ઓવરલે નેટવર્કમાં હોવું એ બે સ્થાનિક સબનેટને એક નેટવર્કમાં રાખવા જેવું નથી. નીચેની મુસાફરી તે વર્કસ્ટેશનથી શરૂ થાય છે અને એવી વિનંતી પર પૂરી થાય છે જે ડિઝાઇન જાણી જોઈને નકારે છે, અને દરેક સ્ટોપ એવી વસ્તુ છે જે તમે ઉપકરણ પરથી વાંચો છો, અનુમાન નહીં. અપેક્ષા રાખો કે ખૂટતો ભાગ રૂટ અથવા નીતિ છે, ઓવરલે નહીં.

પહેલા વર્કસ્ટેશન પરથી ભૂલ વાંચો

મેનેજમેન્ટ કન્સોલ ખોલતા પહેલા નક્કી કરો કે વર્કસ્ટેશન ખરેખર શું મોકલે છે. તેનું પોતાનું રૂટિંગ ટેબલ નક્કી કરે છે કે પેકેટ સાઇટ ગેટવે પર જાય, સ્થાનિક ઇન્ટરફેસ પર જાય કે ક્યાંય નહીં, અને તે નિર્ણય કોઈપણ ઓવરલે સાધન વિના દેખાય છે. દૂરના પ્રીફિક્સ માટે રૂટ ન હોય તેવું મશીન પીઅર યાદી કેટલી સ્વસ્થ દેખાય તે ધ્યાનમાં લીધા વિના નિષ્ફળ જશે. ઓવરલે શ્રેણી અને સાઇટનું પોતાનું પ્રીફિક્સ અલગ સરનામાંની જગ્યાઓ છે, અને નોંધણીએ તેમાંથી ફક્ત એક જ ગોઠવ્યું છે.

પછી નામ ઉકેલને પહોંચથી અલગ કરો, કારણ કે બ્રાઉઝર બંનેને સમાન સમય સમાપ્તિ તરીકે જણાવે છે. NetBird ક્લાયંટ ચલાવતા મશીનથી અને પછી ન ચલાવતા સામાન્ય વર્કસ્ટેશનથી સરનામા દ્વારા વિનંતીનું પુનરાવર્તન કરો. જો નોંધાયેલ મશીન સફળ થાય અને સામાન્ય નિષ્ફળ જાય, તો ખાલી જગ્યા સ્થાનિક રૂટિંગમાં છે; જો બંને નિષ્ફળ જાય, તો રૂટ બદલતા પહેલા વાંચવાનું ચાલુ રાખો.

દરેક સાઇટ માટે એક રૂટિંગ પીઅર પસંદ કરો

રૂટિંગ પીઅર એ યજમાન છે જે ઓવરલે પર તેના LANનું પ્રતિનિધિત્વ કરે છે, તેથી કોઈની ડેસ્ક વર્કસ્ટેશનને બદલે સબનેટ સુધી સ્થિર પહોંચ ધરાવતું Linux મશીન પસંદ કરો. તેને સામાન્ય પ્રક્રિયા દ્વારા નોંધાવો અને ભૂમિકાના નામે જૂથમાં મૂકો, કારણ કે નેટવર્ક સંસાધન અને નીતિ બંને તે જૂથનો સંદર્ભ લેશે. દરેક સાઇટ માટે એક પ્રતિનિધિ વાંચી શકાય તેવો રહે છે; સમાન પ્રીફિક્સની જાહેરાત કરતા સ્વયંસેવકોનું ટોળું દરેક પછીના પ્રશ્નને ડિબગિંગ સત્રમાં ફેરવે છે. સ્થાનિક સેગમેન્ટ પર પીઅરનું સરનામું ઓવરલે ઓળખ જેટલું જ મહત્વનું છે, કારણ કે તે સરનામું દરેક સામાન્ય ઉપકરણને કહેવાતો આગળનો હોપ બને છે.

કન્સોલને સ્પર્શ કરતા પહેલા યોજના લખો, કારણ કે નામ અને પ્રીફિક્સ એ જ જગ્યા છે જ્યાં આ ડિઝાઇન ભટકે છે: પ્રીફિક્સ, ગેટવે, પીઅર સરનામું અને જૂથ, દરેક સાઇટ માટે. પશ્ચિમ 10.52.0.0/24 છે જેને 10.52.0.5 સેવા આપે છે અને પૂર્વ 10.63.0.0/24 છે જેને 10.63.0.5 સેવા આપે છે; બે જૂથો west-routers અને east-routers છે, અને કોઈપણ પ્રીફિક્સ બીજા સાથે, ઓવરલે શ્રેણી સાથે કે અન્ય રૂટ થયેલા ગંતવ્ય સાથે ઓવરલેપ ન કરી શકે.

સંસાધન બનાવો, માસ્કરેડિંગ ચાલુ રાખો

તૈનાત ડેશબોર્ડમાં, દરેક સાઇટ માટે એક નેટવર્ક સંસાધન બનાવો અને તે સાઇટના રૂટિંગ-પીઅર જૂથને તેની સાથે જોડો. સંસાધન એ પ્રીફિક્સ છે અને જૂથ એ યજમાન છે જે તેના માટે જવાબ આપે છે, અને કંઈપણ જાહેર કરતા પહેલા બંને હોવા જોઈએ. ખાતરી કરો કે તૈનાત સ્વ-હોસ્ટેડ આવૃત્તિમાં નેટવર્ક્સ વર્કફ્લો બિલકુલ છે, કારણ કે સમાન નામના રૂટ ઑબ્જેક્ટવાળું જૂનું ઇન્ટરફેસ અલગ સુવિધા છે.

માસ્કરેડિંગ ચાલુ રાખો. NetBird ની સાઇટ-થી-સાઇટ માર્ગદર્શિકા આ ગોઠવણીમાં તેની માંગ કરે છે, અને દરેક મૂળ સરનામું દૃશ્યમાન રાખવા માટે તેને બંધ કરવું એ એક હોપ ઓછી સાથેની એ જ ડિઝાઇન નથી; તે બદલે છે કે ઓવરલેની સ્રોત-તપાસ અને નીતિઓ શું જુએ છે. પરિણામ સીધું કહેવા જેવું છે: પ્રાપ્ત કરતી સેવા સ્રોત તરીકે રૂટિંગ પીઅર નોંધે છે, વ્યક્તિગત વર્કસ્ટેશન નહીં. જો તે સેવાની મંજૂરી-યાદી કે ઓડિટ વર્કસ્ટેશન સરનામાંની અપેક્ષા રાખે, તો કાં તો અપેક્ષા બદલાય છે અથવા અનુવાદ પહેલા સાઇટ સીમા પર ઓળખ લાગુ કરવી પડે.

શરૂ કરનારાઓને અધિકૃત કરો, પ્રીફિક્સને નહીં

રૂટ સરનામાને પહોંચવા યોગ્ય બનાવે છે અને નીતિ નક્કી કરે છે કે કોણ તેનો ઉપયોગ કરી શકે; આ બે અલગ માલિકો સાથેના અલગ ઑબ્જેક્ટ છે. નીતિને વર્કલોડથી પાછળ લખો: કયું જૂથ શરૂ કરે છે, કયા સંસાધનને લક્ષ્ય બનાવે છે અને કઈ TCP સેવા જોઈએ છે. જે નેટવર્ક દરેક નોંધાયેલ પીઅરને બંને પ્રીફિક્સની જાહેરાત કરે છે તેણે પહોંચ બનાવી છે અને કંઈ નક્કી કર્યું નથી.

પછી વાંચો કે બીજું શું પહેલેથી મંજૂર છે, કારણ કે સાંકડો નવો નિયમ તેની ઉપર બેઠેલા પહોળા જૂના નિયમને રદ કરતો નથી. જ્યારે પૂર્વે પણ પશ્ચિમ તરફ જોડાણો શરૂ કરવાના હોય, ત્યારે તે દિશા તેની પોતાની નીતિ તરીકે લખો; પશ્ચિમે ખોલેલા સત્ર માટે પરત ટ્રાફિક પૂર્વ તરફ નવા સત્રોની મંજૂરી કરવાથી અલગ પ્રશ્ન છે. જો ફક્ત અમુક પશ્ચિમ વર્કસ્ટેશનોએ પૂર્વ એપ્લિકેશન સુધી પહોંચવું હોય, તો અનુવાદ પહેલા તેમને સાઇટ સીમા પર પસંદ કરો અને એપ્લિકેશનની પોતાની પ્રમાણીકરણ જગ્યાએ રાખો. રૂટિંગ પીઅર LAN ટ્રાફિકને સમગ્ર સાઇટ તરીકે વહન કરે છે, વપરાશકર્તા દીઠ ઓવરલે ઓળખ તરીકે નહીં, તેથી વપરાશકર્તા દીઠ હિસાબ બીજે ક્યાંકથી આવવો જોઈએ.

દરેક ગેટવેને આગળનો હોપ શીખવો, પછી ઇનકારની કસોટી કરો

સામાન્ય ઉપકરણો ઓવરલે ક્યારેય જોતા નથી, તેથી તેમના પોતાના ગેટવેને સ્થિર રૂટની જરૂર છે જે દૂરના પ્રીફિક્સને રૂટિંગ પીઅરના LAN સરનામા તરફ નિર્દેશ કરે. આ એ પગલું છે જે લોકો છોડી દે છે, કારણ કે NetBirdની અંદર દેખાતું બધું પહેલેથી કામ કરે છે જ્યારે સામાન્ય વર્કસ્ટેશન હજી સમય સમાપ્ત કરે છે. ગેટવે તેનો ડિફોલ્ટ રૂટ જેમ હતો તેમ રાખે છે; આ પ્રીફિક્સ ઉમેરો છે, બદલી નહીં.

બે રૂટ વર્ણનો દરેક સાઇટના પોતાના ગેટવે રૂપરેખાંકનમાં આવે છે, યજમાન પરના ઓવરરાઇડમાં નહીં. બંને સામાન્ય સ્થિર રૂટ છે, અને એક પણ ડિફોલ્ટ રૂટને સ્પર્શતું નથી:

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

પ્રોજેક્ટને ખરેખર જરૂરી એપ્લિકેશન સાથે, સામાન્ય વર્કસ્ટેશનથી કસોટી કરો અને ત્રણ વસ્તુઓ નોંધો: મોકલનાર બાજુ પર પસંદ કરાયેલો આગળનો હોપ, મેળ ખાતી નીતિ અને સેવાએ નોંધેલું સ્રોત સરનામું. ઇનકારની પણ કસોટી કરો, કારણ કે જે ડિઝાઇને ક્યારેય કંઈ નકાર્યું નથી તેની કિનારીઓ અજાણી છે, અને ઇનકાર એ જ એકમાત્ર પુરાવો છે કે રૂટિંગ નહીં પણ નીતિ કામ કરે છે. જ્યારે પૂર્વે પણ શરૂ કરવાનું હોય, ત્યારે બીજી દિશા અનુસરશે એમ માનવાને બદલે તે બાજુથી નવું જોડાણ શરૂ કરો. રૂટિંગ પીઅરના પુનઃપ્રારંભ, અપગ્રેડ અને બદલીનું પણ આયોજન કરો, કારણ કે એક યજમાન સાઇટની નિર્ભરતા બની ગયું છે.

ખાનગી નામોને પોતાની ઉકેલકર્તા ડિઝાઇનની જરૂર છે, કારણ કે પહોંચ DNS રેકોર્ડ બનાવતી નથી અને તૂટેલા નામ સાથેનો કાર્યકારી IP માર્ગ બરાબર તૂટેલા માર્ગ જેવો વંચાય છે. જો રૂટિંગ પીઅર ક્લાઉડ નેટવર્કમાં ચાલે, તો પ્રદાતાના ફોરવર્ડિંગ અને ફાયરવોલ નિયમોની પણ સમીક્ષા કરો, કારણ કે નોંધણી તેમને રદ કરતી નથી. કસોટીના અવલોકનો યોજનાની બાજુમાં રાખો, કારણ કે આગળ જે આને ડિબગ કરશે તેને ટોપોલોજીનું વર્ણન નહીં, મેળ ખાતી નીતિ અને નોંધાયેલું સ્રોત સરનામું જોઈશે.