WireGuard માં હોસ્ટ પ્રીફિક્સ: એક સરનામું કેમ કામ કરે છે અને બાકીના નહીં
ઇન્ટરફેસ પર /32 માન્ય હોસ્ટ પ્રીફિક્સ છે અને ફક્ત તે જ એક સરનામું રૂટ કરે છે. AllowedIPs સૂચવે છે તે રૂટ ઉમેરો, પછી પાછળનો રસ્તો ચકાસો.
ટનલ ચાલુ છે, handshake દર બે મિનિટે થાય છે, અને બીજી બાજુએ બરાબર એક સરનામું જવાબ આપે છે. પીઅરના ટનલ સરનામા પર ping કામ કરે છે; તેની પાછળ કંઈ કામ કરતું નથી. કોઈ ઇન્ટરફેસની ગોઠવણી વાંચે છે, હોસ્ટ પ્રીફિક્સ જુએ છે અને નિષ્કર્ષ કાઢે છે કે માસ્ક ખોટું છે. તેને /24 સુધી પહોળું કરવાથી ping થોડા સમય માટે ઠીક થાય છે અને પછી બીજું કંઈક તૂટે છે. પ્રીફિક્સ ક્યારેય કારણ નહોતું, અને ગુમ રૂટ એ નથી જેને માસ્ક નિયંત્રિત કરે છે.
ઇન્ટરફેસ પ્રીફિક્સ ખરેખર શું બનાવે છે
Linux માં ઇન્ટરફેસને સરનામું આપવાથી તે પ્રીફિક્સ માટે જોડાયેલો રૂટ બને છે. હોસ્ટ પ્રીફિક્સ આપો તો જોડાયેલો રૂટ એક સરનામું આવરે છે. /24 આપો તો તે 256 આવરે છે, અને તેમાંથી દરેક હવે તે લિંક પર પહોંચી શકાય તેવું ગણાય છે.
ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1
હોસ્ટ પ્રીફિક્સ પોઇન્ટ-ટુ-પોઇન્ટ ટનલ માટે સંપૂર્ણ સામાન્ય પસંદગી છે, કારણ કે બીજા છેડે બરાબર એક પીઅર હોય છે. ત્રીજો આદેશ તે જ છે જે વપરાશકર્તાના પ્રશ્નનો જવાબ આપે છે: તે કહે છે કે કર્નલ તે લક્ષ્ય માટે કયું ઇન્ટરફેસ વાપરશે, અને જો કોઈ રૂટ મેળ ન ખાય તો તે કંઈ ઉપયોગી બતાવશે નહીં.
લક્ષણની આખી સમજૂતી આ જ છે. એક સરનામું જવાબ આપે છે કારણ કે તેના માટે જોડાયેલો રૂટ છે, અથવા કારણ કે પીઅરની પરવાનગીવાળી યાદી સંયોગવશ તેને સમાવે છે. બાકીના બધાનો કોઈ રૂટ નથી અને WireGuard સામેલ થાય તે પહેલાં જ તે ફેંકી દેવાય છે. ટનલ આખા સમય દરમિયાન સ્વસ્થ રહે છે, તેથી જ handshake કાઉન્ટર આશ્વાસન આપતું દેખાતું રહે છે.
AllowedIPs એક નામ હેઠળ બે નિયમો છે
WireGuard ની પ્રતિ-પીઅર પરવાનગીવાળી યાદી એક સાથે બે કામ કરે છે, અને ગોઠવણીની રચના તેમને એક જેવા દેખાડે છે. અંદર આવતી વખતે તે નક્કી કરે છે કે પીઅર કયા સ્રોત સરનામાં રજૂ કરી શકે. બહાર જતી વખતે તે પસંદ કરે છે કે પેકેટ કયા પીઅરને મોકલવું, સૌથી ચોક્કસ મેળ શોધીને.
આ બંનેમાંથી કોઈ કામ રૂટિંગ નથી. કર્નલને હજી પણ નક્કી કરવું પડે છે કે પેકેટ ટનલ ઇન્ટરફેસનું છે, તે પહેલાં કે WireGuard તેને જુએ, અને આ નિર્ણય રૂટિંગ કોષ્ટકમાંથી આવે છે. પહોળી પરવાનગીવાળી યાદીવાળી પીઅર નોંધ પોતાની રીતે કોઈ રૂટ સ્થાપિત કરતી નથી.
તેથી જ કોઈ ગોઠવણી પૂર્ણ દેખાઈ શકે છે અને અસમમિત વર્તન કરી શકે છે. ક્લાયન્ટ બીજી બાજુ મોકલે છે કારણ કે રૂટ છે, અને જવાબો ક્યારેય પહોંચતા નથી કારણ કે બીજી બાજુની પરવાનગીવાળી યાદી ક્લાયન્ટના સ્રોતને પરવાનગી આપતી નથી, અથવા કારણ કે બીજી બાજુનો પાછળનો રસ્તો નથી. બંને દિશાઓ અલગ નિર્ણયો છે અલગ નિષ્ફળતાની રીતો સાથે. તમે કઈ ચકાસી રહ્યા છો તે લખવું નિદાનનો અડધો ભાગ છે.
રૂટ ક્યાંથી આવે છે
જો તમે wg-quick વાપરો છો, તો રૂટ તમારા માટે દરેક પીઅરની પરવાનગીવાળી યાદીમાંથી બને છે, સિવાય કે તમે Table = off સેટ કર્યું હોય અને નિયંત્રણ જાતે લીધું હોય. આ સાધનનું દસ્તાવેજી વર્તન છે, અને તેથી જ સ્પષ્ટ રૂટ સૂચનાઓ વગર પણ ગોઠવણી કામ કરે છે.
sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0
પરવાનગીવાળી યાદીની તુલના તે રૂટો સાથે કરો જે ખરેખર અસ્તિત્વમાં છે. જે પીઅર આખું સબનેટ પરવાનગી આપે છે પણ ફક્ત એક હોસ્ટ રૂટ બનાવે છે, તેનો અર્થ સહાયક ક્યારેય ચાલ્યો નહોતો, અથવા તમે ઇન્ટરફેસ સીધું wg અને ip વડે ચલાવો છો, અને પછી તમારા માટે કોઈ રૂટ બનાવતું નથી.
જ્યારે તમે તેને હાથથી ચલાવો છો, ત્યારે રૂટ એક લીટી છે અને તેનો આકાર સ્પષ્ટ છે: લક્ષ્ય ઇન્ટરફેસ દ્વારા, ગેટવે વગર કારણ કે લિંક પોઇન્ટ-ટુ-પોઇન્ટ છે. તેને ઉમેરવું ખરાબ પ્રીફિક્સ માટે કોઈ બચાવ નથી; તે એવી રચનાનો ગુમ અડધો ભાગ છે જેણે રૂટિંગ જાતે લીધું.
પહોળું પ્રીફિક્સ પીઅર નોંધ ઉમેરતું નથી
લલચાવતો સુધારો એ છે કે સરનામું /24 કરી દેવાય જેથી જોડાયેલો રૂટ સર્વરના સ્થાનિક નેટવર્કને આવરે. તે કામ કરતું લાગે છે, અને કામ કરતું લાગવાનું કારણ એ છે કે જોડાયેલો રૂટ હવે મેળ ખાય છે, નહીં કે WireGuard એ કંઈ નવું શીખ્યું.
તમે એ પણ કર્યું કે આખી શ્રેણીને તે લિંક પર સીધી પહોંચી શકાય તેમ જાહેર કર્યું, જેમાં એ સરનામાં પણ છે જે બીજા પીઅરના છે અથવા એવા સ્થાનિક નેટવર્કના જે ખરેખર સર્વરની પાછળ છે. તે સરનામાં તરફનો ટ્રાફિક હવે ટનલમાં જાય છે, અને તે બીજી બાજુથી નીકળે છે કે નહીં તે સર્વરની પોતાની રૂટિંગ અને પરવાનગીવાળી યાદીઓ પર આધાર રાખે છે.
ક્રિપ્ટો બાજુ કોઈ પણ સ્થિતિમાં અસર પામતી નથી. WireGuard ને પીઅર પસંદ કરવા માટે પરવાનગીવાળી યાદીમાં લક્ષ્યને આવરતી નોંધ હજી પણ જોઈએ, અને બીજી બાજુને તમારો સ્રોત સ્વીકારવા માટે તેને આવરતી નોંધ હજી પણ જોઈએ. પહોળું ઇન્ટરફેસ પ્રીફિક્સ આમાંથી એક પણ આપી શકતું નથી.
કંઈ બદલતા પહેલાં બંને દિશાઓની પુષ્ટિ કરો
બંને છેડા અલગ લો અને દરેક શું કહે છે તે લખો. ક્લાયન્ટ પર રૂટ અને પીઅર નોંધ; સર્વર પર અરીસાની છબી અને તેનો પોતાનો પાછળનો રસ્તો:
ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10
કૅપ્ચર એ જ છે જે દિશા વિશેના વિવાદો ઉકેલે છે. જો બહાર જતા પેકેટ ટનલ ઇન્ટરફેસ પર દેખાય અને સર્વર કંઈ નોંધે નહીં, તો દૂરનો છેડો તેમને નકારી રહ્યો છે, સામાન્ય રીતે કારણ કે તમારો સ્રોત તેની પરવાનગીવાળી યાદીની બહાર છે. જો બિલકુલ કંઈ દેખાય નહીં, તો રૂટ ગુમ છે અથવા બીજે ક્યાંક નિર્દેશ કરે છે.
પછી સૌથી સાંકડો છેડો સુધારો. સર્વરની બાજુ તમારા ક્લાયન્ટ સરનામા માટે પરવાનગીવાળી યાદીમાં નોંધ અને ક્લાયન્ટની બાજુ લક્ષ્ય સબનેટ માટે નોંધ સામાન્ય આકાર છે, અને તે ઇન્ટરફેસ પ્રીફિક્સને અડતું નથી. પ્રીફિક્સ ફક્ત ત્યારે જ પહોળું કરો જ્યારે સરનામા યોજના ખરેખર તે લિંક પર વહેંચાયેલું સબનેટ ઈચ્છે, અને તેને ડિબગિંગ પગલાને બદલે યોજના ફેરફાર તરીકે કરો.