Docker માં OpenVPN: ન્યૂનતમ ક્લાયન્ટને જરૂરી રનટાઇમ કરાર

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

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

કન્ટેનર શું મેળવે છે અને શું નહીં

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

services:
  vpn:
    image: ${VPN_CLIENT_IMAGE:?set the reviewed image reference}
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - ./vpn:/vpn:ro
    working_dir: /vpn
    entrypoint: ["openvpn"]
    command: ["--config", "/vpn/client.ovpn"]

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

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

ક્ષમતાઓ, entrypoint અને તેમની વચ્ચેની જાળ

બે સેટિંગ્સ જરૂરી છે અને તે અસંબંધિત કામ કરે છે. NET_ADMIN કન્ટેનરના નેમસ્પેસમાં ઇન્ટરફેસ અને રૂટની ચેતાક્રિયાને મંજૂરી આપે છે. /dev/net/tun ડિવાઇસ એન્ટ્રી પ્રોસેસને ટનલ ડિવાઇસ ખોલવાની જ મંજૂરી આપે છે. એકને બીજા વિના આપવાથી સ્પષ્ટ નિષ્ફળતા થાય છે, જે અનુકૂળ છે: ગેરહાજર TUN ડિવાઇસ ખોલતી વખતે નિષ્ફળ જાય છે, જ્યારે ગેરહાજર ક્ષમતા ત્યારે નિષ્ફળ જાય છે જ્યારે ક્લાયન્ટ ઇન્ટરફેસ ગોઠવવાનો પ્રયાસ કરે છે.

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

entrypoint ને ઓવરરાઇડ કરવું એ ડંખ મારતો ભાગ છે. openvpn ને સીધું બોલાવવું સામાન્ય ઇમેજ માટે સાચું છે અને એવી કોઈપણ પ્રોડક્ટ ઇમેજ માટે ખોટું છે જેની સ્ટાર્ટઅપ સ્ક્રિપ્ટ ડેમન ચલાવતા પહેલા ફાયરવોલ નિયમો, રિઝોલ્વર ફાઇલો કે ક્રેડેન્શિયલ તૈયાર કરે છે. તે સ્ક્રિપ્ટ ઓવરરાઇડ કરવાથી તૈયારી છૂટી જાય છે અને અડધા-ગોઠવાયેલા નેમસ્પેસમાં ઊભેલી ટનલને ડિબગ કરવાનું રહે છે.

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

નેમસ્પેસની અંદરથી ચકાસો, હોસ્ટથી નહીં

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

docker compose up -d
docker compose logs --tail 40 vpn
docker compose exec vpn ip -br addr
docker compose exec vpn ip route

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

પછી તમને મહત્ત્વનું ગંતવ્ય તે નેમસ્પેસમાંથી ચકાસો જે ટનલનો ઉપયોગ કરવો જોઈએ, એપ્લિકેશનથી અને ફક્ત ping થી નહીં. નામ ઉકેલવું એ અલગ નિષ્ફળતા છે જે સ્પષ્ટપણે ચકાસવા યોગ્ય છે: પુશ કરેલું DNS એડ્રેસ કન્ટેનરના રિઝોલ્વરને પોતાની જાતે અપડેટ કરતું નથી, અને pushને અવગણતો સ્વતંત્ર ક્લાયન્ટ ઇમેજે ગોઠવેલા માધ્યમથી નામ ઉકેલશે.

ડિસ્કનેક્ટેડ સ્થિતિ કરારનો ભાગ છે

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

જો કાર્યભારે ક્યારેય સામાન્ય માર્ગનો ઉપયોગ ન કરવો જોઈએ, તો ફાયરવોલ નિયમો અને નેમસ્પેસની અંદર તૈયારી સંકેત સાથે તેને સ્પષ્ટ રીતે ડિઝાઇન કરો. Kill switch એ નીતિ છે જે તમે લખો છો અને ચકાસો છો, કન્ટેનરમાં ક્લાયન્ટ ચલાવીને વારસામાં મળતી મિલકત નહીં.

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