WireGuard: સબનેટ બદલાવ પછી પીઅર સુધી કોઈ રૂટ નથી — બે રસ્તા
સબનેટ બદલાવ WireGuard ને બે જગ્યાએ તોડે છે: AllowedIPs અને પરતનો રસ્તો. જગ્યા પર ફરી નંબર આપવાની સરખામણી ઇન્ટરફેસ ફરી બનાવવા સાથે કરો.
wg show માં હેન્ડશેક તાજો છે, એન્ડપોઇન્ટ સાચો છે, કી ક્યારેય બદલાઈ નથી — અને ping હજી કહે છે કે પીઅર સુધી કોઈ રૂટ નથી. એક કલાક પહેલાં તમે ટનલનું સબનેટ બદલ્યું. એ લક્ષણ કીની સમસ્યા નહીં, પ્રીફિક્સની અસંગતિની નિશાની છે: WireGuard એ હેન્ડશેક પૂરો કર્યો અને પછી ડેટા કાઢી નાખ્યો, કારણ કે સ્રોત સરનામું હવે પ્રાપ્ત કરનાર પીઅર જે સ્વીકારશે તેની સાથે મેળ ખાતું નથી. સબનેટ બદલાવ લાગુ કરવાની બે વાજબી રીતો છે, અને તે જુદી જુદી જગ્યાએ નિષ્ફળ જાય છે.
બદલાવ લાગુ કરવાની બે રીતો, અને દરેકની કિંમત
વિકલ્પ A એ જગ્યા પર ફરી નંબર આપવો છે: ઇન્ટરફેસનું સરનામું, પીઅરની શ્રેણીઓ, રૂટ અને કોન્ફિગની દરેક નકલ સંપાદિત કરો, પછી ફરી લોડ કરો. વિકલ્પ B એ જૂનીની બાજુમાં નવા પ્રીફિક્સ પર બીજું ઇન્ટરફેસ બનાવવું, પીઅરને ત્યાં ખસેડવા અને ટ્રાફિક ખરેખર ખસી ગયા પછી જૂનું ઇન્ટરફેસ દૂર કરવું છે.
| A: renumber in place | B: parallel interface | |
|---|---|---|
| Downtime | The reload window, per host | None if peers are added to both |
| Rollback | Re-apply the previous files | Point peers back at the old interface |
| Risk | Half-applied change: new address, old ranges | Two live interfaces with overlapping intent |
| Effort | Small, if the deployment has one owner | Higher, and needs a cleanup step |
| Fits | Two or three peers you control | Many peers, remote sites, or no maintenance window |
અડધું લાગુ થયેલી સ્થિતિ જ વિકલ્પ A ને જોખમી બનાવે છે, કારણ કે તે તૂટેલું દેખાતું નથી. ઇન્ટરફેસ ઉપર આવે છે, હેન્ડશેક સફળ થાય છે, અને ફક્ત ડેટા માર્ગ નિષ્ફળ જાય છે. વિકલ્પ B વધુ કામ માંગે છે પણ જ્યાં સુધી તમે દરેક સંદર્ભ શોધો ત્યાં સુધી કાર્યરત માર્ગ જીવંત રાખે છે.
તમારા છેડે શું સાથે ખસેડવું પડશે
સ્થાનિક હોસ્ટ પરની ચાર વસ્તુઓ એક જ સબનેટ વર્ણવે છે, અને એકમાં ફેરફાર એ બધામાં ફેરફાર છે: ઇન્ટરફેસનું સરનામું, દરેક પીઅરનું AllowedIPs, સિસ્ટમ એ ગંતવ્યો માટે જે રૂટ વાપરે છે, અને મેનેજર તમારા વતી જે પણ સ્થાપિત કરે છે. wg-quick સાથે છેલ્લી બે દર વખતે ઇન્ટરફેસ ઉપર આવે ત્યારે કોન્ફિગમાંથી બને છે, તેથી જૂની નકલ શાંતિથી જૂનું પ્રીફિક્સ ફરી સ્થાપિત કરે છે.
બંનેમાંથી એક પર ભરોસો કરવાને બદલે કોન્ફિગર કરેલાની તુલના જીવંત સાથે કરો:
wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5રૂટ શોધ એ પગલું છે જે લોકો છોડી દે છે. તે જવાબ આપે છે કે કર્નલ કોઈ ગંતવ્ય માટે ખરેખર શું કરશે, જેમાં મેનેજર કે કન્ટેનર રનટાઇમે છોડેલો વધુ ચોક્કસ રૂટ પણ સામેલ છે. જો તે ટનલ કરતાં અલગ ઇન્ટરફેસ બતાવે, તો કોન્ફિગ સમસ્યા નથી.
ચાલુ ઇન્ટરફેસ માટે, ટનલ તોડ્યા વિના સંપાદિત ફાઇલ લાગુ કરો:
wg syncconf wg0 <(wg-quick strip wg0)તે પીઅર અને શ્રેણીઓને જગ્યા પર જ અપડેટ કરે છે. તે ઇન્ટરફેસનું સરનામું કે રૂટ અપડેટ કરતું નથી, કારણ કે તે WireGuard સેટિંગ્સ નથી — તેથી ફરી નંબર આપવા માટે હજી ઇન્ટરફેસ ફરી બનાવવું અથવા ip વડે સરનામું બદલવું, અને પછી રૂટિંગ ફરી ચકાસવું પડે છે.
દૂરના છેડે શું સાથે ખસેડવું પડશે
અહીં જ સામાન્ય રીતે સબનેટ બદલાવ મરે છે. AllowedIPs ફક્ત રૂટિંગ સંકેત નથી; તે સ્રોત સરનામાંની યાદી પણ છે જે પીઅર રજૂ કરી શકે છે. જ્યારે તમે ક્લાયન્ટને ફરી નંબર આપો અને સર્વરનું AllowedIPs જૂના પ્રીફિક્સ પર રહેવા દો, ત્યારે સર્વર હેન્ડશેક સ્વીકારે છે, એન્ક્રિપ્ટેડ પેકેટ મેળવે છે અને તેમને ફેંકી દે છે કારણ કે અંદરનો સ્રોત તે પીઅર સાથે જોડેલી કોઈ પણ શ્રેણી સાથે મેળ ખાતો નથી. કોઈ ભૂલ લોગ થતી નથી, અને ક્લાયન્ટ સમયસીમા જુએ છે.
તેથી પ્રાપ્ત કરનાર છેડો સભાનપણે અપડેટ કરો: સર્વર પરની પીઅર એન્ટ્રીમાં નવું ક્લાયન્ટ પ્રીફિક્સ હોવું જોઈએ, સર્વરનો પોતાનો પરત રૂટ તે પ્રીફિક્સ માટે ટનલ તરફ નિર્દેશ કરવો જોઈએ, અને સર્વર પાછળના કોઈ પણ ડાઉનસ્ટ્રીમ નેટવર્કે નવો માર્ગ શીખવો જોઈએ. જૂની શ્રેણીનું નામ આપતી ફાયરવોલ નીતિને પણ એ જ સારવાર જોઈએ, અને સ્રોત આધારિત પસંદગી કરતી કોઈ પણ વસ્તુને પણ.
બે નિષ્ફળતાઓને અલગ પાડતું નિદાન સસ્તું છે. તાજો હેન્ડશેક પણ ડેટા નહીં એટલે ટનલ ઉપર છે અને અંદરનું સરનામાંકન મળતું નથી. બિલકુલ હેન્ડશેક ન હોવો એટલે તમે પહોંચ કે કી તરફ જોઈ રહ્યા છો. પ્રીફિક્સ સમસ્યા માટે કી ફેરવશો નહીં; તે એકમાત્ર વસ્તુને રીસેટ કરે છે જે કામ કરતી હતી.
તમારા સંપાદન કરતાં વધુ ટકતી જૂની નકલો
ફાઇલ સંપાદિત કરવી એ ચાલુ સિસ્ટમ બદલવા જેવું નથી, અને નકલો લોકો ધારે તેનાથી વધુ હોય છે: ઇન્ટરફેસનો માલિક યુનિટ કે મેનેજર, બીજી ડિરેક્ટરીમાં એ જ નામની બીજી પ્રોફાઇલ, ઇમેજમાં કોન્ફિગ બેક કરેલું કન્ટેનર, પોતાનું સંપાદિત સંસ્કરણ રાખતું રાઉટર UI, અને શરૂ થતાં સાચવેલી ટનલ ફરી આયાત કરતી ક્લાયન્ટ એપ. તમારો ફેરફાર પૂર્ણ દેખાયા પછી પણ દરેક જૂનું પ્રીફિક્સ પાછું લાવી શકે છે.
નામ પણ મુસાફરી કરે છે. જો સંખ્યાત્મક રૂટ કામ કરે પણ હોસ્ટનામ નિષ્ફળ જાય, તો આંતરિક DNS રેકોર્ડ કે સેવા કોન્ફિગ હજી જૂના ટનલ સરનામા તરફ નિર્દેશ કરે છે. દરેક પીઅર શ્રેણી પહોળી કરવાને બદલે સંદર્ભ સુધારો, કારણ કે તે ખરી સમસ્યા ઢાંકી દેશે અને તે જ સમયે સ્રોત ACL મોટું કરશે.
કામ કરતી વખતે એક પુનઃપ્રાપ્તિ માર્ગ ખુલ્લો રાખો: હોસ્ટમાં પ્રવેશવાનો બીજો રસ્તો, સીરિયલ કન્સોલ, અથવા કોન્ફિગ ફાઇલોનું નિર્ધારિત રોલબેક. જે ટનલ ફેરફાર તમને તમે બદલી રહ્યા છો તે મશીનની બહાર લોક કરે છે, તે આ કામને સાંજમાં ફેરવવાનો સૌથી સામાન્ય રસ્તો છે.
બેમાંથી પસંદગી, અને કટની ચકાસણી
A પસંદ કરો જ્યારે દરેક પીઅર તમારું હોય, સંખ્યા નાની હોય, અને ટૂંકું વિક્ષેપ સ્વીકાર્ય હોય. B પસંદ કરો જ્યારે પીઅર દૂરના હાથ હોય જેને તમે નિયંત્રિત કરતા નથી, જ્યારે સાઇટ-થી-સાઇટ લિંક ચાલુ રહેવી જોઈએ, અથવા જ્યારે તમે ખાતરી આપી શકતા નથી કે દરેક નકલ એક જ પાસમાં અપડેટ થશે. તે કિસ્સામાં નવું પ્રીફિક્સ બંને ઇન્ટરફેસમાં ઉમેરો, પીઅરને એક પછી એક ખસેડો, નવા પર ટ્રાફિક જુઓ, અને પછી જ જૂનું ઇન્ટરફેસ અને તેના રૂટ દૂર કરો.
બંને વિકલ્પોમાં, બદલાવ ત્યારે પૂરો થાય છે જ્યારે ચાર તપાસ પસાર થાય: હેન્ડશેક તાજો છે, નવા પ્રીફિક્સના ગંતવ્ય માટે રૂટ શોધ ટનલનું નામ લે છે, થોડા સો બાઇટનો પેલોડ બંને દિશામાં જાય છે, અને હોસ્ટ કે મેનેજર ફરી શરૂ કર્યા પછી પણ એ જ રહે છે. માટે wg(8) માર્ગદર્શિકા દરેક દિશામાં AllowedIPs નો અર્થ શું છે તેનો સંદર્ભ છે, અને લક્ષણ અદૃશ્ય કરવા શ્રેણી પહોળી કરતાં પહેલાં તેને ફરી વાંચવા યોગ્ય છે.
- તાજો હેન્ડશેક અને ડેટા નહીં: કીને અડકતાં પહેલાં પ્રાપ્તકર્તા પાસે AllowedIPs જુઓ.
- રૂટ શોધ ખોટું ઇન્ટરફેસ બતાવે છે: રૂટનો માલિક મેનેજર કે કન્ટેનર છે, તમારી ફાઇલ નહીં.
- સંખ્યાત્મક સરનામું ઠીક અને હોસ્ટનામ તૂટેલું: જૂનો સંદર્ભ, રૂટિંગ લૂપ નહીં.
- બદલાવ ત્યારે જ પૂરો છે જ્યારે ફરી શરૂ કર્યા પછી પણ નવું પ્રીફિક્સ વપરાય છે.