Dev Container-ը չի հասնում միայն VPN-ով հասանելի հոսթին՝ որտեղ նայել

Մասնավոր API-ն բացվում է ձեր աշխատասեղանի բրաուզերում և ձախողվում է զարգացման կոնտեյներում։ Սա հակասություն չէ, և հազվադեպ է, որ պատճառը հենց VPN-ն է։ Բրաուզերի հարցումը և ձախողվող հարցումը կատարել են տարբեր գործընթացներ՝ տարբեր resolver-ներով, proxy-ներով և երթուղիներով, և հաճախ՝ բոլորովին տարբեր ցանցային անվանատարածքներից։ «Իմ նոթբուքում» կարող է նշանակել Windows հոսթ, WSL տարածում, Docker Desktop վիրտուալ մեքենա և կոնտեյներ այդ VM-ի ներսում՝ չորս համատեքստ, որոնցից յուրաքանչյուրը կարող է նույն հոսթանվանը տարբեր պատասխան տալ։ Պարզեք, թե որն է օգտագործում ձախողվող գործընթացը, նախքան որևէ կարգավորման դիպչելը։

Գտեք գործընթացը, նախքան կարգավորումը փոխելը

Սկսեք կոնտեյներային շարժիչից, ոչ VPN հաճախորդից։ Հարցրեք, թե որ համատեքստի հետ է խոսում հրամանի տողը և որ օպերացիոն համակարգի վրա է աշխատում այդ շարժիչը, որովհետև աշխատասեղանի VM-ի կողմից կառավարվող Linux կոնտեյները այլ ուղի է անցնում, քան տեղական daemon-ի կողմից կառավարվողը՝

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Windows-ում wsl -l -v ասում է՝ տարածումն աշխատում է WSL 2-ի ներքո, թե ոչ, ինչը այն դնում է իր սեփական վիրտուալ անջատիչի հետևում։ Այդ մանրամասնությունը որոշում է՝ կոնտեյները կիսում է հոսթի երթուղային աղյուսակը, թե նստած է NAT-ի հետևում, որը հոսթին հասնելու համար պահանջում է փոխանցված պորտ կամ հոսթանուն։

Մեկ հարցում պահեք հաստատուն և համեմատեք

Ընտրեք մեկ անվնաս վերջնակետ մասնավոր հոսթի վրա և օգտագործեք այն ամեն համեմատության համար՝ բրաուզերից, հոսթի տերմինալից, WSL տարածումից և կոնտեյների ներսից։ Յուրաքանչյուր փորձի համար գրանցեք չորս բան՝ լուծված հասցեն, արդյոք proxy օգտագործվել է, ձախողման դասը և անցած ժամանակը։ Անվան որոնումը, կապի հաստատումը, TLS վավերացումը և HTTP կարգավիճակը չորս տարբեր խնդիրներ են, և դրանք «չի աշխատում»-ի մեջ խառնելը մի ամբողջ առավոտ է վատնում։

Համեմատությունն անցկացրեք ձախողվող կոնտեյների ներսում՝ ժամկետով, որպեսզի լուռ firewall-ը րոպեներով չպահի տերմինալը։ Նոր կոնտեյները վերարտադրում է շարժիչի ցանցային համատեքստը, բայց ոչ հավելվածի կոնտեյների անվանատարածքը, proxy փոփոխականները կամ resolver-ը, ուստի docker exec իրական կոնտեյների մեջ հեղինակավոր փորձարկումն է, իսկ կողային կոնտեյները միայն միջոց է առանձնացնելու՝ տարբերությունը շարժիչի՞ մեջ է, թե՞ կոնտեյների՝

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

alpine բազային պատկերը պարունակում է busybox և չունի curl, և հենց այսպիսի մանրամասն է, որ կրկնօրինակված ախտորոշիչ բլոկը ձախողում է՝ ընտրեք հաճախորդով պատկեր կամ ավելացրեք այն նույն գործարկման մեջ։ Անկապ հանրային կայքերի հետ համեմատությունը ոչինչ չի մեկուսացնում։ Եթե https://example.com աշխատում է կոնտեյներից, դուք իմացաք, որ կոնտեյներն ունի ինտերնետ հասանելիություն, և ոչինչ այն մասին, թե արդյոք այն թունելով հասնում է մասնավոր հասցեի։ Նույն կերպ, նոր տերմինալ բացելը միայն ապացուցում է, որ նոր տերմինալն աշխատում է, ոչ թե որ այն կիսում է գործարկման միջավայրը ձախողված հավելվածի հետ։

