Docker կոնտեյները հասանելի չէ VPN-ում? Համեմատեք ենթացանցերը
Docker-ը տալիս է ենթացանց, որը VPN-ն նույնպես պահանջում է։ Համեմատեք երկու հասցեային պլանները, ապա ընտրեք վերանորոգում, որը դիմանում է վերամիացմանը։
Կոնտեյներները պատասխանում են գրասենյակի LAN-ում, ապա դադարում են պատասխանել այն պահին, երբ միանում է ընկերության VPN-ը։ Կոնտեյների մեջ ոչինչ չի փոխվել՝ ոչ վերագործարկում, ոչ պատկերի թարմացում, ոչ կոնֆիգուրացիայի փոփոխություն։ Փոխվել է հոսթի երթուղավորման աղյուսակը, որտեղ թունելի ավելացրած երթուղին այժմ ծածկում է Docker-ի տված հասցեն։ Նախքան ենթացանցը խմբագրելը կամ VPN-ից բացառություն խնդրելը, դրեք երկու հասցեային պլանները կողք կողքի, որովհետև վերանորոգումները շատ տարբեր ժամանակ են արժենում։
Կարդացեք երթուղին նախքան կոնֆիգուրացիան փոխելը
Սկսեք այն ցանցից, որը Docker-ը իրականում կառուցել է։ IPAM բլոկը հասցեային պլանն է, իսկ ենթացանցը՝ այն տողը, որ կարևոր է.
docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]Compose-ը լռելյայն յուրաքանչյուր նոր նախագծի հատկացնում է /16, այնպես որ երկու ծառայություն կարող են տեղավորվել 65,536 հասցեի տիրույթում։ Հենց այդ լայնությունն է պատճառը, որ համընկնումները հաճախ են լինում. պատահական ընտրված /16-ը բավական մեծ է կլանելու այն կայքը, որին հասնում եք թունելով, և ոչ ոք չի նկատում դա, մինչև թունելը չբարձրանա։
Ապա համեմատեք երթուղու ընտրությունը մեկ կոնտեյների հասցեի համար՝ մեկ անգամ թունելը ցածր, մեկ անգամ՝ բարձր.
ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1Պատասխանի երկու ձև տանում են տարբեր տեղեր։ Եթե ելքը նշում է tun0, wg0 կամ մեկ այլ թունելային սարք, VPN նախածանցը առնվազն նույնքան կոնկրետ է, որքան կամրջի երթուղին, և փաթեթը երբեք չի հասնում կոնտեյնին: Եթե այն դեռ նշում է կամուրջը, հոսթը կարող է հասնել կոնտեյնին, և ձեր խնդիրը զտումն է, DNS-ը կամ վերադարձի ուղին, որը ձախողվում է միայն մեկ ուղղությամբ։
Ինչու է /16 բախումը հեշտ հարվածել
Docker-ը կամրջային ցանցերը վերցնում է մասնավոր լողավազաններից, իսկ լռելյայն լողավազանը գալիս է 172.16.0.0/12 բլոկից /16 կտրվածքներով։ Կորպորատիվ ցանցերը հաճախ օգտագործում են նույն մասնավոր տարածությունը, և հեռահար մուտքի VPN-ը մղում է այդ նախածանցերը յուրաքանչյուր միացող հաճախորդի։ Երբ երկու կողմերն էլ կարծում են, թե տիրապետում են 172.18.0.0/16-ին, մեկ երթուղավորման աղյուսակ պահում է երկու հակասական պնդում։
Հաղթողին որոշում է նախածանցի երկարությունը, ոչ թե երթուղիների հայտնվելու հերթականությունը։ Թունելը, որը մղում է 10.0.0.0/8 չի հաղթում կամրջի երթուղուն 172.18.0.0/16, քանի որ /8-ը ավելի քիչ կոնկրետ է։ Թունելը, որը մղում է 172.18.0.0/16, կամ 172.18.5.0/24 դրա ներսում, հաղթում է։ Այդ պատճառով մեկ նոթբուք աշխատում է գրասենյակի ցանցում և ձախողվում հյուրանոցի Wi-Fi-ում նույն VPN-ով. հաճախորդը ստանում է տարբեր նախածանցեր։
Նույն աղյուսակը ղեկավարում է նաև հակառակ ուղղությունը։ Կոնտեյները, որին պետք է ներքին հոսթ 10.8.4.20 հասցեում, փաթեթն ուղարկում է իր կամրջի դարպասին, և հոսթը այնուհետև երթուղավորում է թունել։ Այդ ուղին սովորաբար աշխատում է, որովհետև հոսթը կատարում է NAT-ը, բայց ձախողվում է, երբ կորպորատիվ կողմը ընդունում է միայն նոթբուքի VPN հասցեն, կամ երբ հակադարձ ուղու զտումը գցում է ասիմետրիկ պատասխանը։
Համեմատեք երեք վերանորոգումները
Ելքի միայն երեք ուղի կա, և դրանք տարբերվում են նրանով, թե ով պետք է հաստատի դրանք և ինչ է կոտրվում դրանցից մեկը կիրառելիս։
| Repair | Who owns it | What it costs |
|---|---|---|
| Renumber the container network | You | Recreates the network, restarts services, invalidates literal addresses in configs and scripts |
| Exclude your range from the tunnel | Network team | Changes what every laptop sees, needs a change request and a client profile update |
| Reach the service through a published port | You and the client | One port only, no direct container-to-container routing across the tunnel |
Վերահամարակալումը միակ վերանորոգումն է, որը կարող եք ավարտել առանց տոմսի, և դրա համար էլ գրառումների մեծ մասը կանգ է առնում այնտեղ։ Երիտասարդ նախագծում այն էժան է, իսկ թանկ է դառնում, հենց որ միգրացիայի գործիքը կամ պահված միացման տողը մատնացույց է անում բառացի հասցե։ Հաշվեք այդ հղումները նախքան YAML-ը խմբագրելը, ոչ թե հետո։
Թունելից բացառումը ամենամաքուր պատասխանն է, երբ համընկնումը գտնվում է տիրույթում, որն ձեր ընկերությունն իրականում տիրապետում է։ Այն նաև ամենադանդաղն է, և անօգուտ է կապալառուի համար, որը չի կարող փոխել հաճախորդի պրոֆիլը։ Հրապարակված պորտը կամ փոքր հակադարձ պրոքսին խուսափում են վեճից. հաճախորդը խոսում է այն հասցեի հետ, որը թունելն արդեն ճիշտ է երթուղավորում, և միայն այդ պորտը պետք է հասանելի լինի։
Ամրացրեք տիրույթը դիտմամբ
Մեկ նախագծի համար հայտարարեք ենթացանցը compose ֆայլում, որպեսզի նախագիծը դադարի քաշել ընդհանուր լողավազանից.
networks:
default:
ipam:
config:
- subnet: 10.201.7.0/24Վերցրեք այդ տիրույթը ձեր թիմի վարած գրանցամատյանից, ոչ թե որոնման ժամանակ գտած օրինակից։ Ստուգեք այն VPN-ի մղած նախածանցների, այն տնային LAN-ների, որտեղից մարդիկ աշխատում են, և նույն հոսթի այլ կոնտեյներային ցանցերի դեմ։ Ապա պլանավորեք վերաստեղծումը, որովհետև գոյություն ունեցող ցանցը պահում է իր հին ենթացանցը. docker compose down, ապա up -d. docker network rm հրաժարվում է, քանի դեռ վերջնակետերը կցված են, և ֆայլի ցանկացած ipv4_address գրառում պետք է ընկնի նոր տիրույթի մեջ։
Ցանցերի համար, որոնք Docker-ն ինքն է ստեղծում, սահմանեք դեմոնի լողավազան /etc/docker/daemon.json ֆայլում.
{
"default-address-pools": [
{ "base": "10.201.0.0/16", "size": 24 },
{ "base": "10.202.0.0/16", "size": 24 }
]
}Լողավազանը վերաբերում է դեմոնի վերագործարկումից հետո ստեղծված ցանցերին, իսկ արդեն գոյություն ունեցող կամուրջները պահում են իրենց հասցեները։ Դա հարմար է և հեշտ մոռանալի, ուստի հին նախագիծը դիտարկեք որպես դեռ համընկնող, մինչև ինչ-որ մեկը վերստեղծի նրա ցանցը։ Docker-ի շարժիչի ցանցային փաստաթղթերը նկարագրում են հատկացման կանոնները, եթե պետք է պաշտպանեք լողավազանը վերանայման ժամանակ։
Linux կամուրջը և Docker Desktop-ը ձախողվում են տարբեր կերպ
Linux հոսթում կոնտեյներները նստում են հոսթի անվանատարածքի կամուրջների վրա։ Մեկ աղյուսակ է որոշում ամեն ինչ, ուստի վերևի համեմատությունը ամբողջ պատմությունն է. կարդացեք կամրջի երթուղին, կարդացեք թունելի երթուղին և տեսեք, թե որն է հաղթում իրական կոնտեյների հասցեի համար։
Docker Desktop-ը կոնտեյներները դնում է սեփական NAT-ով VM-ի հետևում։ Հոսթը բոլորովին երթուղի չունի դեպի կոնտեյների հասցեն. այն ծառայությանը հասնում է հրապարակված պորտով, որը սովորաբար կապված է 127.0.0.1-ին։ Հետևաբար VPN հաճախորդը կարող է կոտրել ծառայությունը առանց ենթացանցերի համընկնման՝ կա՛մ VM-ի ներքին տիրույթի համար երթուղի տեղադրելով, կա՛մ արգելափակելով loopback երթևեկությունը, քանի դեռ թունելը միացված է։ Եթե հոսթի վրա ip route get հաղորդում է, որ կոնտեյների հասցեի համար երթուղի չկա, դա սպասելի է, և ոչ թե սխալը։
Գործնական հետևանքն այն է, թե որտեղ առաջինը նայեք։ Linux-ում սկսեք երթուղավորման աղյուսակից։ Desktop-ում սկսեք հրապարակված պորտից և VPN հաճախորդի firewall-ի կանոններից, ապա ստուգեք՝ արդյոք VM-ի ներքին ենթացանցը բախվում է թունելի մղած ինչ-որ բանի հետ։
Ստուգեք թունելը բարձր պահած
Նորից միացրեք VPN-ը երկու անգամ նախքան ուղղված է ասելը, որովհետև այն պրոֆիլը, որը միանալիս մղում է երթուղիներ և անջատվելիս հետ է քաշում դրանք, կարող է առաջին փորձից հետո ճիշտ թվալ։ Ապա գործարկեք այն ստուգումները, որոնք հաճախորդը իրականում գործարկում է.
ip route getհոսթից՝ օգտագործելով կոնտեյների իրական հասցեն։- Հարցում մեկ այլ կոնտեյնից՝ ապացուցելու, որ ծառայությունն ինքնին առողջ է։
curl -sv http://127.0.0.1:8080/հաճախորդից՝ թունելը բարձր, ապաtraceroute -nդեպի կոնտեյների հասցեն LAN-ի մեքենայից։sysctl net.ipv4.conf.all.rp_filterեթե հարցումը հասնում է հոսթին, բայց պատասխանը անհետանում է։
Վերջում գրեք ընտրված տիրույթը նույն գրանցամատյանում, որտեղից վերցրել եք այն, ամսաթվով և այն նախագծով, որին այն պատկանում է։ Հաջորդ համընկնումը կգա մի նախագծից, որը ոչ ոք չի փաստաթղթավորել, և միակ պաշտպանությունը այն է, որ տիրույթը դիտմամբ էր վերապահված, ոչ թե պատահականորեն վերցված։