HTTP પ્રોક્સી દ્વારા OpenVPN: પહેલાં CONNECT જવાબ વાંચો
CONNECT પ્રોક્સી બાઇટ્સ રિલે કરે છે, તેથી બંને છેડે TCP જરૂરી છે. પ્રમાણપત્રોને દોષ આપતાં પહેલાં 407, 403 અને 503 વાંચો, અને સર્વર ચકાસણી ચાલુ રાખો.
VPN ક્લાયન્ટને કોર્પોરેટ HTTP પ્રોક્સી તરફ દોરો, અને પહેલી ઉપયોગી હકીકત એ છે કે પ્રોક્સી VPNનું પ્રોટોકોલ બોલતું નથી. તે તમે કહેલા સરનામે એક સામાન્ય TCP કનેક્શન ખોલે છે અને પછી બાજુ પર ખસી જાય છે, જેથી તમારો ક્લાયન્ટ અને સર્વર તે સ્ટ્રીમમાંથી પોતાની આપ-લે કરી શકે. ક્લાયન્ટને જે જોઈએ છે, પરિવહન પ્રકારથી લઈને સર્વરના શ્રોતા સુધી, તે આ ગોઠવણ સાથે મેળ ખાવું જોઈએ. બે અસંગતિઓ મોટાભાગની નિષ્ફળતાઓ સમજાવે છે: CONNECT પ્રોક્સી તરફ નિર્દેશિત UDP પ્રોફાઇલ, અને VPN ભૂલ ગણાતો પ્રોક્સી જવાબ.
પ્રોક્સી શું વહન કરે છે અને શું નહીં
પ્રોક્સી ફક્ત એક પરિવહન પગલું છે. તે તમારી બ્રાઉઝર પ્રોક્સી બનતું નથી, ટનલ દ્વારા તમે મુલાકાત લેતી સાઇટ્સ કેશ કરતું નથી, અને કોઈએ જાણી જોઈને નિરીક્ષણ ગોઠવ્યું ન હોય તો અંદરનું ટ્રાફિક જોતું નથી. તે જે ટનલ ખોલે છે તે ડિઝાઇનથી જ તેના માટે અપારદર્શક છે.
તેનો અર્થ એ પણ છે કે પ્રોક્સી એવા સર્વરને ઠીક કરી શકતું નથી જેની પાસે મેળ ખાતો શ્રોતા નથી. કોઈ ગંતવ્ય સુધી પહોંચવાની પરવાનગી અને તે ગંતવ્ય પર સાંભળતી સેવા બે અલગ હકીકતો છે, અને ફક્ત પહેલી પ્રોક્સી વ્યવસ્થાપકની છે.
વાહકને બંને છેડે TCP હોવું જોઈએ
પરંપરાગત CONNECT પ્રોક્સી ફક્ત બાઇટ સ્ટ્રીમ રિલે કરે છે , તેથી ક્લાયન્ટે સ્ટ્રીમ પરિવહન વાપરવું જોઈએ. તે કિસ્સા માટે ક્લાયન્ટ ટુકડો આવો દેખાય છે:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128સર્વર બાજુને remote લાઇનમાં કહેલા પોર્ટ પર ખરેખર TCP શ્રોતા જોઈએ છે. પ્રોફાઇલમાં proto udp ને proto tcp-client માં બદલવાથી સ્ટ્રીમની અપેક્ષા રાખતો ક્લાયન્ટ બને છે; તે બીજી બાજુ સ્ટ્રીમ બનાવતું નથી. જો એ જ સર્વર તે પોર્ટ પર UDP પર પણ જવાબ આપે, તો તે બીજો શ્રોતા છે, એ જ શ્રોતાનો બીજો મોડ નહીં.
જ્યાં અલગ TCP ઇન્સ્ટન્સ અસ્તિત્વમાં છે, ત્યાં તેનું ટનલ ઉપકરણ, સરનામા પૂલ અને રૂટિંગ પોતાના સંસાધનો છે. કાર્યકારી રૂપરેખા નકલ કરીને પરિવહન શબ્દ બદલવાથી તે સંસાધનો મૂળ ઇન્સ્ટન્સ તરફ જ નિર્દેશિત રહે છે, જે એવું જોડાણ બનાવે છે જે પ્રમાણીકરણ કરે છે અને પછી કંઈ રૂટ કરતું નથી.
VPN પરિણામ પહેલાં પ્રોક્સી જવાબ વાંચો
ક્લાયન્ટની પહેલી આપ-લે એક વિનંતી લાઇન છે જે ગંતવ્ય હોસ્ટ અને પોર્ટનું નામ આપે છે. તે લાઇનનો જવાબ તમને કહે છે કે બાઇટ સ્ટ્રીમ બિલકુલ છે કે નહીં, અને તે કોઈ પણ પ્રમાણપત્ર કે ઓળખપત્ર ચકાસાય તે પહેલાં આવે છે:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
CONNECT પર 200 વર્ગનો જવાબ એટલે સ્ટ્રીમ અસ્તિત્વમાં છે. તે ગેટવે પ્રમાણપત્ર વિશ્વસનીય છે કે નહીં, શેર કરેલી કી મેળ ખાય છે કે નહીં, અથવા વપરાશકર્તા ખાતું માન્ય છે કે નહીં તે વિશે કંઈ કહેતું નથી. તે ચકાસણીઓ પછી, સ્ટ્રીમની અંદર થાય છે, અને તે HTTP સ્ટેટસ લાઇનને બદલે ક્લાયન્ટના પોતાના સંદેશાઓ સાથે નિષ્ફળ જાય છે. ક્લાયન્ટ લોગમાં પહેલી OpenVPN ઘટના પ્રોક્સી હેન્ડશેક પછી જુઓ, વિન્ડો બંધ થવા પહેલાની છેલ્લી લાઇન નહીં.
પ્રોક્સી ઓળખપત્રો અને VPN ઓળખપત્રો ઘણી વાર જુદી ટીમો પાસેની જુદી ઓળખો હોય છે. 407 એ VPN ખાતાનો ખરાબ પાસવર્ડ નથી, અને નકારાયેલું પ્રમાણપત્ર એ પ્રોક્સી પરવાનગીની સમસ્યા નથી.
CONNECT શું જાહેર કરતું નથી
સ્પષ્ટ CONNECT ટનલ એ અટકાવ નથી. પ્રોક્સી બાઇટ્સ આગળ મોકલે છે અને VPNનું TLS સત્ર સમાપ્ત કરતું નથી, તેથી સર્વર પ્રમાણપત્રની ક્લાયન્ટની ચકાસણી અર્થપૂર્ણ રહે છે અને ચાલુ રહેવી જોઈએ. પ્રોક્સી પાર કરવા ચકાસણી બંધ કરવી એ તમારી સમસ્યા કરતાં બીજી સમસ્યા ઉકેલે છે.
એવી અલગ ગોઠવણો છે જ્યાં સંસ્થા જાણી જોઈને TLS સમાપ્ત કરે છે અને નિરીક્ષણ કરે છે. તેમને પોતાની વિશ્વાસ રૂપરેખા અને પોતાનો નીતિ નિર્ણય જોઈએ છે, અને તે સામાન્ય http-proxy લાઇન માંગે છે તે નથી.
TCP અંદર TCPની કિંમત
ટનલને TCP પર વહન કરવાથી બહારની સ્ટ્રીમ ક્રમમાં અને પુનઃપ્રેષણ સાથે રહે છે, અને અંદરનું ટ્રાફિક પણ સામાન્ય રીતે TCP હોય છે. બે પુનઃપ્રાપ્તિ પદ્ધતિઓ સંકલન કરતી નથી, તેથી એક ખોવાયેલ સેગમેન્ટ તે બહારની સ્ટ્રીમ વહેંચતું બધું પુનઃપ્રેષણ થાય ત્યાં સુધી થંભાવી શકે છે. આ સુસંગતતા માટે સાચી આપ-લે છે, મફત અપગ્રેડ નહીં.
જ્યારે નેટવર્ક બીજો વિકલ્પ ન આપે ત્યારે પ્રોક્સી માર્ગ વાપરો, અને નીતિ પરવાનગી આપે ત્યાં સીધો UDP માર્ગ પસંદ કરો. કોઈપણ રીતે, ફેરફાર પછી ખાતરી કરો કે એ જ પ્રોક્સી, ગંતવ્ય અને પ્રોફાઇલ આગલા તબક્કે પહોંચે છે; તે સરનામે પૃષ્ઠ લોડ કરતો બ્રાઉઝર બીજું પ્રોટોકોલ વાપરે છે અને ટનલ વિશે કંઈ સાબિત કરતું નથી.