ISP UDP બ્લોક કરે છે, કે ટનલની અંદરની એપ છે?

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

બે હેડર, એક શબ્દ

NAT-traversal સાથેના IPsec ડિપ્લોયમેન્ટમાં બાહ્ય પેકેટ UDP છે, જે બે VPN એન્ડપોઈન્ટ વચ્ચે સરનામું ધરાવે છે, સામાન્ય રીતે પોર્ટ 4500 પર. તેની અંદર એન્ક્રિપ્ટ કરેલું પેલોડ ટનલ જે ફોરવર્ડ કરે છે તે બધું વહન કરે છે, જે પોતે TCP અથવા UDP હોઈ શકે છે. તેથી UDP શબ્દ બે વાર આવે છે, જુદા અર્થ અને જુદી દૃશ્યતા સાથે.

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

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

નેટવર્ક હજી શું જોઈ શકે છે

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

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

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

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

કેમ એક UDP એપ કાર્યરત ટનલની અંદર નિષ્ફળ જાય છે

જે ટનલ વેબ એપ્લિકેશન વહન કરે છે પણ UDP એપ્લિકેશન નહીં, તેની ઘણી વિશ્વસનીય સમજૂતીઓ છે, અને ISP દ્વારા આંતરિક પ્રોટોકોલનું ફિલ્ટરિંગ પ્રથમ નથી. સૌથી સામાન્ય કવરેજ છે: બંને એપ્લિકેશનો એક જ ટનલમાં પ્રવેશતી નથી, કારણ કે UDP ગંતવ્યનો રૂટ ખૂટે છે અથવા ક્લાયન્ટના સ્પ્લિટ-ટનલ નિયમો તેને બાકાત રાખે છે.

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

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

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

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

પ્રોટોકોલ નહીં, સ્તર જણાવો

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

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

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