બે DNS નામ, એક OpenVPN પોર્ટ: ખરેખર શું પસંદ કરે છે

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

રિઝોલ્વર શું પાછું આપે તેનાથી શરૂ કરો

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

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

ગણતરીમાં આવતું એકમાત્ર પસંદગીકર્તા પેકેટની અંદર જાય છે

HTTP આને Host હેડરથી સંભાળે છે, અને TLS ClientHello માં સર્વર નામ એક્સ્ટેન્શનથી, અને એ રીતે એક સરનામું એક શ્રોતા પાછળ ઘણી સાઇટને સેવા આપે છે. બંને કાર્ય કરે છે કારણ કે વાયર પ્રોટોકોલ ચોક્કસ સેવા માટે વિનંતી વહન કરે છે. OpenVPN વિશેની સુસંગત હકીકત એ છે કે મધ્યવર્તી બોક્સ તપાસે તે સ્તર પર આ બંને ક્ષેત્રોમાંથી એક પણ હાજર નથી.

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

પ્રોટોકોલ વિભાજક ક્યાં ટૂંકો પડે છે

સામાન્ય રીતે sslh પ્રોજેક્ટ દસ્તાવેજ કરે તે પ્રકારનો મલ્ટિપ્લેક્સર એક પોર્ટ પર સાંભળે છે, શરૂઆતના બાઇટ તપાસે છે અને કનેક્શન તે બેકએન્ડને સોંપે છે જે ઓળખાયેલો પ્રોટોકોલ બોલે છે. જ્યારે એક જ પોર્ટે SSH, HTTPS અને OpenVPN સાથે સેવા આપવી પડે ત્યારે આ ખરેખર મૂલ્યવાન છે.

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

બે સર્વરને ખરેખર અલગ પાડતી ગોઠવણીઓ

સૌથી સસ્તું પ્રામાણિક વિભાજન બીજું જાહેર સરનામું છે, દરેક ઇન્સ્ટન્સ માટે એક, અને હાલની પ્રોફાઇલ જરૂરી હોય તે પહેલેથી ધરાવે છે કારણ કે તે જુદા જુદા સરનામાં તરફ નિર્દેશ કરે છે. આગળનું એ જ સરનામા પર જુદો પોર્ટ છે, જે દરેક પ્રોફાઇલમાં એક સંખ્યા સિવાય કંઈ ખર્ચતું નથી. TCP અને UDP અલગ પોર્ટ કોષ્ટકો રાખે છે, તેથી 1194/tcp અને 1194/udp અસંબંધિત સોકેટ છે અને દરેકમાંથી એક એક જ હોસ્ટ પર સહઅસ્તિત્વ ધરાવી શકે છે; આ નામ-રૂટિંગ નહીં પણ પરિવહન વિભાજન છે, અને ઘણી વાર તેની સાથે ભૂલ થાય છે. બંને વિકલ્પો ફાયરવોલ સમીક્ષામાંથી પસાર થાય છે, કારણ કે નિયમ પેકેટમાં ખરેખર જે છે તેની સાથે મેળ ખાય છે.

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

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

બાંધતા પહેલાં પસંદગીકર્તા સાબિત કરો

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

ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager

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

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