Գեյթվեյը հյուրընկալում է իր սեփական ադմին էջը՝ ներքին թե հանրային հասցե

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

Էջը բեռնվում է դրսից, ոչ թունելով

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

Նպատակակետի երթուղին ընտրում է հասցե, ոչ պորտ։ Երթուղային աղյուսակում ոչինչ չգիտի, որ 443 պորտը ադմինիստրացիայի համար է, իսկ 1194 պորտը՝ տրանսպորտը, ուստի երկուսն էլ դիտարկվում են որպես նույն նպատակակետ։

Այդ պատճառով էջը երբեմն աշխատում է, երբեմն՝ ոչ, կախված նրանից, թե որ անունն ու որ ցանցն է օգտագործել հաճախորդը։ Սա ուղու խնդիր է, ոչ թե նույնականացման խնդիր։ Երկու հաճախորդներն էլ լիովին լավ նույնականացվում են։

Պահեք արտաքին վերջնակետը հասանելի

Լրիվ թունելի պրոֆիլներին անհրաժեշտ է բացառության երթուղի VPN վերջնակետի համար, և OpenVPN-ի redirect-gateway ընտրանքը փաստագրում է հենց դա՝ հեռավոր վերջնակետը պահպանում է երթուղի նախապես գոյություն ունեցող գեյթվեյով, որպեսզի թունելն իր մեջ չերթուղավորի։ Հեռացրեք այդ բացառությունը, և գաղտնագրված տրանսպորտը կհետևի թունելին, ինչը ավարտում է նստաշրջանը օղակում։ Այդ բացառությունն է պատճառը, որ վերջնակետի հասցեն մնում է հասանելի թունելի ներսից։

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

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

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Եթե որոնումը ցույց է տալիս վերջնակետի երթուղին ֆիզիկական գեյթվեյով, վարքը ճիշտ է, և ադմին էջը պարզապես ուղարկվում է սխալ ուղով։ Հենց այդտեղ է անունների լուծումը դառնում ուղղում։

Տվեք ծառայությանը մասնավոր անուն

Ծառայությանը պետք է անուն, որը թունելի ներսում լուծվում է գեյթվեյի հասցեի, միաժամանակ պահպանելով վկայագրի և հոսթի անվան իմաստը, որը սպասում է հավելվածը։ Ադմինիստրացիոն անվան համար մասնավոր գոտու գրառումը սովորական պատասխանն է, և այն անփոփոխ է թողնում տրանսպորտի անունը։

Չվերաուղղեք տրանսպորտի անունը դեպի ներքին հասցե, քանի որ հաջորդ թունելի կառուցումը կփորձի հասնել հասցեի, որը գոյություն ունի միայն թունելի ներսում։ Այդ սխալը ստեղծում է VPN, որն աշխատում է ուղիղ մեկ անգամ։

Ստուգեք նաև հասցեների երկու ընտանիքները, քանի որ հետ մնացած AAAA գրառումը կարող է դիտարկիչն ուղարկել այնտեղ, որտեղ մասնավոր պլանը երբեք չի հասել։

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Համաձայնեցրեք քաղաքականությունը այն տեղի հետ, որտեղ գործընթացն է աշխատում

Գեյթվեյում լսող բնիկ գործընթացին հասնում են տեղական մուտքի ուղով, ուստի մուտքի շղթան և սոքետի կապումը որոշում են՝ հարցումը կընդունվի։ Փոխանցման կանոնները և IP փոխանցումը տեղական լսողին չեն ստիպում պատասխանել։ Թույլատրեք թունելի աղբյուրները մուտքի քաղաքականության մեջ և հաստատեք, որ գործընթացը կապված է հասցեի, որին թունելը կարող է հասնել։

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

Մեկնարկի հերթականությունը կարևոր է երկու դեպքում էլ, քանի որ այնպիսի հասցեի կապումը, որը հայտնվում է միայն թունելի բարձրանալուց հետո, բացման պահին լուռ ձախողվում է։

Ստուգեք մասնավոր հասանելիությունը և մերժված հանրային ուղին

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

Կարդացեք կապումները և ֆիլտրի վիճակը, ոչ թե այն հոսթի անունը, որը տրվել է օգտատերերին։ Բացահայտվածությունը սոքետի հատկություն է, ոչ անվան։ Այդ տարբերությունը վերապրում է ամեն DNS փոփոխություն։

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

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