WireGuard 5G શાખા: શાખા પોતે હબને કૉલ કરે

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

તેને જાણી જોઈને ગોઠવો અને પછી જે ભાગ લોકો ધારે છે કે કામ કરે છે તે ચકાસો. બંને પગલાંમાં મિનિટો લાગે છે, અને આ ડિઝાઇન સામાન્ય રીતે બીજામાં નિષ્ફળ જાય છે.

કઈ બાજુ સ્થિર એન્ડપોઇન્ટ રાખે છે

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

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

શાખાને એવું રૂપરેખાંકન આપો જે ફરી નંબરિંગ ઝીલી શકે

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

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

પચ્ચીસ સેકન્ડ એ NAT મેપિંગ સજીવ રાખવા માટે વારંવાર ટાંકવામાં આવતું ઉદાહરણ છે, દરેક પીઅર માટે ફરજિયાત નહીં. તમે ખરેખર જે મેપિંગ ટાઇમઆઉટ જુઓ છો તેના આધારે તે સેટ કરો, અને યાદ રાખો કે ઇન્ટરફેસ ચાલુ હોય ત્યાં સુધી તે ડેટા-મર્યાદિત લિંક પર ટ્રાફિક પેદા કરે છે.

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

મેપિંગ અને ફેલઓવર ચકાસો

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

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

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

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

આ ડિઝાઇન શું હલ કરતું નથી

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

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

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