WireGuard PersistentKeepalive: NAT મેપિંગ જીવંત રાખો
જો ઉલટી કનેક્શન ફક્ત પીઅર ટ્રાફિક મોકલ્યા પછી તરત જ કામ કરે, તો મેપિંગ સમાપ્ત થઈ રહ્યું છે. રાઉટર પાછળ keepalive સેટ કરો અને પછી વાસ્તવિક ટાઈમઆઉટ વાંચો.
ઘરનું બોક્સ ટનલ ખોલે છે અને કોઈ મુશ્કેલી વિના ક્લાઉડ સર્વર સુધી પહોંચે છે. ઘરનું બોક્સ છેલ્લે કંઈક મોકલ્યા પછી ક્લાઉડ સર્વર એક-બે મિનિટ સુધી ઘરની એપ્લિકેશન સુધી પહોંચી શકે છે, અને પછી બંધ થઈ જાય છે. WireGuard લોગમાં કંઈ દેખાતું નથી, કોઈ હેન્ડશેક ભૂલની જાણ થતી નથી, અને ટનલ ફરી શરૂ કરવાથી તે થોડા સમય માટે સુધરે છે. એ પેટર્ન સમાપ્ત થતું મેપિંગ છે, તૂટેલી ટનલ નહીં, અને નીચેનું માર્ગદર્શિકા કંઈપણ બદલતા પહેલા તેની પુષ્ટિ કરે છે.
પુષ્ટિ કરો કે પેટર્ન નિષ્ક્રિયતામાં સમાપ્તિ છે
અલગ પાડતી વિગત સમય છે. જો ઉલટી કનેક્શન ઘરના પીઅર ટ્રાફિક મોકલ્યા પછી તરત જ કામ કરે છે અને શાંત અંતરાલ પછી નિષ્ફળ જાય છે, તો માર્ગ ઠીક છે અને વચ્ચેની સ્થિતિ નથી. જો તે ક્યારેય કામ ન કરે, ટ્રાફિક પછી તરત જ પણ, તો આ ખોટું નિદાન છે.
sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transferઘરનું પીઅર કંઈક મોકલ્યા પછી તરત જ પ્રથમ બે ચલાવો, પાંચ મિનિટ રાહ જુઓ અને ફરીથી ચલાવો. સમયપત્રક મુજબ નવાજૂની થતી હેન્ડશેક ટાઈમસ્ટેમ્પ, નવા એન્ડપોઈન્ટ વિના, તમને કહે છે કે ટનલ જીવંત છે. જે બદલાયું તે બહારથી વિનંતી ન કરેલા પેકેટ આવવાની ક્ષમતા છે, જે ટનલની નહીં પણ માર્ગની લાક્ષણિકતા છે.
પછી ઉલટો પ્રયાસ કરો અને ટ્રાન્સફર કાઉન્ટર જુઓ. જો ક્લાઉડ બાજુ બાઇટ મોકલે છે અને ઘરની બાજુ એક પણ મેળવતી નથી, તો પેકેટ ક્લાઉડ છોડીને રસ્તામાં સ્થિતિ રાખતા ઉપકરણમાં મૃત્યુ પામ્યું. તમે જે હસ્તાક્ષર શોધી રહ્યા છો તે આ છે. જો બંને કાઉન્ટર ખસે, તો ટનલે પેકેટ પહોંચાડ્યું છે અને શંકાસ્પદ એપ્લિકેશન છે.
રાઉટર પાછળના પીઅર પર keepalive મૂકો
કાયમી keepalive સમયપત્રક મુજબ નાનું પ્રમાણિત પેકેટ મોકલીને NAT મેપિંગ અને કોઈપણ ફાયરવોલ સ્થિતિ જીવંત રાખે છે. આ સેટિંગ રાઉટર પાછળની મશીન પર, દૂરના પીઅર માટેની તેની એન્ટ્રીમાં હોવી જોઈએ, કારણ કે તે બાજુનું બહાર જતું પેકેટ સ્થિતિ બનાવે છે.
[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25તેને હાલના પીઅર વિભાગમાં ભેળવો. સમાન જાહેર કી સાથે બીજો બ્લોક ઉમેરવો વિકલ્પો ઉમેરવાની માન્ય રીત નથી, અને wg-quick તમારા માટે તેમને ભેળવશે નહીં. દસ્તાવેજીકૃત 25 સેકન્ડ સામાન્ય UDP ટાઈમઆઉટની નીચે રહેવા માટે પસંદ કરેલું ઉદાહરણ છે, કોઈ વિશેષ અર્થ ધરાવતું મૂલ્ય નહીં.
તે જ સૂચના ક્લાઉડ બાજુ પર મૂકવાથી આ સમસ્યામાં મદદ મળતી નથી. તે પીઅરના પેકેટ પહેલેથી જ જાહેર સરનામાં પરથી આવે છે, તેથી મહત્વની દિશામાં સાચવવા જેવું કોઈ મેપિંગ નથી. તે ટ્રાફિક ઉમેરે છે અને કંઈ બદલતું નથી.
અંતરાલનો અંદાજ લગાવવાને બદલે ટાઈમર વાંચો
keepalive કામ કરે છે કારણ કે તે સ્થિતિ સમાપ્ત થવા કરતાં વધુ વાર આવે છે. તે ટાઈમઆઉટને તમને ખરેખર જરૂરી સંખ્યા બનાવે છે, અને Linux પર તે અનુવાદ કરતા ઉપકરણ પર વાંચી શકાય છે:
sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820પ્રથમ મૂલ્ય એ UDP પ્રવાહ માટેનો ટાઈમઆઉટ છે જે ફક્ત એક દિશામાં જોયો છે, અને બીજું જવાબો જોવાયા પછી લાગુ પડે છે. બંને સામાન્ય રીતે ટૂંકા હોય છે, અને શાંત થઈ જતું મેપિંગ તમારા પ્રવાહ પર જે લાગુ પડે તેને અનુસરશે.
તે સંખ્યાને તમારા અંતરાલ સાથે સરખાવો. 30 સેકન્ડના ટાઈમઆઉટ હેઠળ 25 સેકન્ડનું keepalive કામ કરે છે; 15 સેકન્ડના ટાઈમઆઉટ હેઠળ તે જ keepalive કામ કરતું નથી. કેટલી પણ પુનઃપ્રયાસ કરવાથી તે ગણિત બદલાતું નથી. કેટલાક ગ્રાહક રાઉટર અને મોબાઈલ ઓપરેટર Linuxના ડિફોલ્ટ કરતાં ઘણા ટૂંકા મૂલ્યો વાપરે છે, તેથી જ એક નેટવર્ક પર કામ કરતું કન્ફિગરેશન બીજા પર નિષ્ફળ જાય છે.
| Observation | What it means | Reasonable response |
|---|---|---|
| Works after traffic, dies when idle | Mapping or firewall state expiring | Lower the keepalive interval |
| Never works, even immediately | No return route, listener or firewall | Stop tuning keepalive |
| Works for hours, then dies once | Carrier-side translation or address change | Check the endpoint and logs together |
શ્રોતા અને ફાયરવોલ અલગથી તપાસો
જીવંત મેપિંગ જરૂરી છે અને પૂરતું નથી. ઘરના બોક્સ પરની એપ્લિકેશને યોગ્ય સરનામે સાંભળવું જોઈએ, અને હોસ્ટ ફાયરવોલે ડિક્રિપ્ટ થયા પછી પેકેટને મંજૂરી આપવી જોઈએ.
sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/healthજો સોકેટ ફક્ત ભૌતિક ઇન્ટરફેસના સરનામે બંધાયેલું છે, ટનલના સરનામે નહીં, તો ટનલ પર આવતા પેકેટ ફાયરવોલને પૂછવામાં આવે તે પહેલાં જ કાઢી નાખવામાં આવે છે. આ નિષ્ફળતા ક્લાઉડ બાજુથી મેપિંગ સમસ્યા જેવી જ દેખાય છે, અને દરેક keepalive ગોઠવણીને ટકી રહે છે.
મંજૂર સૂચિની તપાસ બીજી દિશામાં પણ એટલી જ મહત્વપૂર્ણ છે. ક્લાઉડ પીઅરે જવાબ આપવાનો હોય તો ઘરની ટનલનું સરનામું સ્રોત તરીકે મંજૂર કરવું જોઈએ, અને ઘરના પીઅરે ક્લાઉડ સરનામું ગંતવ્ય તરીકે મંજૂર કરવું જોઈએ. keepalive પેકેટ પ્રમાણિત ટ્રાફિક છે અને તે જ નિયમો લાગુ કરે છે, તેથી કામ કરતું દેખાતું keepalive એવી એપ્લિકેશન સાથે રહી શકે છે જે કામ કરતી નથી.
ફેરફાર રોલ આઉટ કરો અને તેની મર્યાદા જાણો
સેટિંગ લાગુ કરો, જો તે તમારી અપડેટ રીત હોય તો ઇન્ટરફેસ ફરી શરૂ કરો, અને પછી તાત્કાલિક પરીક્ષણને બદલે નિષ્ક્રિયતા પરીક્ષણનું પુનરાવર્તન કરો. પહેલાં વાંચેલા ટાઈમઆઉટ કરતાં વધુ રાહ જુઓ, ઉલટી વિનંતી કરો અને પુષ્ટિ કરો કે બંને છેડે કાઉન્ટર ખસ્યા છે.
અંતરાલ અને માપેલો ટાઈમઆઉટ તેની બાજુમાં નોંધો. ભવિષ્યમાં રાઉટરની ફર્મવેરમાં ફેરફાર, અથવા મોબાઈલ કનેક્શનમાં જવાથી, ટાઈમઆઉટ બદલાઈ શકે છે. નોંધ એ છે જે કોઈને મૂલ્ય કોપી કરવાને બદલે ફરીથી મેળવવા દે છે. એક લાઇનમાં બે સંખ્યાઓ પછી આખી તપાસ બચાવે છે.
કાયમી keepalive સ્થિતિનું રક્ષણ કરે છે. તે પોર્ટ ખોલતા નથી, મંજૂર સૂચિમાં એન્ટ્રી ઉમેરતા નથી, અને શ્રોતાને દેખાવા મજબૂર કરતા નથી. જ્યારે ઉલટી કનેક્શન બિલકુલ કામ કરતું નથી, ત્યારે દોષ તે ત્રણમાંથી એક છે, અને WireGuard ઝડપી શરૂઆત keepalive સેટિંગનું વર્ણન તે જ સાંકડી શરતોમાં કરે છે.