બે સેલ્યુલર સાઇટ, કોઈ ઇનબાઉન્ડ પોર્ટ નહીં: કામ કરતું હબ બનાવો

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

કોઈ પણ સાઇટને ડાયલ કરી શકાતું નથી, તેથી બંનેને બહાર ડાયલ કરવું પડશે

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

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

તમારી સામેની સાઇટના સરનામાંકન પ્રશ્નનો જવાબ બે આદેશો આપે છે. તેમને સાઇટના રાઉટર પર ચલાવો, તેની પાછળના લેપટોપ પર નહીં:

ip -4 addr show scope global
ip -6 addr show scope global

કોણ પીઅરની ઓળખાણ કરાવે છે અને કોણ પેકેટ લઈ જાય છે

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

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

દરેક સાઇટ માટે એક રૂટ, જેનો માલિક એક પીઅર છે

હબને દરેક સાઇટ માટે એક ટનલ, દરેકની પાછળ અલગ LAN પ્રીફિક્સ, અને દરેક પ્રીફિક્સ માટે એક રૂટ જોઈએ જે તેના માલિકનું નામ લે. ઉદાહરણમાં હબ 10.61.0.1 છે, સાઇટ A એ 10.61.0.11 છે જેનું LAN 10.60.10.0/24 છે, અને સાઇટ B એ 10.61.0.12 છે જેનું LAN 10.60.20.0/24 છે. નીચેનો દરેક રૂટ ટનલ ઇન્ટરફેસ તરફ નહીં, પ્રીફિક્સ ધરાવતા પીઅર તરફ નિર્દેશ કરે છે:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

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

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

ઓપરેટર દ્વારા દરેક મેપિંગ જીવંત રાખો

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

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

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

બંને દિશા સાબિત કરો, પછી પુનઃપ્રાપ્તિ સાબિત કરો

ચકાસણી દિશાત્મક છે, તેથી A થી B સુધીનું ping ડિઝાઇનનો અડધો ભાગ સાબિત કરે છે અને પરત માર્ગ વિશે કંઈ નહીં. હબ પર સમાન સ્રોત-જાગૃત શોધ સાથે જવાબ માર્ગ તપાસો, પછી બીજી બાજુથી પરીક્ષણનું પુનરાવર્તન કરો. નવા હેન્ડશેક પણ પુરાવામાં આવે છે, કારણ કે એક કલાક નિષ્ક્રિય ટનલ જૂનું મેપિંગ ચકાસી રહી હોઈ શકે છે:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

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