બે પીઅર સાથેની WireGuard કસોટી કેવી રીતે બનાવવી જે એક જ માર્ગ સાબિત કરે

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

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

કી, સરનામાં અને એકમાત્ર એન્ડપૉઇન્ટ

દરેક સિસ્ટમ પર કી જોડ બનાવો અને તેમની વચ્ચે ફક્ત જાહેર અડધા ભાગ ખસેડો. wg genkey | tee privatekey | wg pubkey > publickey એ દસ્તાવેજીકૃત એક-લીટી આદેશ છે, અને તે ખાનગી કીને એવી ફાઇલમાં રાખે છે જેને તમે પછી સુરક્ષિત કરી શકો છો. તમારી બીજી કોઈ પણ ગોઠવણીમાં ન દેખાતી શ્રેણીમાંથી ટનલ સરનામાં પસંદ કરો, જેમ કે 10.99.0.1/24 અને 10.99.0.2/24. કયું સરનામું કઈ મશીનનું છે તે લખી રાખો, કારણ કે પછીની દરેક ચકાસણી તે મેપિંગ પર આધાર રાખે છે.

ખાનગી કી ક્યારેય મુસાફરી કરતી નથી. જો કસોટીને એક કી બીજી બાજુ નકલ કરવાની જરૂર હોય, તો કસોટી પહેલેથી ખોટી ગઈ છે. જ્યારે બંને સિસ્ટમ NAT પાછળ હોય, ત્યારે ઓછામાં ઓછી એકને પહોંચી શકાય તેવો UDP પોર્ટ જોઈએ જ્યારે બીજી તરફ તેના તરફ ઇશારો કરતું Endpoint હોય, અને જાહેર સરનામું અને પોર્ટ તમારી નોંધમાં હોવા જોઈએ, 51820 વિશેના અનુમાનમાં નહીં.

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

wg સાથે જોડાયેલા ફીલ્ડ અને જે જોડાયેલા નથી

મુખ્ય ફીલ્ડ સમૂહ નાનો છે: Interface હેઠળ PrivateKey અને ListenPort, Peer હેઠળ PublicKey, AllowedIPs અને Endpoint. Address અને DNS wg પોતાને બદલે wg-quick સાથે જોડાયેલા છે, અને એ જ ગોઠવણી બીજા સાધનમાં જાય તે ક્ષણે આ ભેદ ડંખે છે.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs એક સાથે બે કામ કરે છે. તે પસંદ કરે છે કયા ગંતવ્યો ટનલમાં જાય, અને તે પીઅરને આગમન સમયે તે સ્રોત સરનામાં વાપરવાની અધિકૃતિ આપે છે. તેથી બીજી બાજુની પ્રતિબિંબી એન્ટ્રીએ તમારા ટનલ સરનામાને ચોક્કસ નામ આપવું પડે; ખોટા પીઅર માટે /32 રાઉટિંગ સમસ્યા તરીકે વંચાય છે અને અધિકૃતિ સમસ્યાની જેમ વર્તે છે. WireGuard ઝડપી શરૂઆત ફીલ્ડ નામો સરખાવવા હોય તો પ્રમાણભૂત શબ્દરચના સાથે એ જ બે-પીઅર આકાર બતાવે છે.

આઇકનને બદલે હેન્ડશેક વાંચવો

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

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

એક માન્ય સેવા સાબિત કરવી, પછી ઊલટી દિશા

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

ઊલટી દિશા પોતાના પરિણામ સાથે અલગ કસોટી તરીકે ચલાવો, કારણ કે બંને દિશાઓની ફાયરવૉલ અને AllowedIPs એન્ટ્રીઓ અલગ છે અને તેઓ સ્વતંત્ર રીતે નિષ્ફળ થઈ શકે છે. જો હેન્ડશેક કામ કરે અને વિનંતી ન કરે, તો સમસ્યા ટનલમાં નહીં પણ ડેટા માર્ગમાં છે: AllowedIPs, સાંભળતી સેવા, અથવા હોસ્ટ ફાયરવૉલ. ફોરવર્ડિંગ, NAT અથવા DNS ઉમેરતા પહેલા તેને સુધારો, નહીંતર ક્યારેય દોષિત ન હોય તેવી સુવિધા ડિબગ કરવામાં બપોર વીતી જશે.

આધારને સંદર્ભ તરીકે રાખવો

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

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