Ինչու ձեր հանրային Linux ծառայությունը պատասխանում է VPN-ի միջով

Ոչինչ socket-ում չի հիշում, թե որ ինտերֆեյսն է տեղափոխել հարցումը, ուստի լրիվ թունելով VPN-ի լռելյայն երթուղին կարող է որսալ պատասխան, որը պատկանում է WAN-ին։ Ծառայությունը չի անտեսում մուտքային ինտերֆեյսը. Linux-ը տեղական ստեղծված պատասխանը երթուղավորում է ըստ նպատակակետի և աղբյուրի քաղաքականության։ Աղբյուրի վրա հիմնված կանոնը կարող է փոխարենը միայն ծառայության պատասխաններն ուղարկել ամբողջական WAN աղյուսակով՝ սովորական ելքը թողնելով թունելում։ Պորտը մնում է բաց, մինչ պատասխանը դուրս է գալիս սխալ ուղուց, և դա է պատճառը, որ ախտանիշը միակողմանի է թվում։

Սխալ պատկերացում. պատասխանները հետևում են այն ինտերֆեյսին, որով եկել են

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

Հենց ծառայությունն ընդունում է կապը, նրա պատասխանը նոր՝ տեղական ստեղծված փաթեթ է։ Միջուկը դիտարկում է երթուղային կանոնները պատասխանի նպատակակետի և աղբյուրի համար, և VPN-ի լռելյայն երթուղին լիովին վավեր պատասխան է։ Ոչինչ socket-ում չի հիշում, թե որ ինտերֆեյսն է տեղափոխել հարցումը։

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

Ինչ է միջուկը իրականում երթուղավորում. աղբյուրի հասցեն

Անհրաժեշտ բռնակը տեղական հասցեն է, որն օգտագործում է ծառայությունը պատասխանների համար։ Հոսթի վրա, որի օրինակելի eth0 հասցեն 192.0.2.10/24 է և դարպասը՝ 192.0.2.1, այդ հասցեն առկա է ինտերֆեյսի վրա։ Ամպային VM-ում հանրային հասցեն կարող է վերևում թարգմանված լինել և բացակայել հյուրից, ուստի օգտագործեք այն հասցեն, որն իսկապես ունի հոսթը։

Ստուգեք ընթացիկ վիճակը նախքան աղյուսակի համար կամ կանոնի առաջնահերթություն վերապահելը։ Գործող քաղաքականության կանոնները կարող են ստվերել նորը, և նույն համարով հին աղյուսակը կարող է արդեն կրել անկապ երթուղիներ:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

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

Կառուցեք ամբողջական վերադարձի աղյուսակ, ոչ թե կես լռելյայն

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Օգտագործեք իրական նախածանցն ու դարպասը, այլ ոչ թե պատճենեք օրինակը։ Ուղիղ կապի դարպասով /32-ի պես կարգավորված ամպային ինտերֆեյսը պահանջում է այլ միացված երթուղի, և սխալ նախածանցից կառուցված աղյուսակը ձախողվում է առաջին ցատկում։ src հատկանիշը նշում է այդ երթուղու նախընտրելի աղբյուրը. այն չի փոխարինում աղբյուրի կանոնին։

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

Ստուգեք աղբյուրով որակավորված որոնմամբ

Խնդրեք միջուկին երթուղավորել փորձնական նպատակակետ ծառայության հասցեից։ Պատասխանը պետք է նշի eth0-ը և WAN դարպասը, ոչ թե թունելը:

ip -4 route get 198.51.100.25 from 192.0.2.10

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

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

Որտեղ է ավարտվում այս բացառությունը

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

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

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

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