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

બે નામ, બે પરિવહન

વેબસાઇટને પ્રોક્સી થયેલ રેકોર્ડ આપો જેથી તેનો HTTP અને HTTPS ટ્રાફિક Cloudflare દ્વારા પસાર થાય. VPN ને ફક્ત-DNS રેકોર્ડ આપો જે સીધો જાહેર VPN પ્રવેશ પર ઉકેલાય, અને ક્લાયંટને તે જ UDP કે TCP પોર્ટ વાપરવા દો જેના માટે તે ગોઠવાયેલ છે.

બંને નામ એક જ મૂળ મશીન પર પહોંચી શકે છે. ફરક એ છે કે ક્લાયંટ અને એ મશીન વચ્ચે શું થાય છે, અને એ ફરક જ વિભાજનનો હેતુ છે.

Cloudflare નું નેટવર્ક-પોર્ટ સંદર્ભ સૂચિ આપે છે કે સામાન્ય વેબ પ્રોક્સી કયા પોર્ટ સ્વીકારે છે. એ સૂચિ એ પોર્ટ પરના HTTP અને HTTPS વિશે છે, સંખ્યા વહેંચતા મનસ્વી પ્રોટોકોલ વિશે નહીં.

પોર્ટ એ પ્રોટોકોલ નથી

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

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

ફક્ત-DNS રેકોર્ડ એ કામ કરતો કંટાળાજનક જવાબ છે, અને પહેલા તેની જ તરફ હાથ લંબાવવો જોઈએ.

એક મશીનને હજી પણ બે શ્રોતા જોઈએ

અલગ નામો બે પ્રક્રિયાઓને એક જ સમયે એક જ સરનામું, પોર્ટ અને પરિવહન બાંધવા દેતા નથી. જો વેબ સર્વર પહેલેથી જ બધા સરનામાં પર TCP 443 ધરાવે છે, તો OpenVPN ઘટક જાણી જોઈને કરેલી ગોઠવણ વિના તેને પણ લઈ શકતું નથી.

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

પ્રમાણપત્રો જે જોડાણનું રક્ષણ કરે છે તેને અનુસરે છે

બ્રાઉઝરનું Cloudflare સાથેનું TLS જોડાણ અને Cloudflareનું તમારા મૂળ સાથેનું જોડાણ બે અલગ પ્રમાણપત્રો સાથેની બે અલગ સંબંધો છે. બ્રાઉઝર ધારનું પ્રમાણપત્ર જુએ છે. મૂળ Cloudflareને પોતાનું પ્રમાણપત્ર રજૂ કરે છે, અને Cloudflare Origin CA પ્રમાણપત્ર બરાબર એ બીજા સંબંધ માટે જ છે.

એ મૂળ પ્રમાણપત્ર પર Cloudflare Full (strict) સ્થિતિમાં ભરોસો કરે છે અને તે સામાન્ય રીતે વિશ્વસનીય બ્રાઉઝર પ્રમાણપત્ર નથી. જો કોઈ ફક્ત-DNS હોસ્ટનામ સીધું મુલાકાત કરે અને ચેતવણી મળે, તો તે બદલાયેલા ભરોસા-માર્ગનું અપેક્ષિત પરિણામ છે, એન્ક્રિપ્શન અટક્યાનો પુરાવો નથી.

તેથી સીધી મુલાકાત લેવાયેલી વેબસાઇટને એવી પ્રમાણપત્ર શૃંખલા જોઈએ જેના પર તેના બ્રાઉઝર ભરોસો કરે. તે એવી પ્રોક્સી થયેલી સાઇટ સાથે સહઅસ્તિત્વ ધરાવી શકે છે જેનું મૂળ મુલાકાત માટે બિલકુલ નથી.

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

એક્સપોઝર નામને અનુસરે છે

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

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

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

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

સંબંધિત લેખો