VPN કન્ટેનરની અંદર વેબ ઇન્ટરફેસ સુધી પહોંચવું: પોર્ટનો માલિક પસંદ કરો

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

પોર્ટ નેમસ્પેસનો માલિક કોણ છે

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

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

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

એપને નેમસ્પેસ જ્યાં અપેક્ષા રાખે ત્યાં સાંભળવા દો

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

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

એપની અંદરની લિસનર યાદી બાંધવાના સરનામા વિશે સત્ય કહે છે, અને docker port કહે છે કે માલિકે ખરેખર શું પ્રકાશિત કર્યું. જો પ્રથમ 127.0.0.1 બતાવે અને બીજું હોસ્ટ મેપિંગ બતાવે, તો તમે VPN કન્ફિગરેશનને સ્પર્શ કર્યા વગર જ વિસંગતિ શોધી કાઢી છે.

મેનેજમેન્ટ માર્ગ કેવી રીતે અંદર આવે તે પસંદ કરો

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

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

બધું ખોલ્યા વગર મેનેજમેન્ટ પોર્ટ ખોલો

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

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

મેનેજમેન્ટ ઉપકરણથી ચકાસો, પછી પાછળથી ફરી ચકાસો

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

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