WireGuard અટકી જાય છે: MTU મર્યાદા કે ખૂટતો ફોરવર્ડ નિયમ?
સર્વરની પેલે પાર કંઈ ન ચાલે તે ફોરવર્ડિંગ કે પરત રૂટની સમસ્યા છે. નાની વિનંતીઓ ચાલે અને મોટી અટકે તે પેકેટ કદની ઓળખ છે.
ટેવ એ છે કે WireGuard ખરાબ વર્તન કરે કે તરત MTU ઘટાડી દેવો, અને એ ટેવ બીજી ખામી છુપાવે છે. જે ગેટવે ફોરવર્ડ કરતું નથી અને જે માર્ગ મોટા પેકેટ ઉપાડતો નથી તે અલગ પેટર્ન બનાવે છે: એક બંને દિશામાં અને દરેક કદમાં નિષ્ફળ જાય છે, બીજું નાની વિનંતીઓમાં ટકી રહે છે અને મોટીમાં મરી જાય છે. કોઈ પણ આંકડો બદલતા પહેલાં તમારી પાસે કઈ આકૃતિ છે તે નક્કી કરો. પરીક્ષણ સસ્તું છે અને સંભવિત કારણોમાંથી અડધા દૂર કરે છે.
બે નિષ્ફળતા, બે અલગ આકાર
ફોરવર્ડિંગની સમસ્યા સર્વરની તરત પછી દેખાય છે. હેન્ડશેક સફળ થાય છે, ટનલનું સરનામું જવાબ આપે છે, અને ગેટવે પાછળ નાની વિનંતીથી પણ કંઈ પહોંચતું નથી. પેકેટ સર્વર સુધી પહોંચ્યું અને આગળ મોકલાયું નહીં, અથવા જવાબનો પાછા જવાનો કોઈ માર્ગ નહોતો.
કદની સમસ્યા ફક્ત એક મર્યાદાથી ઉપર દેખાય છે. DNS, TCP હેન્ડશેક અને નાનો API કૉલ ચાલે છે, જ્યારે ફાઇલ ડાઉનલોડ કે મોટો જવાબ અટકી જાય છે. જે પેકેટ સમાઈ ગયા તે એક છેડેથી બીજા છેડે ગયા, અને જે સમાયા નહીં તે ક્યાંક ઉપયોગી અહેવાલ વિના ફેંકાઈ ગયા.
એ વર્ણનો અલગ લોકો અને અલગ રૂપરેખા ફાઇલો તરફ ઇશારો કરે છે, તેથી અનુમાન કરતાં આકાર માપવો વધુ કિંમતી છે. ગેટવે પર એક જ પિંગ તેમને અલગ કરી શકતું નથી.
કંઈ પણ નાનું કરતા પહેલાં ફોરવર્ડિંગ બાદ કરો
ગેટવે પોતે નહીં, ગેટવેની પેલે પારનું લક્ષ્ય ચકાસો. સર્વરના ટનલ સરનામા પરનો પિંગ ફક્ત એ સાબિત કરે છે કે ઇન્ટરફેસ ચાલુ છે અને તમે ટનલ પૂરી કરતા મશીન સુધી પહોંચો છો. વિશાળ નેટવર્કનો ટ્રાફિક એ મશીન પર IP ફોરવર્ડિંગ ચાલુ હોવા અને ફોરવર્ડ થતા પ્રવાહને મંજૂરી આપતા ફાયરવોલ પર આધાર રાખે છે. બંને સાચા હોવા જોઈએ, અને એમાંથી એક ખોટું હોય તો એ જ મૌન સર્જાય છે.
પરત રૂટિંગનું પણ એટલું જ મહત્વ છે. જો લક્ષ્ય નેટવર્કને ખબર ન હોય કે ક્લાયન્ટના ટનલ સરનામા સુધી કેવી રીતે પહોંચવું, તો વિનંતી આવે છે અને જવાબ અદૃશ્ય થાય છે, અને ક્લાયન્ટ એવો સમયસમાપ્તિ જણાવે છે જે ફેંકાયેલા ફોરવર્ડ જેવો જ દેખાય છે.
જ્યાં ડિઝાઇન સરનામા અનુવાદ વાપરે છે, ત્યાં અનુવાદનો નિયમ એ પરત માર્ગનો ભાગ છે. MTU સમસ્યા પાછળ દોડતી વખતે તેને દૂર કરવાથી એક ચાલતી ડિઝાઇન તૂટેલી બની જાય છે, તેથી હાલના નિયમો સંપાદિત કરતા પહેલાં વાંચો.
ભંગ ક્યાંથી શરૂ થાય છે તે માપો
પહેલાં ફોરવર્ડિંગની સ્થિતિ અને ફિલ્ટર નિયમો વાંચો. આ ફક્ત વાંચવાની ચકાસણીઓ છે અને સસ્તા પ્રશ્નનો જવાબ આપે છે:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9પછી ક્લાયન્ટથી ગેટવેની પેલે પારના હોસ્ટ તરફ, ડોન્ટ-ફ્રેગમેન્ટ બિટ સાથે કદ ચકાસો:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9જો પહેલી ચકાસણી ચાલે અને બીજી ફ્રેગમેન્ટેશન ભૂલ સાથે નિષ્ફળ જાય, તો માર્ગ તમને તેનું વપરાયોગ્ય કદ કહી રહ્યો છે. જો એક પણ ન ચાલે, તો તમે ફોરવર્ડિંગ કે રૂટિંગ જોઈ રહ્યા છો, અને MTU એ બદલવાનું ચલ નથી.
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
તમે સાબિત કરેલો સ્તર સુધારો
જ્યારે ફોરવર્ડિંગ ખામી હોય, ત્યારે સુધારો ફોરવર્ડિંગ નિયમ કે રૂટ છે, જે ડિઝાઇન પરવાનગી આપે તેટલો સાંકડો વ્યક્ત કરેલો હોય. જ્યારે કદ ખામી હોય, ત્યારે સુધારો એવો MTU છે જે આ ચોક્કસ માર્ગ પરના એન્કેપ્સ્યુલેશનનો હિસાબ રાખે છે, અને જરૂર હોય તે ઇન્ટરફેસ પર લાગુ પડે છે, ફ્લીટના દરેક એડેપ્ટર પર નહીં.
કોઈ પણ રીતે, પછી એ જ લક્ષ્ય સામે એ જ કાર્ય ફરીથી કરો. જો મૂળ મોટું સ્થાનાંતરણ હવે પૂરું થાય, તો ફેરફારે એ સ્તરને સંબોધ્યું જે નિષ્ફળ જતું હતું. જો ફક્ત નાની ચકાસણી સુધરી, તો તમે લક્ષણનો ઉપચાર કર્યો અને સાચી મર્યાદા હજી યથાવત્ છે.
ફેરફાર પહેલાં તમે કઈ આકૃતિ જોઈ તે લખો. સુધારાની બાજુમાં નોંધાયેલી એ એક લાઇન જ આગલી વ્યક્તિને એવું MTU ઘટાડવાથી રોકે છે જે કદી સમસ્યા નહોતું.