Ինչու macvlan բեռնարկղը չի կարող պատասխանել VPN հաճախորդին

Պատկերացրեք Linux հոսթ, որը վերջացնում է VPN-ը և միևնույն ժամանակ macvlan ցանցում բեռնարկղ է աշխատեցնում։ LAN-ը 192.168.60.0/24 է, բեռնարկղը պահում է 192.168.60.210-ը, իսկ VPN հաճախորդները գալիս են 10.95.0.0/24-ից։ Հաճախորդը հասնում է ծառայությանը, պատասխանը երբեք չի վերադառնում, և հոսթի վրա յուրաքանչյուր firewall կանոն ճիշտ է թվում։ Երկու առանձին սահմանափակում առաջացնում են այդ ախտանիշը, և մեկի ուղղումը թողնում է մյուսին իր տեղում։

Երկու սահմանափակում, մեկ ախտանիշ

Առաջին սահմանափակումը մեկուսացումն է՝ Docker-ի macvlan դրայվերը թույլ չի տալիս բեռնարկղին ծնող ինտերֆեյսի միջոցով խոսել իր սեփական հոսթի հետ։ Երթևեկությունը հոսթի stack-ի և բեռնարկղի միջև ուղի չունի, անկախ նրանից, թե ինչպես են գրված երթուղիները հոսթի վրա։

Երկրորդ սահմանափակումը վերադարձի ուղին է։ Բեռնարկղի լռելյայն դարպասը սովորաբար LAN երթուղիչն է, ուստի VPN հաճախորդին հասցեագրված պատասխանը դուրս է գալիս այդ երթուղիչով։ Եթե երթուղիչը VPN լողավազան վերադառնալու երթուղի չունի, պատասխանը ինչ-որ տեղ մեջտեղում թափվում է։

Այս երկու խափանումները հաճախորդի տեսանկյունից նույնն են թվում՝ հարցում, որը գալիս է, և պատասխան, որը երբեք չի գալիս։ Նրանց տարբեր վերանորոգում է պետք, և լայն masquerade կանոնը կարող է թաքցնել, թե դրանցից որն է դեռ կոտրված։ Այդ պատճառով առաջին փորձարկումը բեռնարկղի կողմում գրավումն է, այլ ոչ թե firewall-ի ևս մեկ փոփոխությունը։ Եթե հարցումն այնտեղ երբեք չի երևում, ուրեմն գործում է մեկուսացման սահմանափակումը։

Կառուցեք հոսթի կողմի shim-ը, նեղ

Երկրորդ macvlan ինտերֆեյսը հոսթի վրա, որը կամուրջի ռեժիմում միացված է նույն ծնողին, հոսթի stack-ին տալիս է սեփական ինքնություն այդ LAN սեգմենտում։ Դրա համար առանձնացրեք հասցե DHCP լողավազանից դուրս և բեռնարկղի տիրույթից դուրս, և միայն բեռնարկղն անցկացրեք դրա միջով։

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

Առաջին հրամանը ստեղծում է ինտերֆեյսը կամուրջի ռեժիմում, ինչը այս դրայվերի փաստաթղթավորված լռելյայնն է և այն ռեժիմը, որը ցանկանում եք հոսթ-բեռնարկղ երթևեկության համար։ Երկրորդը նշանակում է /32, որպեսզի հասցեն չբախվի LAN նախածանցի հետ, իսկ չորրորդը shim-ի միջով ուղարկում է միայն բեռնարկղի հասցեն։

Չուղղորդեք ամբողջ LAN-ը նոր ինտերֆեյսով։ Սովորական միացված երթուղին մնում է ինչպես կա, և հոսթի երթուղին դիտավորյալ նեղ է, որպեսզի մեկ բեռնարկղ ուղի ստանա, առանց սեգմենտի մնացած մասի վարքը փոխելու։ Shim-ին ուղղված լռելյայն երթուղին այլ հետևանքներով այլ ձևավորում կլիներ։ Պահեք այն կոնկրետ, և վնասի շառավիղը մնում է փոքր։

Այս հրամանները փոխում են ցանցային կարգավորումները աշխատող հոսթի վրա։ Սարքի կամ կառավարվող հարթակի վրա օգտագործեք այդ հարթակի աջակցվող կարգավորման մեխանիզմը, քանի որ root-shell-ում ինտերակտիվ փոփոխությունը կարող է չդիմանալ թարմացմանը։

