ફક્ત VPN માટે NGINX સાઇટ: લિસનર, ફાયરવોલ અને HTTP પરવાનગી યાદી

ખાનગી NGINX સાઇટને બંધાયેલ VPN સોકેટ, મર્યાદિત હોસ્ટ ઇનપુટ નિયમ અને અકબંધ HTTP ઍક્સેસ યાદીની જરૂર છે. એક સર્વર બ્લોક નહીં, ત્રણેય ચકાસો.

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

ઉદાહરણ tun0 પર 10.90.0.1 પર Linux OpenVPN ગેટવે, 10.90.0.0/24 માં ક્લાયન્ટ, સાચવેલા સ્રોત અને આ પ્રવેશ માટે અનામત TCP 8443 વાપરે છે. મૂલ્યો સમાયોજિત કરો, સ્તરો રાખો.

હોસ્ટનામ નહીં, સોકેટથી શરૂ કરો

HTTPS લિસનરને ટનલ સરનામા અને સમર્પિત પોર્ટ સાથે બાંધો. ચોક્કસ સરનામું વાઇલ્ડકાર્ડ સોકેટ અને નામ-તપાસ કરતાં વિચારવું સરળ છે, કારણ કે કર્નલ પોર્ટ બીજા સ્થાનિક સરનામાને આપશે નહીં.

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

    ssl_certificate     /etc/nginx/tls/admin-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/admin-key.pem;

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

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

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

તે સામગ્રી માટે અન્ય દરેક લિસનર બંધ કરો

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

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

બંને સરનામા કુટુંબો તપાસો. IPv4 બાઇન્ડ IPv6 સોકેટને અસ્પૃશ્ય રાખે છે, અને નવું A રેકોર્ડ જૂનો AAAA જવાબ પાછું ખેંચતું નથી જે હજી જાહેર માર્ગ તરફ નિર્દેશ કરે છે.

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

હોસ્ટ પર આવતા માર્ગનો વ્યાપ મર્યાદિત કરો

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

ડિફોલ્ટ-નકાર ઇનકમિંગ નીતિ અને આ સેવા માટે વિશાળ પરવાનગી વગર, મર્યાદિત નિયમ ટનલ, સ્રોત શ્રેણી, લક્ષ્ય અને પોર્ટને સાથે નામ આપે છે:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

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

તે નિયમ હોસ્ટ ઇનપુટ છે, બીજી LAN મશીન તરફનો માર્ગ નહીં, અને ગેટવેનું બાહ્ય OpenVPN લિસનર અલગ સેવા જ રહે છે. જો સાઇટ પહેલાં જાહેર હતી, તો જૂનું પ્રવેશદ્વાર કેવી રીતે નિવૃત્ત થશે અને હાલનાં સત્રો કેવી રીતે સંભાળાશે તેનું આયોજન કરો.

સ્થાનો બદલાય ત્યારે HTTP યાદી અકબંધ રાખો

NGINX allow અને deny એન્ટ્રીઓ ક્રમમાં મૂલ્યાંકન કરે છે, અને ઉપરની સર્વર-સ્તરીય યાદી અંતિમ deny પહેલાં જાહેર કરેલા સમૂહને પ્રવેશ આપે છે. ઍક્સેસ મોડ્યુલ એ પણ નોંધે છે કે કોઈપણ ઍક્સેસ એન્ટ્રી વ્યાખ્યાયિત કરતું સ્થાન પિતૃ યાદીને બદલે પોતાની યાદી વાપરે છે. ક્રમ એન્ટ્રીઓ જેટલો જ મહત્ત્વનો છે.

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

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

HTTP નકાર TCP કનેક્શન NGINX સુધી પહોંચ્યા પછી થાય છે. તે નેટવર્ક પ્રતિબંધને પૂરક બને છે, અને એપ્લિકેશનની પોતાની અધિકૃતિ હજી દરેક વપરાશકર્તા પર લાગુ પડે છે.

જીવંત માર્ગ અને નિષ્ફળતાનો કિસ્સો ચકાસો

રૂપરેખા પાર્સર ચલાવો, સાંભળતા સોકેટનું નિરીક્ષણ કરો, પછી ઇચ્છિત ક્લાયન્ટથી નવી નામવાળી વિનંતી કરો. ખાતરી કરો કે પ્રમાણપત્ર માન્ય છે, DNS નામ બંધાયેલા સરનામા પર ઉકેલાય છે અને જવાબ અપેક્ષિત રૂટથી આવે છે.

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

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

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

સંબંધિત લેખો