બે સાઇટના WireGuard હબ માટે IPv6 આયોજન: પ્રીફિક્સ, પીઅર્સ, રૂટ્સ
બે LAN માટે ખાનગી IPv6 હબ પર કામ કરો: પ્રીફિક્સ પસંદ કરો, ટનલ સરનામાં અનામત રાખો, પછી AllowedIPs ને જણાવવા દો કે કયો પીઅર કઈ સબનેટ ધરાવે છે.
બે LAN, એક WireGuard હબ અને એક IPv6 સરનામા યોજના જેને ત્રણ અલગ પ્રશ્નોના જવાબ આપવા પડશે: કયો પ્રીફિક્સ, કયું સરનામું કયા રાઉટરનું છે અને કયો પીઅર કઈ સબનેટ ધરાવે છે. એમાંથી એક પણ ખોટું હોય તો એવી ટનલ બને છે જે હેન્ડશેક કરે છે અને કંઈ રૂટ કરતી નથી. નીચેની યોજના એ જ ક્રમમાં ખાનગી બે-સાઇટ ડિઝાઇન પર કામ કરે છે. તે જાણી જોઈને IPv6 ઇન્ટરનેટ ઍક્સેસ આપતી નથી.
નક્કી કરો કે પ્રીફિક્સ શેના માટે છે
જ્યારે ધ્યેય સાઇટ્સ વચ્ચે ખાનગી પહોંચ હોય ત્યારે fd00::/8 માંથી અનન્ય-સ્થાનિક પ્રીફિક્સ સ્વાભાવિક પસંદગી છે. દરેક સ્થળને કયો ISP સેવા આપે છે તેનાથી સ્વતંત્ર રહીને તે સ્થિર રહે છે અને વૈશ્વિક રૂટિંગ કોષ્ટકમાં જાહેર થતું નથી, તેથી તે તમારી આંતરિક નંબરિંગને ઇન્ટરનેટ પર લીક કરી શકતું નથી.
એ જ ગુણધર્મ મર્યાદા છે. ULA કોઈ જાહેર પરત માર્ગ આપતું નથી, કારણ કે કોઈ અપસ્ટ્રીમ તેને તમારા ગેટવે તરફ રૂટ કરવાનું જાણતું નથી. જો જરૂરિયાતમાં IPv6 ઇન્ટરનેટ ઇગ્રેસ સામેલ હોય, તો તમને જરૂર છે એવા પ્રદાતા તરફથી ફાળવણી જે તેને તમારા સુધી રૂટ કરે, અને તે પોતાના પ્રીફિક્સ કદ સાથેનો અલગ ડિઝાઇન નિર્ણય છે.
ધારો નહીં કે દરેક ડિપ્લોયમેન્ટને /48 ની જરૂર છે. RFC 6177 એક જ ફરજિયાત અંતિમ-સાઇટ કદથી દૂર ગયું છે, અને યોગ્ય કદ તમે ચલાવશો તે નેટવર્કની સંખ્યા પર આધાર રાખે છે. બીજી સંસ્થા પણ વાપરી શકે એવો પ્રીફિક્સ શોધવાને બદલે RFC 4193 પ્રક્રિયા સાથે ULA બનાવો. કોઈપણ ઉપકરણ ગોઠવાય તે પહેલાં પરિણામ સરનામા યોજનામાં લખો, કારણ કે જે પ્રીફિક્સ કોઈએ નોંધ્યું નથી તે પ્રીફિક્સ કોઈ ફરી વાપરશે.
પ્રીફિક્સને ભૂમિકાઓમાં વિભાજિત કરો
નીચેનું ઉદાહરણ fd7c:2e91:4a00::/48 વાપરે છે, અને કોષ્ટક સાઇટ પ્રમાણે નહીં, પણ દરેક બ્લોક ક્યાં લખાય છે તે પ્રમાણે ગોઠવાયેલું છે. મૂલ્યોને નમૂનો ગણો અને કંઈપણ ડિપ્લોય કરતા પહેલાં તમારા પોતાના બનાવો.
| Where it is written | What appears there | Block used | What it establishes |
|---|---|---|---|
| Hub wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::1/128 | The hub's own tunnel identity |
| Hub wg0.conf, Site A peer | Two ranges in one AllowedIPs line | ::2/128 and :10::/64 | That A owns its tunnel address and its LAN |
| Hub wg0.conf, Site B peer | Two ranges in one AllowedIPs line | ::3/128 and :20::/64 | That B owns its tunnel address and its LAN |
| Site A wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::2/128 | A's identity as the hub sees it |
| Site B wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::3/128 | B's identity as the hub sees it |
LAN બ્લોકો /64 છે કારણ કે સામાન્ય SLAAC 64-બિટ ઇન્ટરફેસ ઓળખકર્તા ધારે છે. LAN ને નાના બ્લોકમાં વિભાજિત કરવાથી મોટાભાગના હોસ્ટ પર તે ધારણા તૂટે છે, અને ખાનગી યોજનામાં સરનામાંની બચત માટે ઓપરેશનલ ખર્ચ યોગ્ય નથી. બંને LAN બ્લોક /48 ના મધ્યમાંથી આવે છે, જેથી નીચી શ્રેણી પછીની સાઇટ્સ માટે મુક્ત રહે.
ટનલ સરનામાં વહીવટી ભંડાર છે, લિંક પરનું નેટવર્ક નહીં. દરેક ઇન્ટરફેસ તેમાંથી એક /128 મેળવે છે, તેથી કોઈ હોસ્ટ ટનલ પર વહેંચાયેલી સબનેટ ધારતું નથી અને જ્યાં જરૂર નથી ત્યાં પડોશી શોધ ચાલતી નથી. ભૂમિકાઓ અલગ રાખો અને તેમને સંસ્થાની સરનામા યોજનામાં નોંધો જેથી પછીની સાઇટ બ્લોક ફરી ન વાપરે.
દરેક રાઉટરને એક ટનલ સરનામું આપો
દરેક રાઉટર માટે એક /128 ફાળવો અને કાર્યરત હબની હાલની કી અને એન્ડપોઇન્ટ રાખો. નીચેનાં ત્રણ મૂલ્યો ફક્ત હોસ્ટ ભાગમાં અલગ પડે છે.
Hub: Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128આ /128 તે ઇન્ટરફેસને ફાળવેલા એક જ સરનામાનું વર્ણન કરે છે. પીઅર કેટલા ગંતવ્યો રૂટ કરી શકે તે વિશે તે કંઈ કહેતું નથી, કારણ કે પહોંચ ઇન્ટરફેસ પ્રીફિક્સમાં નહીં, AllowedIPs માં વ્યક્ત થાય છે.
દરેક સાઇટ રાઉટરને તેના LAN બ્લોકમાં સરનામું અને તેને વહેંચવાની રીત પણ જોઈએ, સામાન્ય રીતે SLAAC માટે રાઉટર જાહેરાતો. WireGuard તમારા વતી તે જાહેરાતો મોકલતું નથી અને બે LAN ને બ્રિજ કરતું નથી. સાઇટ રાઉટર બંને દિશામાં રાઉટર છે.
સબનેટ માલિકી AllowedIPs માં મૂકો
સાઇટ A માટે હબની પીઅર એન્ટ્રી A ના ટનલ સરનામા અને A ના LAN ની માલિક છે, અને તે જોડી આખું માલિકી નિવેદન છે. તે પીઅર વિભાગમાં બીજું કંઈ સાઇટનું વર્ણન કરવાની જરૂર નથી.
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64સાઇટ B માટેની પીઅર એન્ટ્રી મેળ ખાતી જોડીની માલિક છે, અને અહીં સમપ્રમાણતા સંક્ષિપ્તતા કરતાં વધુ મહત્વપૂર્ણ છે. બંને લીટીઓ સાથે વાંચો અને માલિકીનું વિભાજન એક નજરમાં દેખાય છે.
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64આ બે અલગ પીઅર વિભાગો છે, એક પીઅર માટે સ્પર્ધા કરતી બે યાદીઓ નહીં. WireGuard AllowedIPs ને બંને દિશામાં વાપરે છે: તે બહાર જતા ગંતવ્ય માટે પીઅર પસંદ કરે છે, અને જે પેકેટનો સ્રોત તેને ડિક્રિપ્ટ કરનાર પીઅરને ફાળવેલી શ્રેણી સાથે મેળ ખાતો નથી તેને નકારે છે. બંને પીઅર્સને આખું /48 આપવાથી તે બીજી ચકાસણી બંધ થઈ જાય અને કઈ સાઇટ કયો બ્લોક ધરાવે તે અસ્પષ્ટ બને. એ જ ભેદ ખોટા સ્રોત સરનામાને ચૂપચાપ સ્વીકારવાને બદલે દેખાય તેમ બનાવે છે.
દરેક સાઇટને ફક્ત તેના હબ પીઅર દ્વારા પહોંચી શકાય તેવાં ગંતવ્યોની જરૂર છે: સાઇટ A હબનું સરનામું, સાઇટ B નું ટનલ સરનામું અને B નું LAN સૂચિબદ્ધ કરે છે, અને સાઇટ B તેની વિરુદ્ધ ગણ સૂચિબદ્ધ કરે છે. યાદીઓ જાણી જોઈને અસમપ્રમ છે, કારણ કે દરેક રાઉટર ટોપોલોજીની અલગ બાજુ જુએ છે. બંને સરનામા યોજનામાંથી લખો, બીજી સાઇટના રૂપરેખાંકનમાંથી નહીં, કારણ કે એ રીતે જૂની શ્રેણી ફરી-નંબરિંગમાં ટકી રહે છે.
wg-quick સાથે આ શ્રેણીઓ રૂટ્સ પણ બનાવે છે. systemd-networkd અથવા જાતે સેટઅપ સાથે સમકક્ષ રૂટ્સ જાતે ઉમેરો; નહીં તો ટનલ એવા પેકેટ લઈ જાય છે જે કર્નલ ક્યારેય તેમાં મોકલતું નથી.
ફોર્વર્ડિંગ પૂર્ણ કરો અને બંને દિશા ચકાસો
હબ પર અને બંને સાઇટ રાઉટર પર IPv6 ફોર્વર્ડિંગ સક્ષમ કરો, અને ફોર્વર્ડ નીતિમાં જરૂરી આંતર-સાઇટ સેવાઓને મંજૂરી આપો. ICMPv6 Packet Too Big સંદેશાઓ વાપરી શકાય તેમ રાખો, કારણ કે તેમને છોડી દેવાથી પાથ MTU શોધ તૂટે છે અને એપ્લિકેશન ખામી જેવા દેખાતા મોટા ટ્રાન્સફરના અટકાવ ઊભા થાય છે. ફાયરવોલ મંજૂરી વગર ફોર્વર્ડ કરતું હબ રૂટિંગ અને ટનલ વચ્ચે પેકેટ છોડી દે છે. એ નિષ્ફળતાનો પ્રકાર જાણવા જેવો છે, કારણ કે ટનલ ચાલુ રહે છે અને ફક્ત કેટલાક ફ્લો મરે છે.
sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1સાઇટ A ના હોસ્ટથી સાઇટ B ના હોસ્ટ સુધી અને પછી વિરુદ્ધ દિશામાં ચકાસો. હબના ટનલ સરનામા પરનું ping ફક્ત પ્રથમ હોપ કસે છે અને LAN રૂટ્સ ખોટા હોય તો પણ પસાર થશે. હોસ્ટથી-હોસ્ટ ફ્લો એ જ છે જે યોજના સાબિત કરે છે.
બાહ્ય WireGuard જોડાણ IPv4 પર ચાલી શકે છે જ્યારે આંતરિક ટ્રાફિક IPv6 હોય, અને આ સ્વતંત્રતા સ્થળાંતર દરમિયાન ઉપયોગી છે. જો પછીથી વૈશ્વિક IPv6 ઇગ્રેસ ઉમેરાય, તો પ્રદાતાની ફાળવણી, સ્રોત સરનામા પસંદગી અને પરત રૂટિંગને નવા ડિઝાઇન પગલા તરીકે ફરી જુઓ; ઉપરની ખાનગી યોજના સાઇટ-થી-સાઇટ ટ્રાફિક માટે માન્ય રહે છે.