OpenVPN પાછળ Docker અને VM ટ્રાફિક: રૂટ કે ફરી નંબર?

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

ત્રણ પ્રશ્નો નક્કી કરે છે કે તમે બેમાંથી કયો કિસ્સો જોઈ રહ્યા છો, અને તેમાં લગભગ એક મિનિટ લાગે છે.

એકસરખા દેખાતા બે ખામી

પ્રથમ રિટર્ન-પાથની સમસ્યા છે. પ્રકાશિત પોર્ટ કન્ટેનરમાં અનુવાદિત થાય છે, વિનંતી આવે છે, અને જવાબ હોસ્ટના ડિફોલ્ટ રૂટ દ્વારા રૂટ થાય છે, જેને OpenVPN ક્લાયન્ટે tun0 તરફ વાળ્યો છે. જવાબ એવા સરનામેથી નીકળે છે જેની દૂરના પીઅરને અપેક્ષા નથી, અને તે નકારી કાઢવામાં આવે છે. બીજી પ્રિફિક્સ અથડામણ છે: Docker નો ડિફોલ્ટ બ્રિજ 172.17.0.0/16 ધરાવે છે અને કોર્પોરેટ ટનલ એ જ શ્રેણી ધકેલે છે.

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

ત્રણ પ્રશ્નોથી નક્કી કરો

પ્રશ્ન એક: VPN બંધ કરો ત્યારે ખામી મટી જાય છે? ટનલ બંધ હોય ત્યારે બધું કામ કરે તો રિટર્ન પાથ પર શંકા કરો. પ્રશ્ન બે: શું ip route show table all એ જ પ્રિફિક્સ બે વાર સૂચિબદ્ધ કરે છે, એક વાર બ્રિજ પર અને એક વાર tun0 પર? એ જ અથડામણ છે. પ્રશ્ન ત્રણ: અસરગ્રસ્ત સરનામું કન્ટેનર છે, NAT ગેસ્ટ છે કે બ્રિજ કરેલ ગેસ્ટ છે?

ત્રીજો પ્રશ્ન મહત્વનો છે કારણ કે દરેકનો અલગ યોગ્ય ઉકેલ છે, અને કન્ટેનરનો ઉકેલ libvirt ગેસ્ટ પર લાગુ કરવો એક સાંજ વેડફે છે.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

રિટર્ન પાથ: એક સ્રોત સરનામા માટે ટેબલ

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

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

જે પેકેટનો સ્રોત એ સરનામું છે તે પહેલા ટેબલ 10 જુએ છે, અને ટેબલ 10 તેને ટનલને બદલે બ્રિજ ગેટવે પર મોકલે છે.

આનાથી ચકાસો: ip route get 1.1.1.1 from 172.22.0.3. જવાબમાં બ્રિજ ઇન્ટરફેસનું નામ હોવું જોઈએ, tun0 નહીં. આ રીતે ઉમેરાયેલા નિયમો રીબૂટ પર અદૃશ્ય થાય છે, તેથી તેમને કન્ટેનર ધરાવતા unit અથવા નેટવર્ક હૂકમાં મૂકો.

એ જ પેટર્ન WireGuard કન્ટેનર માટે પણ કામ કરે છે, જ્યાં રિપ્લાય પાથને પણ સ્પષ્ટ નિયમની જરૂર પડે છે.

પ્રિફિક્સ અથડામણ: બ્રિજને ફરી નંબર કરો

રૂટ ટેબલ એક પ્રિફિક્સને એક જગ્યાએ મોકલે છે. જો VPN 172.17.0.0/16 ધકેલે અને Docker નો બ્રિજ પહેલેથી ત્યાં હોય, તો નીચું મેટ્રિક જીતે છે: Docker પોતાનો જોડાયેલ રૂટ મેટ્રિક 0 પર સ્થાપિત કરે છે, અને ધકેલાયેલ રૂટ 50 પર આવે છે. પછી Docker કામ કરતું રહે ત્યારે ટનલ તૂટેલી દેખાય છે, અથવા ઊલટું, ઇન્સ્ટોલેશન ક્રમ પ્રમાણે. મેટ્રિક સાથે લડવાને બદલે બ્રિજને ફરી નંબર કરો.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

ફેરફાર પછી Docker ફરી શરૂ કરો અને જૂના પૂલ સાથે બનેલા નેટવર્ક ફરી બનાવો. તેના બદલે મેટ્રિક બદલવું માત્ર સંઘર્ષને આગલા બૂટ પર ખસેડે છે.

VM ને ફરી બીજો જવાબ જોઈએ

ડિફોલ્ટ NAT નેટવર્ક પરનો libvirt ગેસ્ટ હોસ્ટનું રૂટિંગ વારસાઈમાં લે છે અને હોસ્ટની ટનલ ડિફોલ્ટ રૂટ ધરાવતાં જ બહાર પહોંચવાનું બંધ કરે છે. ગેસ્ટને બ્રિજ કરેલ કે macvtap ઉપકરણ પર ખસેડવાથી તેને ભૌતિક નેટવર્ક પર પોતાનો રસ્તો મળે છે. virt-manager માં હાર્ડવેર ઉમેરો, Network પસંદ કરો, સ્રોતને macvtap હોસ્ટ ઉપકરણ પર સેટ કરો, મોડેલ તરીકે virtio રાખો, પછી જૂનું NAT ઇન્ટરફેસ નિષ્ક્રિય કરો.

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

જે ગેસ્ટને ફક્ત હોસ્ટનું LAN જોઈએ છે તેના માટે વેન્ડરના ક્લાયન્ટમાં ખૂટતો સ્વિચ હોઈ શકે: Mullvad સાથે mullvad lan set allow libvirt ને સ્પર્શ કર્યા વિના સ્થાનિક પહોંચ પુનઃસ્થાપિત કરે છે. અને જ્યારે કન્ટેનર ફક્ત ટનલ દ્વારા જ પહોંચી શકાય તેવું હોવું જોઈએ, ત્યારે પ્રકાશિત પોર્ટને ટનલ સરનામા સાથે બાંધો, -p 10.8.0.5:8080:8080, દરેક સરનામા પર પ્રકાશિત કરવાને બદલે.