ઓફિસ અને VPN માટે એક જ URL? મંજૂર સૂચિની દંતકથા કેમ નિષ્ફળ જાય છે

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

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

દંતકથા: જોડાવું એ રૂટિંગ નથી

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

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

ત્રણ વિનંતી-સ્થિતિઓ, બે મંજૂર એગ્રેસ

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

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

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

નિર્ણય જ્યાં લેવાય છે ત્યાં જ સ્રોત વાંચો

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

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

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

પછી બીજું સરનામા-કુટુંબ તપાસો. ફક્ત IPv4 આવરી લેતો નિયમ-સમૂહ AAAA પર પણ જવાબ આપતા હોસ્ટનામ માટે અધૂરો નિર્ણય છે, અને કાર્યરત IPv6 ધરાવતો ક્લાયન્ટ એ જ એપ્લિકેશન સુધી એવા માર્ગે પહોંચશે જે તમે ક્યારેય સમીક્ષા કર્યો નથી.

વિભાજિત ટનલ: એ વિનંતી જે ક્યારેય અંદર આવતી નથી

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

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

નકાર સાબિત કરો, પછી પુનઃપ્રાપ્તિ

કોષ્ટકની દરેક હાર પર ઊભેલા ક્લાયન્ટથી, વાસ્તવિક નિર્ણયનો ઉપયોગ કરતી વિનંતીથી પરીક્ષણ કરો. અસંબંધિત સરનામું દર્શાવતા કોઈ પૃષ્ઠ સામેની પહોંચ-ચકાસણી કંઈ સાબિત કરતી નથી, કારણ કે એ ગંતવ્ય એપ્લિકેશન કરતાં અલગ માર્ગ અનુસરી શકે છે.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

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

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