ફક્ત વેબ નેટવર્ક પર VPN બ્લોક? સ્તરો પર કામ કરો

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

સાબિત કરો કે કયું સ્તર જોડાણ નકારે છે

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

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

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

હવે તમે ખરેખર મેળવો છો તે પ્રમાણપત્ર તપાસો. સર્વર સાથે વાત કરો છો કે સત્રને ફરી સહી કરનારા મધ્યસ્થ બોક્સ સાથે, તે જાણવાનો આ સૌથી ઝડપી રસ્તો છે:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

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

પ્રોક્સી-સભાન ક્લાયન્ટ પહેલું પેકેટ બદલે છે, નીતિ નહીં

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

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

પહેલો આદેશ સાબિત કરે છે કે પ્રોક્સી લક્ષ્ય વહન કરશે. બીજો ક્લાયન્ટને 443 પર TCP વાપરવા કહે છે, જે મોટાભાગના ફક્ત-વેબ માર્ગો જરાય આગળ મોકલે છે તે એકમાત્ર પરિવહન છે. જો પહેલો આદેશ સફળ થાય અને બીજો હજી નિષ્ફળ જાય, તો પ્રોક્સી અવરોધ નથી.

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

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

પોર્ટ 443 પહોંચી શકાય છે, મંજૂર નથી

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

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

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

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

ગઈકાલે કામ કરતા પીઅરની બાજુમાં ખાલી હેન્ડશેક સમયછાપ એ UDP નો જવાબ છે. બે DNS પ્રશ્નો બીજા પ્રશ્નનો જવાબ આપે છે: જો સ્થાનિક રિઝોલ્વર અને જાહેર રિઝોલ્વર એન્ડપોઇન્ટ સરનામા પર સહમત ન હોય, તો તમને સ્ટીયર કરવામાં આવે છે અને પરિવહનની દલીલ ખોટી છે.

ખરેખર મશીનમાંથી શું નીકળ્યું તે ચકાસો

ક્લાયન્ટ લોગ કહે છે કે ક્લાયન્ટ શું માને છે. કેપ્ચર કહે છે કે નેટવર્કે શું જોયું, અને બંને વચ્ચેનો ફરક એ છે જ્યાં મોટાભાગના આ કેસ ઉકેલાય છે:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

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

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

પાછું ફેરવવું, અને રાખવા લાયક નોંધ

ફેરફારો જે ક્રમમાં કર્યા તેના ઊલટા ક્રમમાં પાછા ફેરવો. પ્રોક્સી ચલ દૂર કરો, હાથે શરૂ કરેલો ક્લાયન્ટ બંધ કરો, અને ઉમેરેલ કોઈ પણ રૂટ કે રિઝોલ્વર ઓવરરાઇડ દૂર કરો:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

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

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