બે નેટવર્કવાળું કન્ટેનર ખોટું ગેટવે પસંદ કરે છે

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

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

ડિફોલ્ટ રૂટ ખોટા નેટવર્ક પર કેમ પડે છે

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

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

gw_priority વડે ગેટવે પિન કરો

Compose 2.33.1 આવૃત્તિથી દરેક સેવા-થી-નેટવર્ક જોડાણ પર gw_priority આપે છે, અને સૌથી મોટી સંખ્યા જીતે છે. દરેક સેવા માટે અલગ ગેટવે કી નથી, તેથી મૂલ્ય સેવાના networks બ્લોક હેઠળ આવે છે. નીચેનું ઉદાહરણ ડિફોલ્ટ control ને આપે છે જ્યારે office તેના સીધા જોડાયેલા LAN માટે પહોંચી શકાય તેવું રહે છે.

services:
  vpn:
    networks:
      control:
        gw_priority: 1
      office:
        gw_priority: 0

networks:
  control:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.50.0/24
  office:
    driver: macvlan
    driver_opts:
      parent: eno1.120
      macvlan_mode: bridge
    ipam:
      config:
        - subnet: 192.168.120.0/24
          ip_range: 192.168.120.192/27
          gateway: 192.168.120.1

બ્લોકને બે અલગ નિયંત્રણ તરીકે વાંચો: gw_priority ડિફોલ્ટ રૂટ નક્કી કરે છે અને ipam વિભાગ સરનામાંકન નક્કી કરે છે. ફક્ત subnet બદલવાથી એક્ઝિટની પસંદગી અકબંધ રહે છે, અને આ સુધારો અડધોઅધૂરો લાગુ થવાનો આ સૌથી સામાન્ય રસ્તો છે. પ્રાયોરિટીઓને જે નેટવર્ક પર તેઓ રાજ કરે તેની બાજુમાં રાખો જેથી આગલા વાચકને નિર્ણય શોધવો ન પડે.

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

ખરેખર કયું નેટવર્ક ડિફોલ્ટ રૂટ વહન કરે છે તે ચકાસો

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

docker compose config --quiet
docker exec vpn ip -4 route show default
docker exec vpn cat /proc/net/route

સાચું પરિણામ બ્રિજ ઉપકરણ અને 172.30.50.1 નામ આપે છે; ખોટું પરિણામ 192.168.120.1 અને macvlan ઉપકરણ આપે છે. જો ઇમેજમાં iproute2 પેકેજ ન હોય, તો /proc ફાઇલ હજી પણ ડિફોલ્ટ રૂટ જણાવે છે, લક્ષ્ય 00000000 અને ગેટવેના બાઇટ ઉલટાવેલા. ઉપકરણનાં નામ અસ્પષ્ટ હોય ત્યારે ઇન્ટરફેસ કોલમને docker inspect સાથે સરખાવો.

macvlan ભૌતિક પોર્ટ છે, બ્રિજનું ક્લોન નહીં

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

macvlan_mode: bridge સેટિંગ macvlan ડ્રાઇવરની એક મોડ છે, Dockerનું સૉફ્ટવેર બ્રિજ નહીં, અને passthru ડિફોલ્ટ નહીં પણ અલગ વિશેષ મોડ છે. Linux macvlan કન્ટેનરને તેના પોતાના હોસ્ટ સુધી પહોંચતું પણ અટકાવે છે એ જ પેરેન્ટ દ્વારા, અને તેથી જ કંટ્રોલ બ્રિજ રાખવામાં આવે છે, એક જોડાણ બંને કામ કરશે એવી અપેક્ષા રાખવાને બદલે.

Compose તેને જો તે પહેલાં VLAN પેરેન્ટનું નામ આપો

Docker eno1.120 જેવા બિંદુવાળા પેરેન્ટને 802.1Q સબ-ઇન્ટરફેસ તરીકે ગણે છે અને VLAN ઉપકરણ જાતે બનાવે છે. એ સુવિધાની મર્યાદા છે: વ્યુત્પન્ન નામ ભૌતિક ઇન્ટરફેસના નામ પર આધારિત છે, અને લાંબા નામ પરિણામને આસપાસનાં સાધનોની અપેક્ષાથી આગળ ધકેલી શકે છે. હોસ્ટના નેટવર્ક કન્ફિગમાં નામવાળું VLAN ઇન્ટરફેસ બનાવીને parent તેની તરફ દિશામાન કરવાથી બંને છેડા અનુમાનિત રહે છે.

યાદ રાખો કે networks હેઠળની કી Compose નામ છે, Linux ઉપકરણ નહીં. હોસ્ટ પર office નામનું ઇન્ટરફેસ શોધવું નિષ્ફળ જશે, કારણ કે કર્નલ ફક્ત પેરેન્ટ ઇન્ટરફેસ અને કન્ટેનર પાછળની veth જોડી જુએ છે.

ઉપર VPN માટે જગ્યા કરો

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

VPN શરૂ થયા પછી અને ફરી જોડાયા પછી પણ સરનામાં, રૂટ અને સેવાનો માર્ગ ફરી ચકાસો, કારણ કે ફરી જોડાવાના સમયે જ હાથે ઉમેરેલો રૂટ અદૃશ્ય થાય છે. પહેલી કસોટી પહેલાં અપેક્ષિત ટેબલ લખી રાખો જેથી પછીની સરખામણી સ્મૃતિકસરત નહીં પણ diff બને. નેટવર્કની કાયમી માલિકી Composeમાં રાખો અને VPN કન્ફિગને ફક્ત તેની પોતાની નીતિ રાખવા દો.