Որոշեք, թե ինչպես է պահվում աղբյուրը

Shim-ը տեղում լինելու դեպքում բեռնարկղը կարող է հասնել հոսթին, և հարցը դառնում է, թե պատասխանն ինչ աղբյուրի հասցե է կրում։ Բնօրինակ VPN աղբյուրը պահելը ավելի մաքուր մոդել է՝ բեռնարկղը տեսնում է հաճախորդի իրական հասցեն, և ծառայության մատյաններն ու մուտքի կանոնները կարող են օգտագործել այն։

Որպեսզի դա աշխատի, բեռնարկղի ցանցային կազմաձևը այս ուղու համար պետք է 10.95.0.0/24-ի երթևեկությունն ուղարկի 192.168.60.250-ին որպես իր դարպաս։ Դա աջակցվող երթուղու կամ դարպասի կարգավորում է հենց բեռնարկղի կազմաձևում, ոչ թե հոսթի կողմի հնարք։ Հաստատեք այն բեռնարկղի ներսից, փոխարենը ենթադրելու, որ կարգավորումն ուժի մեջ է մտել։ Լռելյայն դարպասը, որը դեռ ցույց է տալիս LAN երթուղիչին, կշարունակի պատասխաններն ուղարկել նույն անցքի մեջ։

Եթե հաստատված ձևավորումը փոխարենը թաքցնում է VPN աղբյուրները, սահմանափակեք թարգմանությունը նեղ՝ իրական VPN լողավազանը, shim-ը որպես ելքային ինտերֆեյս, և կոնկրետ բեռնարկղն ու ծառայությունը։

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Համապատասխանեցրեք shim-ին որպես ելքային ինտերֆեյս, ոչ թե թունելին։ Կանոնը, որը թունելն անվանում է ելքային ինտերֆեյս, չի համապատասխանի դեպի բեռնարկղ գնացող փաթեթին, և հենց այդ սխալն է սովորաբար պարունակում նման տեղադրումը։ Պահեք կանոնը նույնքան նեղ, որքան վերևի նախադասությունը, և վերանայեք այն, երբ լողավազանը փոխվի։

Ստուգեք հաճախորդից, ոչ թե հոսթից

Հենց հոսթից եկող, shim-ի հասցեին կապված հարցումը ապացուցում է, որ shim-ը կարող է հասնել բեռնարկղին։ Այն չի ապացուցում, որ բեռնարկղը կարող է երթևեկությունը հետ ուղարկել պահված 10.95.0.x աղբյուրին, քանի որ այդ փորձարկման մեջ աղբյուրի հասցեն հենց shim-ինն է։

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

Առաջին հրամանը ստուգում է հոսթից բեռնարկղ հատվածը, իսկ երկրորդը ցույց է տալիս, թե իրականում ինչ է անցնում shim-ով, մինչ իրական VPN հաճախորդը հարցումն է ուղարկում։ Նայեք աղբյուրի հասցեին մուտքի ուղու վրա և նրան, թե արդյոք նույն հոսքով պատասխան է հայտնվում։

Հոսթի վրա պետք է միացված լինի փոխանցումը, և փոխանցման ուղուն անհրաժեշտ է թույլտվություն VPN լողավազանից դեպի shim ծառայության պորտով, ինչպես նաև հաստատված պատասխանների համար։ Հոսթի INPUT կանոնը չի լիազորում փոխանցվող երթևեկությունը, և դա հաճախակի պատճառ է, որ փաթեթը թափվում է այն բանից հետո, երբ երթուղավորումը ճիշտ է թվում։

Գործարկեք իրական հավելվածը իրական հավատարմագրերով, ապա ստուգեք, որ նույն բեռնարկղի վրա երկրորդ, անկապ ծառայությունը դեռ մերժում է ձեզ։ Եթե այն աշխատեցնելու միակ միջոցը բոլոր փոխանցման կանոնները բացելն էր, ձևավորումը ավարտված չէ։ Նկատեք նաև, թե ծառայությունն ինչ աղբյուրի հասցե է գրանցել, քանի որ դրանից հետո հենց այն կօգտագործեն նրա սեփական մուտքի կանոնները։