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

કંઈપણ બદલતાં પહેલાં પેકેટોને તેમના હેતુ પ્રમાણે ગોઠવો, કારણ કે ઉકેલ તબક્કા પ્રમાણે આવે છે.

ત્રણ વાતચીતો, એક પોર્ટ નંબર

પહેલી વાતચીત એન્ડપોઇન્ટ માટે નામની શોધ છે: તમારું મશીન તેના ગોઠવેલા રિઝોલ્વરને પૂછે છે કે vpn.example.com ક્યાં છે, અને ક્લાયન્ટ એક પણ ટનલ પેકેટ મોકલે તે પહેલાં એ જવાબ સામાન્ય DNS પર આવે છે. બીજી વાતચીત OpenVPN ટ્રાન્સપોર્ટ પોતે છે, જે શોધે જે સરનામું આપ્યું તેની સાથે પ્રોફાઇલ જે પ્રોટોકોલ અને પોર્ટ કહે તેના પર જોડાય છે. ત્રીજી ટનલ તૈયાર થયા પછી થાય છે, જ્યારે એપ્લિકેશનો નામ માંગે છે અને મોકલેલી રિઝોલ્વર સેટિંગ્સ નક્કી કરે છે કે કોણ જવાબ આપશે.

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

ConversationWhen it happensWhat has to be true
Endpoint lookupBefore the client contacts a hostnameAn underlying resolver path can answer for the endpoint name
OpenVPN transportDuring tunnel establishmentThe gateway listens on its configured transport, address and port, and nothing filters it
Application DNSDuring or after the protected sessionA resolver the client can reach, plus routing that carries its queries

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

પોર્ટ નંબર એપ્લિકેશનનું નામ નથી

પોર્ટ 53 પરંપરાથી DNS વહન કરે છે, અને OpenVPN સંચાલક ત્યાં લિસ્નર પણ પ્રકાશિત કરી શકે છે, એટલે જ આ નંબર નબળી ઓળખ છે. UDP 53 પરનું OpenVPN સત્ર હજી પણ OpenVPN સત્ર જ છે, અને પોર્ટ 53 પરના સર્વરને કરેલી DNS પૂછપરછ એ વિશે કંઈ કહેતી નથી કે ટનલને મંજૂરી છે કે નહીં. પ્રોફાઇલની proto અને remote લાઇનો બાહ્ય એન્ડપોઇન્ટ નક્કી કરે છે; પોર્ટ નંબર પોતે કંઈ નક્કી કરતો નથી.

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

નેટવર્કને દોષ આપતાં પહેલાં લિસ્નર સાબિત કરો

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

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

ટનલ પછી DNS અલગથી તપાસો

ટનલ તૈયાર થયા પછી, VPN ઇન્ટરફેસ પર રિઝોલ્વરની સ્થિતિ તપાસો અને એક આંતરિક નામ અને એક જાહેર નામ પૂછો. જો ટનલ ટ્રાફિક વહન કરે છે ત્યારે આંતરિક નામો નિષ્ફળ જાય, તો મોકલેલી DNS સેટિંગ્સ લાગુ નથી થઈ, જે ક્લાયન્ટ ઇન્ટિગ્રેશનનો પ્રશ્ન છે, ટ્રાન્સપોર્ટનો નહીં. જો જાહેર નામો નિષ્ફળ જાય અને આંતરિક નામો કામ કરે, તો સ્પ્લિટ-ટનલ નીતિ એ જ કરી રહી છે જે તેને કરવા ગોઠવવામાં આવી હતી.

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

સંબંધિત લેખો