શું TLS રેપર તમને ખાનગી નેટવર્ક આપે છે? સામાન્ય રીતે નહીં

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

સેવા રેપર ખરેખર શું જોડે છે

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

તેથી રેપર વિશેનો ઉપયોગી પ્રશ્ન એ નથી કે તે એન્ક્રિપ્ટ કરે છે કે નહીં, પણ એ છે કે તે જે સાંકળ બનાવે છે તેના દરેક છેડે શું છે.

application -> local listener -> TLS connection -> remote listener -> configured backend

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

TLS ચેનલ ક્યાં પૂરી થાય છે તે શોધો

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

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

ss -ltnp | grep -F 443
openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates

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

રાઉટેડ VPN શું ઉમેરે છે જે રેપર નથી કરતું

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

પ્રવેશ પરવાનગી ફરી અલગ છે. ક્લાયન્ટને પ્રમાણિત કરતું VPN હજી પણ એવી અધિકૃતિ માંગે છે જે કહે કે ક્લાયન્ટ કયા સ્રોતો સુધી પહોંચી શકે છે, અને પીઅરને પ્રમાણિત કરતું રેપર હજી પણ એવા બેકએન્ડની માંગ કરે છે જે પોતાની પરવાનગીઓ લાગુ કરે.

એક કાયદેસર સંયોજન છે: જાણી જોઈને સમર્થિત TCP ગોઠવણી પર TLS રેપરની અંદર વહન કરાયેલ VPN પ્રોટોકોલ. તે બે સ્તરોને થપાટી દે છે, અને તે રેપર અને VPNને એક જ પ્રકારની વસ્તુ બનાવતું નથી.

જે સીમા નિષ્ફળ જાય છે તેની સરખામણી કરો

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

નકારાયેલી બેકએન્ડ વિનંતીને ફ્રન્ટ-એન્ડ ઓળખ ચકાસણી બંધ કરીને ક્યારેય સુધારવી ન જોઈએ. તે નિદાન કરી શકાય તેવી અધિકૃતિ નિષ્ફળતાને નિદાન ન કરી શકાય તેવી વિશ્વાસ નિષ્ફળતા સાથે બદલે છે.

curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30

નામને પસંદ કરેલા સરનામે પિન કરવું નામ ઉકેલને પહોંચથી અલગ કરે છે, અને સામાન્ય રીતે બેમાંથી કયું તૂટ્યું છે તે જાણવાનો આ સૌથી ઝડપી રસ્તો છે.

મહત્વની તુલના સુરક્ષિત છેડા-જોડી, વહન કરાયેલ પેલોડ, તેનો ઉપયોગ કરતી એપ્લિકેશનો અને ગંતવ્ય પર લાગુ કરાયેલ પરવાનગીનું નામ આપે છે. TLS તે વર્ણનમાં ફાળો આપે છે પણ તેને પૂર્ણ કરતું નથી.