Docker-ի և VM-ների տրաֆիկը OpenVPN-ի հետևում. երթուղե՞լ, թե՞ վերահամարակալել

Հոսթը զննում է թունելով, իսկ կողքի կոնտեյները ոչնչի չի հասնում։ Ավելի վատ է պորտ հրապարակել այն կոնտեյներից, որն ունի իր սեփական 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՝ յուրաքանչյուր հասցեում հրապարակելու փոխարեն։