WireGuard સંપૂર્ણ ટનલ: AllowedIPs 0.0.0.0/0 પૂરતું નથી

પીઅરના AllowedIPs માં 0.0.0.0/0, ::/0 મૂકવું એ એ પગલું છે જે બધા યાદ રાખે છે, અને તે ફક્ત નક્કી કરે છે કે પીઅરને કયો ટ્રાફિક વહન કરવાની પરવાનગી છે. આ પ્રીફિક્સ કોઈ રૂટ બનાવતા નથી, બીજી બાજુ કંઈ ફોરવર્ડ કરતા નથી, અને દરેક એપ્લિકેશનના રિઝોલ્વરને જ્યાં હતું ત્યાં જ છોડી દે છે. સંપૂર્ણ ટનલ સંપૂર્ણ રહે તે માટે ચાર અલગ બાબતો એકસાથે સાચી હોવી જોઈએ, અને તેમને નીચેના ક્રમમાં તપાસવા શ્રેષ્ઠ છે, કારણ કે પછીની તપાસ પહેલાની તપાસને બચાવી શકતી નથી. નીચેની દરેક તપાસ એ હકીકત છે જે મશીનમાંથી વાંચી શકાય છે, એવી સેટિંગ નહીં જે લાગુ થઈ હશે એવી આશા રાખો.

પીઅર પ્રીફિક્સ શું પસંદ કરે છે, અને શું નહીં

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

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

ક્લાયન્ટને રૂટ કરવો, ફક્ત પીઅર યાદી નહીં

મેનેજરો જેમ કે wg-quick હોસ્ટનું રૂટિંગ ટેબલ તમારા વતી પ્રોગ્રામ કરે છે, એટલે જ બે સમાન રૂપરેખાંકન ફાઇલો ઇન્ટરફેસ કેવી રીતે ઉપર આવ્યું તેના આધારે અલગ વર્તે છે. ન્યૂનતમ પ્રોફાઇલ એક જ વારમાં વાંચી શકાય તેટલી ટૂંકી છે:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

કામ બે વિગતો ઉપાડે છે. Address ક્ષેત્ર એક હોસ્ટ પ્રીફિક્સ છે, ક્લાયન્ટ પોતાનું માને છે એવું સબનેટ નહીં, અને મેનેજર જ ડિફોલ્ટ AllowedIPsને ખરેખરા ડિફોલ્ટ રૂટમાં ફેરવે છે. એ જ ફાઇલને ip link અને wg setconf વડે ઉપર લાવો અને કોઈ રૂટ દેખાશે જ નહીં, જે તૂટેલી ટનલ જેવું લાગે છે અને વાસ્તવમાં રૂટિંગ પગલું છોડી દીધેલી તંદુરસ્ત ટનલ છે. wg-quick માર્ગદર્શિકા રૂટિંગ અને Table વર્તનનું દસ્તાવેજીકરણ કરે છે જે તે મેનેજરો ઉમેરે છે.

ફાઇલને બદલે પરિણામ વાંચો: ip route get 1.1.1.1 ટનલ ઇન્ટરફેસનું નામ આપવું જોઈએ, અને wg show હલતા ટ્રાન્સફર કાઉન્ટર સાથે તાજેતરનું હેન્ડશેક બતાવવું જોઈએ. રૂટ વિનાનું હેન્ડશેક એટલે મેનેજર ક્યારેય ચાલ્યું જ નહીં, અને પ્રોફાઇલ ફરી સંપાદિત કરવાથી તે ઠીક થશે નહીં. ઇન્ટરફેસને વપરાશકર્તા જેવી રીતે શરૂ કરશે તેમ શરૂ કરો, નહીં તો પરીક્ષણ તૈનાતીને બદલે તમારું શેલ માપશે.

એન્ડપોઇન્ટને ટનલની બહાર રાખવો

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

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

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

ગેટવે પર ફોરવર્ડિંગ અને પરત માર્ગ

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

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

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

DNS અને નિષ્ફળતાની સ્થિતિ, અલગથી પરીક્ષણ

પ્રોટોકોલ પોતે કોઈ પણ એપ્લિકેશનનું રિઝોલ્વર ગોઠવતું નથી. wg-quick વિતરણના રિઝોલ્વર એકીકરણ દ્વારા લીટી DNS લાગુ કરે છે, પોતાના સ્ટેક ધરાવતા કન્ટેનર અને બ્રાઉઝર તેને અવગણી શકે છે, અને તેથી ટનલ પેકેટ સંપૂર્ણ રીતે વહન કરતી હોય ત્યારે પણ નામ નિષ્ફળ જઈ શકે છે. સરનામાને બદલે હોસ્ટનામ સાથે પરીક્ષણ કરો, અને પ્રોફાઇલનું સર્વર જ જવાબ આપ્યો એમ માનવાને બદલે કયું સર્વર જવાબ આપ્યો તે નોંધો.

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

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