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

એક લેબલ પાછળ બે પ્રશ્નો છુપાયેલા છે

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

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

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

મેપિંગ અને ફિલ્ટરિંગ અલગ ગુણધર્મો છે

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

BehaviourWhat it meansEffect on a direct peer path
Endpoint-independent mappingOne external port for every destinationDiscovery works if the port is advertised
Address-dependent mappingNew port per remote addressWorks only if both sides probe the same pair
Address-and-port-dependentNew port per remote address and portUsually needs a relay

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

ફિલ્ટરિંગના પોતાના ત્રણ કિસ્સા છે અને દરેક માટે પોતાનું નામ છે. ટિકિટમાં “સિમેટ્રિક NAT” લખવું જ્યારે તમારો અર્થ “સરનામા અને પોર્ટ-આધારિત ફિલ્ટરિંગ” છે, ત્યારે આગલી વ્યક્તિને માર્ગદર્શિકાના ખોટા પ્રકરણમાં મોકલે છે. પરીક્ષણમાં બંને અલગ વર્તે છે, તેથી ભૂલ ફક્ત શૈક્ષણિક નથી.

મેપિંગને નામ આપવાને બદલે માપો

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

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

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

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

STUN-આધારિત સાધનો એક જ પગલામાં એ જ વર્ગીકરણ જણાવે છે, અને જ્યારે નેટવર્ક જાહેર STUN સર્વર સુધી બહાર જતા UDP ની પરવાનગી આપે ત્યારે તેમનો ઉપયોગ યોગ્ય છે. જ્યારે પરવાનગી ન આપે, ત્યારે ઉપરની કેપ્ચર પદ્ધતિ હજી પણ કામ કરે છે અને તમારા નિયંત્રણમાં પહેલેથી હોય તેવા હોસ્ટ સિવાય કંઈ જ જરૂરી નથી.

નિષ્ફળતાને મેળ ખાતો ઉપાય પસંદ કરો

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

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

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

ચુકાદો નહીં, સ્થાપના નોંધો

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

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

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

સંબંધિત લેખો