એક સાર્વજનિક પ્રોક્સી VPN દ્વારા ખાનગી ઉદ્ગમ સુધી કેવી રીતે પહોંચે છે

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

આકૃતિમાં એકસરખા દેખાતા બે મોડેલ

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

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

TLS ક્યાં થંભે છે, અને તે ખરેખર શું સાબિત કરે છે

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

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

ફોરવર્ડ કરેલા હેડર પર ફક્ત પ્રોક્સી તરફથી જ ભરોસો રાખો

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

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

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

ઉદ્ગમને બરાબર એક જ જગ્યાએથી સુલભ રાખો

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

ss -ltnp | grep -E ':(80|443)'

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