WireGuard રૂપરેખાને લીટી-દર-લીટી વાંચો, Interface થી Peer સુધી

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

Interface કી આ મશીનનું વર્ણન કરે છે

interface બ્લોક આ છેડાની પોતાની ઓળખ રાખે છે. PrivateKey એ ઓળખ છે અને ક્યારેય હોસ્ટ છોડતી નથી; તેમાંથી અનુરૂપ જાહેર કી મેળવાય છે અને બીજા peers એ જ સૂચિબદ્ધ કરે છે. ListenPort અહીં આ બાજુ હેન્ડશેક સ્વીકારે છે, તેથી એક સરનામા પાછળના બે ક્લાયન્ટને અલગ પોર્ટ જોઈએ.

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

વાસ્તવિક ક્લાયન્ટ સાથે [Interface] બ્લોકમાં બાકીનું બધું સામાન્ય રીતે wg-quick ઉમેરે છે: DNS, MTU, Table, અને હૂક લીટીઓ. આ પ્રોટોકોલ ક્ષેત્રો નથી, અને નકરું wg સેટઅપ તેમને સંપૂર્ણ અવગણે છે.

દરેક peer એન્ટ્રી બીજી એક બાજુનું વર્ણન કરે છે

[Peer] બ્લોક દૂરનો પક્ષ છે. PublicKey તે પક્ષની મેળવેલી કી છે, ક્યારેય તેમની ખાનગી કી નહીં, અને PresharedKey વૈકલ્પિક વધારાનું રહસ્ય છે જે બંને બાજુએ એકસરખું રાખવું પડે. Endpoint ક્યાં મોકલવું તે છે, અને PersistentKeepalive આ હોસ્ટને કહે છે કે અંતરાલ પછી પેકેટ મોકલે જ્યારે બીજું કંઈ બહાર જતું ન હોય.

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

AllowedIPs રૂટિંગ છે, પરવાનગીની યાદી નહીં

AllowedIPs એ WireGuardનું ક્રિપ્ટોકી રૂટિંગ છે. બહારની દિશામાં, તે ગંતવ્યના આધારે નક્કી કરે છે કે કયો peer પેકેટ મેળવે. અંદરની દિશામાં, તે સ્રોતના આધારે નક્કી કરે છે કે તે peer તરફથી આવતું પેકેટ સ્વીકારવું કે નહીં. એક જ ક્ષેત્ર બંને કામ કરે છે, તેથી તે એક્સેસ-નિયંત્રણ યાદી નથી અને મંજૂર વેબસાઇટોની યાદી પણ નથી.

સાંકડું AllowedIPs સર્વર પર ક્લાયન્ટ માટે એટલે કે સર્વર ફક્ત એ સ્રોતોનો દાવો કરતા પેકેટ સ્વીકારશે, અને ફક્ત એ ગંતવ્યો તે ક્લાયન્ટને મોકલશે. એક બાજુ પહોળી કરો બીજી કર્યા વિના, અને તમને એવી ટનલ મળે છે જે ઉપર આવે છે અને કંઈ પસાર કરતી નથી.

wg-quick પ્રોટોકોલની આસપાસ શું ઉમેરે છે

wg-quick એ જ ફાઇલ વાંચે છે અને પ્રોટોકોલ ઓપરેટિંગ સિસ્ટમને સોંપેલા નેટવર્ક પગલાં કરે છે. તે interface સરનામું સોંપે છે, AllowedIPs થી મેળવેલા રૂટ ઉમેરે છે, રિઝોલ્વર સેટિંગ્સ લખે છે અને હૂક આદેશો ક્રમમાં ચલાવે છે.

એ સ્તર પારંપરિક અસમમિતિ સમજાવે છે. 0.0.0.0/0 અને DNS લીટી ધરાવતી ફાઇલ ક્લાયન્ટને ડિફોલ્ટ રૂટ અને રિઝોલ્વર આપે છે, અને સર્વરના ફોરવર્ડિંગ કે NAT નિયમોને કંઈપણ કરતી નથી. એ સર્વરની પોતાની રૂપરેખાના છે, અને કોઈ ક્લાયન્ટ ફાઇલ તે આપી શકતી નથી.

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

ફાઇલ નહીં, લાગુ થયેલી સ્થિતિ તપાસો

ફાઇલ એક ઇરાદો છે. લાગુ થયેલી સ્થિતિ એ છે જે કર્નલ રાખે છે, અને સક્રિયકરણ પછી કોઈ સહાયક, drop-in કે હૂકે કંઈક સંપાદિત કર્યું હોય ત્યારે બંને અલગ પડે છે.

જીવંત સ્થિતિ અને સરનામાંકન સાથે વાંચો, પછી બંનેને તમે લખ્યું તેની સાથે સરખાવો:

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

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