Ինչու Access Server-ի հաճախորդները հասանելի չեն LAN-ից

Նոթբուքը միանում է, թունելը բարձրացած է, և դեպի ներքին ծառայություն ուղարկված հարցումները կախվում են միացման պահին։ Ծառայության մոտ հարցումը գալիս է 10.90.0.25-ի նման հասցեից, պատասխանը դուրս է գալիս դեպի լռելյայն դարպասը, և ոչինչ չի վերադառնում, որովհետև այդ դարպասը գաղափար չունի, թե որտեղ է գտնվում 10.90.0.25-ը։ Մյուս կողմից նույն խափանումը երևում է որպես ներքին հոսթ, որը չի կարող ping անել միացած հաճախորդին։ Երկուսն էլ մեկ բացակայող օբյեկտ են՝ վերադարձի ուղի դեպի VPN հաճախորդների փուլ, որը կարող է ավելացնել միայն մասնավոր ցանցը։

Կարդացեք աղբյուրի հասցեն, որը տեսնում է ծառայությունը

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

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

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

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

Ավելացրեք ուղին այնտեղ, որտեղ որոշվում է պատասխանը

Ուղին պատկանում է այն դարպասին, որն արդեն օգտագործում է ներքին ծառայությունը, ոչ թե ծառայությանը, եթե իհարկե այն ինքը չի երթուղավորում իր տրաֆիկը։ Ուղղեք այն Access Server-ի հասանելի մասնավոր հասցեին, որը տարբերվում է հաճախորդի պահած թունելի հասցեից։

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

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

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

Փոխանցումը և զտիչները պետք է համաձայնեն ուղու հետ

Երթուղավորումը ճանապարհի միայն կեսն է։ Սերվերին պետք է թույլատրվի փոխանցել թունելի և մասնավոր ինտերֆեյսի միջև, ինչը Linux-ում նշանակում է net.ipv4.ip_forward գումարած փոխանցման շղթա, որը թույլատրում է ինտերֆեյսների զույգը, իսկ կարծրացված հոսթում սովորաբար բացահայտ կանոն յուրաքանչյուր ուղղության համար։

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

Վիճակով զտումը բացատրում է ախտանիշ, որը մարդկանց սխալ ճանապարհ է տանում։ Հաստատված հոսքի ներսում պատասխանը նոր մուտքային կանոնի կարիք չունի, ուստի SYN-ACK-ից հետո կախված կապը չի արգելափակվում բացակայող accept կանոնով, այլ դեն է նետվում կամ սխալ երթուղավորվում։ Պահեք այդ տարբերությունը, որովհետև այն առանձնացնում է երթուղավորման փոփոխությունը firewall-ի փոփոխությունից։

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

Երթուղավորված թե քողարկված՝ ընտրեք գիտակցաբար

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

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

Հաճախորդի հետևի ենթացանցը առանձին խնդիր է

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

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

Ստուգեք մեկ հոսքով և մեկ գրավմամբ

Ապացուցեք ուղին մեկ կապով, այլ ոչ թե հասանելիության ընդհանուր փորձարկումով։ Դիտեք նույն հոսքը երկու ծայրերում՝ ծառայություն հասնող հարցումը և այն թողնող պատասխանը։

tcpdump -ni any host 10.90.0.25 and port 443

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

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