Docker Desktop-ը կարող է աշխատել VPN-ով

Docker-ի սեփական փաստաթղթերը VPN-ի և հոսթի միացման մասին դա նկարագրում են որպես աջակցվող կարգավորում, և ազնիվ ամփոփումն այն է, որ այն աշխատում է, այլ ոչ թե ինքնաբերաբար կոտրված է։ Մի ենթադրեք, որ աշխատասեղանի VM-ը դիզայնով շրջանցում է հոսթի թունելը. շատ կարգավորումներում երթևեկությունը ճիշտ հետևում է հոսթի թունելին, և դրա համար է, որ «Docker-ը անտեսում է VPN-ը» առասպելը վստահ և սխալ խորհուրդներ է տալիս։

Ինչ դեռևս կարևոր է՝ օգտագործվող backend-ը, հաճախորդի split-tunnel քաղաքականությունը և VM-ի ստացած resolver կարգավորումը։ VPN հաճախորդը, որը տեղադրում է երթուղիներ, բայց ոչ DNS, կամ մղում է DNS սերվեր, որին VM-ը չի հասնում, անվան որոնման ձախողում է առաջացնում կոնտեյների ներսում, մինչ հոսթն աշխատում է, որովհետև ունի լրացուցիչ resolver կամ քեշավորված պատասխան։ Սա resolver-ի խնդիր է՝ կոնտեյների զգեստով։ Այն գոյատևում է VPN-ի ձեր փորձած յուրաքանչյուր վերամիացումից, քանի որ թունելն արդեն տանում է այն երթևեկությունը, ինչ խնդրել եք տանել։

Հասցեների համընկնումը և MTU-ն տարբեր ձախողումներ են

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

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

Երկրորդը MTU-ի խնդիրն է։ Եթե կապը հաստատվում է և TLS-ը ավարտվում, բայց ավելի մեծ պատասխանները կանգ են առնում, դուք ունեք փաթեթի չափի խնդիր, ոչ թե լիազորման, և DNS գրառումների փոխարինումը երբեք չի լուծի այն։ Փորձարկեք փոքր և մեծ հարցումով, նախքան ինչ-որ բան փոխելը, և գրանցեք երկու արդյունքները։

Համընկնման լուծումը այլ կոնտեյներային ենթացանց է կամ սահմանափակ երթուղի՝ ընտրված հասցեային պլանի տիրոջ կողմից։ MTU-ի կանգի լուծումը թունելի կամ ինտերֆեյսի MTU-ն այնպիսի արժեքի սեղմելն է կամ իջեցնելը, որը դիմանում է ուղուն, կիրառված այն շերտում, որը դուք վերահսկում եք։

Proxy կարգավորումը յուրաքանչյուր գործընթացի համար է, ոչ մեքենայի

Կոնտեյների ներսում localhost անվանում է այդ կոնտեյների սեփական ցանցային համատեքստը, ուստի հոսթի վրա աշխատող proxy-ն այնտեղ հասանելի չէ այդ անվան տակ։ Docker Desktop-ը հոսթի հասանելիության համար տրամադրում է host.docker.internal, իսկ Linux-ում դուք այն բացահայտ ավելացնում եք --add-host=host.docker.internal:host-gateway-ով։ Ամեն դեպքում, այդ անունը ձեզ երթուղի է տալիս դեպի հոսթ. այն proxy ծառայություն չի ստեղծում և չի լիազորում օգտագործել մեկը։

Օգտագործեք իրական միջավայրի համար տրված proxy հասցեն և պորտը, և ստուգեք, թե ով է կարդում դրանք։ Ինտերակտիվ shell-ում արտահանված փոփոխականները ինքնաբերաբար չեն կարգավորում խմբագրի ամեն ընդլայնում, լեզվի սերվեր, build գործիք և ֆոնային daemon։ Կարևորը այն գործընթացն է, որը կատարել է ձախողված հարցումը, ուստի ստուգեք նրա միջավայրը, ոչ թե ձեր տերմինալինը։

Վերջում թողեք, որ ուղղումն ինքն իրեն բացատրի։ Օգտակար լուծումը նշում է այն սահմանը, որը սխալ էր, այն կարգավորումը, որը փոխեց այն, և գործընթացների այն բազմությունը, որի վրա այն այժմ ազդում է։ VPN-ի, խմբագրի և շարժիչի հաջորդական վերագործարկումը կարող է փոխել ախտանիշը, բայց ոչինչ չի թողնում, ինչ հաջորդ մարդը կարող է օգտագործել։