OpenVPN 443 પર હજુ પણ અવરોધિત? નેટવર્ક શું તપાસે છે તે જુઓ

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

હેન્ડશેક નંબર કરતાં વધુ જાહેર કરે છે

TCP 443 પરનો મૂળ VPN શ્રોતા પહેલા પેકેટથી જ પોતાનો પ્રોટોકોલ બોલે છે. ClientHello માં એક આવૃત્તિ ક્ષેત્ર, એક અવ્યવસ્થિત મૂલ્ય અને વિસ્તરણોની યાદી હોય છે, અને થોડા સો બાઇટ વાંચતું ઉપકરણ કંઈ પણ ડિક્રિપ્ટ કર્યા વિના ફરક પારખી શકે છે. પોર્ટ નંબર સંતોષવા સસ્તા છે, અને પ્રોટોકોલનો આકાર એ છે જે ફિલ્ટર ખરેખર તપાસે છે. નિયમો સામાન્ય રીતે પ્રોટોકોલ પ્રમાણે પણ લખાય છે, તેથી TLS તપાસતી નીતિ UDP વિશે કંઈ કહેતી નથી.

માન્ય TLS સત્ર પર ભાર મૂકતો પારદર્શક પ્રોક્સી સેટઅપ દરમિયાન જ જોડાણ કાપી નાખે છે, ઘણી વાર TCP હેન્ડશેક પૂર્ણ થયા પછી. એ વિગત પછી કામ આવે છે, કારણ કે તેનો અર્થ છે કે સોકેટ સ્થપાયા પછી ક્લાયન્ટ લોગ અટકી જાય છે.

સ્ટ્રીમને આવરવાથી બે નિષ્ફળતાના મુદ્દા ઊભા થાય છે

stunnel જેવું TLS આવરણ અપેક્ષિત આકાર પુનઃસ્થાપિત કરે છે: ક્લાયન્ટ સ્થાનિક શ્રોતા સાથે જોડાય છે, આવરણ સર્વર સાથે 443 પર ખરેખરું TLS સત્ર ખોલે છે, અને સર્વર પરનું બીજું આવરણ ડિક્રિપ્ટ થયેલા બાઇટને VPN ડિમન સુધી મોકલે છે. બહારનું સત્ર હવે બીજા કોઈ પણ HTTPS જોડાણ જેવું લાગે છે. સર્વર પરના VPN ડિમનએ ફક્ત loopback પર સાંભળવું જોઈએ, કારણ કે આવરણની બહાર કોઈને તેના સુધી પહોંચવાની જરૂર નથી.

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

આવરણ સુધીનો માર્ગ જ જાળ છે

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

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

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

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

કંઈ બદલતા પહેલાં સમય જુઓ

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

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

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

એક સમયે એક ચલ કસો

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

દરેક પ્રયાસે એક ઘટક બદલો. નવો પોર્ટ, નવું આવરણ અને નવું સાઇફર એક જ દોડમાં રાખો તો ત્રણમાંથી કયું મહત્ત્વનું હતું તે તમે કહી શકશો નહીં.