WireGuard ની અંદર IPIP: એ વધારાના 20 બાઇટ જે કોઈએ બજેટમાં ન લીધા
IPIP WireGuard ની અંદર 20 વધારાના બાઇટ ખર્ચે છે. જીવંત ટનલ પર અટકેલા સ્થાનાંતર માટે ફ્રેગમેન્ટેશનને દોષ આપતા પહેલાં યોગ્ય સ્તર પર બજેટ કરો.
નાના ping આખો દિવસ ટનલ પાર કરે છે, SSH બેનર આવે છે, અને પછી ફાઇલ સ્થાનાંતરણ શરૂ થાય તે ક્ષણે સેશન થીજી જાય છે. આ પેટર્ન ખોટા સ્તર પર ગણાયેલા બાઇટ-બજેટ તરફ ઇશારો કરે છે, જ્યાં બાહ્ય ટનલ તેના પોતાના ઓવરહેડ માટે માપવામાં આવી હતી અને કોઈએ અંદરની બાદ કરી ન હતી. WireGuard માટે નેસ્ટેડ IPIP પેકેટ ફક્ત બીજું IP પેકેટ છે, અને તેથી જ તે એ બાઇટ વાપરે છે જે તમે કદી અનામત રાખ્યા ન હતા. સુધારો ગણિત છે, અને તે ત્રણ આદેશ અને એક કોષ્ટકમાં આવી જાય છે.
જે લક્ષણ તેને પકડી પાડે છે
ફ્રેગમેન્ટેશનની સમસ્યા પોતાની જાહેરાત કદ દ્વારા કરે છે, કદી સરનામાં દ્વારા નહીં. તમારો પીઅર એક કલાક સુધી 56 બાઇટના ping નો જવાબ આપે છે અને પછી 1400 બાઇટ પર શાંત થઈ જાય છે, જ્યારે ટનલ ચાલુ રહે છે અને કોઈ રૂટ બદલાયો નથી. હેન્ડશેક બંધ બેસે છે, પ્રથમ સંપૂર્ણ TCP વિન્ડો નહીં, અને સ્થાનાંતરણ સ્વસ્થ દેખાયાના સેકંડો પછી અટકી જાય છે.
કંઈપણ સંપાદિત કરતા પહેલાં ટોચમર્યાદા માપો, કારણ કે ન માપેલી ટોચમર્યાદા એ છે જેનો તમે બે વાર પીછો કરશો. શંકાસ્પદ કદની નીચે do-not-fragment બિટ સેટ કરીને એક પ્રોબ મોકલો, ping -M do -s 1000 10.9.0.2, અને પછી એ કદ પર પુનરાવર્તન કરો જે તમે પહેલેથી જાણો છો કે ઘણું મોટું છે. જ્યારે ઉલટાવ પેલોડના કદને અનુસરે છે જ્યારે ગંતવ્ય અપરિવર્તિત રહે છે, ત્યારે રૂટિંગ પોતાનું કામ કરે છે અને બજેટમાંથી એક હેડર ખૂટે છે.
દરેક હેડરને એક વાર ગણો, યોગ્ય સ્તર પર
ટનલ ઇન્ટરફેસથી નહીં, પણ પાથ પરના સૌથી નાના MTU થી શરૂ કરો, કારણ કે દીવાલ બંને છેડાથી ઉપર છે. WireGuard IPv4 બાહ્ય પરિવહન પર 60 બાઇટ ખર્ચે છે: 20 IP માટે, 8 UDP માટે અને 32 તેના પોતાના હેડર માટે, અને જ્યારે તે પરિવહન IPv6 હોય ત્યારે 80 બાઇટ. 1420 બાઇટનું wg0 1440 ની નીચે 20 બાઇટની છૂટ રાખે છે, જે 1500 બાઇટનો પાથ ખરેખર પહોંચાડી શકે છે, અને તેથી વિકિમાંથી નકલ કરેલો આંકડો અહીં પણ બંધ બેસે છે. આખો સ્ટેક ડાયાગ્રામ પર દોરો, કારણ કે આગલી વાર MTU બદલનાર વ્યક્તિ અન્યથા નવો ગોળ આંકડો પસંદ કરશે અને તમારો બગ વારસામાં લેશે.
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
પાંચમી હરોળ એ છે જ્યાં બજેટ ખોટા પડે છે, કારણ કે નેસ્ટેડ ઇન્ટરફેસ વહન કરતા 1400 બાઇટમાં મૂળ પેકેટના પોતાના 40 બાઇટ હેડર પહેલેથી સમાયેલા છે. તે બાઇટમાંથી ફક્ત 1360 ફાઇલ વાંચતી પ્રક્રિયા સુધી પહોંચે છે. 1400 ને એપ્લિકેશન પેલોડ ગણો, જેમ તે કોલમ વગરનું કોઈપણ ડાયાગ્રામ તમને આમંત્રે છે, અને અંદરનું ઉપકરણ એવી દીવાલ સામે 40 બાઇટ વધુ ઉદાર બની જાય છે જે ખસી નથી.
બે MTU અલગ રીતે સેટ કરો
વાહક અને નેસ્ટેડ ઉપકરણ અલગ વસ્તુઓ છે, તેથી દરેકને પોતાનું મૂલ્ય જોઈએ. તેમને આ ક્રમમાં લાગુ કરો, કારણ કે નેસ્ટેડ ઉપકરણ વાહક પાસેથી કંઈ વારસામાં લેતું નથી:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400યાદ રાખવા લાયક નિયમ: આંતરિક MTU = બાહ્ય MTU - 20 જ્યારે IPIP ટનલ વહન કરતું પેકેટ IPv4 હોય, અને - 40 જ્યારે આંતરિક પેકેટની કોઈપણ બાજુ IPv6 હોય, કારણ કે નેસ્ટેડ હેડર 20 બાઇટથી 40 સુધી વધે છે. આ બાદબાકીમાં બીજું કંઈ આવતું નથી. તમે 1420 પસંદ કર્યું ત્યારે WireGuard નો ઓવરહેડ પહેલેથી ખર્ચાઈ ગયો હતો, અને તેને બે વાર ગણવાથી એવી ટનલ બને છે જે સંપૂર્ણ કામ કરે છે અને જ્યાં સુધી કોઈ તેને માપતું નથી ત્યાં સુધી ધીમી રહે છે. જેમાં બંને ઉપકરણો ગોળ 1400 વહન કરે છે તે જમાવટ એ ભૂલની આંગળીની છાપ છે.
નેસ્ટેડ પેકેટની કોઈપણ બાજુ IPv6 હોવાથી ઉપરના દરેક આંકડા અમાન્ય થઈ જાય છે, તેથી સમાન સાઇટ પરથી આંકડો નકલ કરવાને બદલે ફરી ગણતરી કરો. IPv6 બાહ્ય પાથમાં કે મૂળ ડેટાગ્રામમાં દેખાય કે તરત જ બાદ કરાયેલા હેડર દરેક 40 બાઇટના હોય છે, અને પેલોડનો આંકડો બરાબર તેટલો ઘટે છે.
ફાયરવોલ નિયમ જેની તમને કદાચ જરૂર નથી
બે WireGuard પીઅર વચ્ચે વાયર પર એકમાત્ર UDP હોય છે, તેથી પ્રોટોકોલ 4 માટેનો ઇનબાઉન્ડ નિયમ, જે નંબર RFC 2003 IPv4-માં-IPv4 એન્કેપ્સ્યુલેશનને આપે છે, તે ન તો નેસ્ટેડ પાથ બનાવે છે કે ન તેને જીવંત રાખે છે. IPIP હેડર એન્ક્રિપ્ટેડ પેલોડની અંદર રહે છે, જ્યાં કોઈ એજ ફાયરવોલ તેને જોતું નથી. પ્રોટોકોલ 4 ખોલવાથી હોસ્ટમાં એક વધુ મંજૂર માર્ગ સિવાય કંઈ મળતું નથી.
મૂળ પેકેટના સ્રોત અને ગંતવ્યોનો ઉલ્લેખ કરતી નીતિ ડિકેપ્સ્યુલેશન પછી, ટનલ ઇન્ટરફેસ પર અને રૂટિંગ કોષ્ટકમાં આવે છે. તેને ત્યાં મૂકો અને એજ નિયમ બંધ રહી શકે છે.
WireGuard ખરેખર શું માન્ય કરે છે
AllowedIPs WireGuard વહન કરે છે તે પેકેટના સ્રોતનો નિર્ણય કરે છે, અને તે જે વહન કરે છે તે IPIP-એન્કેપ્સ્યુલેટેડ પેકેટ છે. મંજૂર IPIP સ્રોત સ્વીકારવામાં આવે છે ત્યારે પણ જ્યારે અંદરનું હેડર એવા હોસ્ટનું નામ આપે છે જેને તમે રૂટ ન કરવા પસંદ કરશો. તેથી મૂળ સ્રોત એ નથી જે પીઅરે તમારા માટે ચકાસ્યું, અને તે આંતરિક સરનામાં-જોડીને ડિકેપ્સ્યુલેશન પછી પોતાની અમલવારીની જરૂર છે.
આવરણ રૂટિંગ માળખું આપે છે, બીજું ક્રિપ્ટોગ્રાફી સ્તર નહીં. WireGuard ની અંદર IPIP ને વધારાનું રક્ષણ કહેવું એ અલગ રચનાનું વર્ણન છે.
એક ping નહીં, સીડી વડે ચકાસો
તમે ગણેલી સીમાની બંને બાજુ રહેતા કદની પ્રોબ કરો, પછી કર્નલ બંને ઉપકરણો વિશે શું માને છે તેની પુષ્ટિ કરો. 1360 બાઇટ પેલોડ વત્તા 40 બાઇટ હેડર મળીને 1400 થાય છે, નીચેનો પ્રથમ પડઘો પસાર થાય છે અને બીજો ટોચમર્યાદાથી એક બાઇટ બહાર બેસે છે:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0ટોચમર્યાદાની નીચે સ્વચ્છ પસાર થવું અને તેની ઉપરના પ્રથમ કદ પર નિષ્ફળ જવું એટલે કે ગણિત શરૂઆતથી અંત સુધી ટકે છે. પછી મૂળ રૂપે અટકેલું સ્થાનાંતરણ ફરી ચલાવો, કારણ કે કૃત્રિમ પ્રોબ બજેટ સાબિત કરે છે અને મોકલનારના પોતાના લેખન-કદ વિશે કંઈ કહેતું નથી. જો નેસ્ટેડ પાથ તમે સાબિત કરેલા કદ પર પણ તૂટે, તો MTU માંથી બીજા દસ બાઇટ કાપતા પહેલાં દૂરના છેડાનું ડિકેપ્સ્યુલેશન અને રૂટ તપાસો.