Մուտք գործել վեբ ինտերֆեյս VPN կոնտեյների ներսում. ընտրեք պորտի տիրոջը

Հավելվածի հետ ոչինչ այնպես չէ, և թունելի հետ ոչինչ այնպես չէ, բայց վահանակը դեռ չի բեռնվում։ Երբ ծառայությունը աշխատում է network_mode: service:vpn-ով, այն կիսում է VPN կոնտեյների ցանցային անվանատարածքը, ինչը նշանակում է, որ նրա լսողը և հրապարակված պորտերը պատկանում են այդ անվանատարածքին, ոչ թե ծառայությանը։ Դրանից բխում է երեք որոշում՝ որտեղ է կապվում հավելվածը, որ կոնտեյներն է հրապարակում պորտը, և որքան նեղ է կառավարման ուղին։ Տեղադրեք դրանք սխալ հերթականությամբ, և յուրաքանչյուր առանձին կարգավորում ճիշտ կթվա, մինչդեռ համակցությունը չի կարող աշխատել։

Ով է տիրում պորտի անվանատարածքին

Կիսված անվանատարածքում կախյալ ծառայությանը ports: գրառում ավելացնելը ոչ մի օգտակար բան չի անում, և մի քանի ցանցային տարբերակներ նախագծով չեն աջակցվում դրա համար։ Փոխարենը հրապարակեք այն կոնտեյների վրա, որը տիրում է անվանատարածքին։ Այդ կոնտեյներն է նաև այն, ում հասցեն երևում է հոսթի վրա, ուստի քարտեզագրումը կարդացվում է որպես մեկ գրառում, ոչ թե մեկը յուրաքանչյուր ծառայության համար։

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

Ուշադրություն դարձրեք քարտեզագրման ձախ կողմի հասցեին։ 127.0.0.1-ին կապելը հրապարակված պորտը պահում է հոսթի loopback-ի վրա, ինչը սովորաբար այն է, ինչ ուզում է կառավարման ինտերֆեյսը։ 0.0.0.0-ին կապելը բացում է այն հոսթի բոլոր ինտերֆեյսներում, և դա այլ անվտանգության որոշում է, ոչ թե հարմարավետություն։

Թույլ տվեք հավելվածին լսել այնտեղ, որտեղ անվանատարածքը սպասում է

Անվանատարածքի ներսում 127.0.0.1-ին կապված լսողը հասանելի է միայն այդ անվանատարածքի ներսից։ Հրապարակված հոսթի պորտերը գալիս են դրսից, ուստի հավելվածը պետք է կապի ավելի լայն հասցե, որպեսզի քարտեզագրումն աշխատի։ Սա մեկ տողի փոփոխություն է շատ սերվերներում, և հենց այդ քայլն են բաց թողնում մարդիկ առանց կոնտեյների տեղակայման համար գրված կարծրացման ուղեցույցը պատճենելուց հետո։

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

Հավելվածի ներսում լսողների ցանկը ճշմարտությունն է ասում կապման հասցեի մասին, և docker port ասում է, թե տերն ինչ է իրականում հրապարակել։ Եթե առաջինը ցույց է տալիս 127.0.0.1, իսկ երկրորդը՝ հոսթի քարտեզագրում, դուք գտել եք անհամապատասխանությունը՝ առանց VPN-ի կարգավորումներին դիպչելու։

Ընտրեք, թե ինչպես է ներս մտնում կառավարման ուղին

Կան երեք խելամիտ դասավորություններ։ Հրապարակեք VPN կոնտեյների վրա և հասեք դրան հոսթից կամ տեղային ցանցից։ Անվանատարածքի առջև դրեք հակադարձ պրոքսի և պրոքսիին տվեք միակ բաց պորտը։ Կամ վահանակը հասանելի պահեք միայն անվանատարածքի ներսից՝ exec նստաշրջանի կամ SSH թունելի միջոցով, ինչը նվազագույն բացահայտումն է և նվազագույն հարմարավետությունը։

Որն է հարմար, կախված է նրանից, թե ում և որտեղից է պետք ինտերֆեյսը։ Նույն հոսթի վրա մեկ ադմինիստրատորին բավարար է loopback-ին կապելը։ VPN-ով հասնող թիմին պետք է մտածված ուղի և անունով տեր։ Պրոքսի տարբերակն ընտրելը ձեզ տալիս է TLS և մուտքի մատյաններ, դիմացը՝ ևս մեկ բաղադրիչ, որը պետք է թարմ պահել։

Բացեք կառավարման պորտը՝ չբացելով ամեն ինչ

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

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

Ստուգեք կառավարման սարքից, ապա ստուգեք նորից ավելի ուշ

Փորձարկեք այն մեքենայից, որը իրականում կկառավարի ծառայությունը, ոչ թե հոսթից, ապա առանձին ստուգեք հավելվածին անհրաժեշտ ինտերնետ ուղին։ Կառավարման հաջողությունը ապացուցում է մեկ ուղղություն և ոչինչ չի ասում ելքի մասին։

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