VPN գործընկերը փինգ է ուղարկում այլ ինտերֆեյսներին, քանի որ դրանք տեղական են
Տեղական երթուղայնացման աղյուսակը փաթեթներն ուղարկում է ցանկացած հասցե, որը պատկանում է հյուրընկալողին, անկախ այն բանից, թե որ ինտերֆեյսի վրա է այն։
WireGuard հաճախորդը միանում է և փինգ ուղարկում բոլորովին այլ ինտերֆեյսի հասցեին, և պատասխանը գալիս է։ Գրառումները ցույց են տալիս, որ հարցումը միայն թունելի վրա է։ Ոչինչ կոտրված չէ, և ուշադիր անջատված փոխանցման կարգավորումը դրա հետ կապ չունի։ Սա երկու ուղիների համեմատություն է, որոնք դիագրամում նման են երևում, իսկ միջուկում բոլորովին տարբեր են։
Մեկ ուղին փաթեթները փոխանցում է ուրիշի փոխարեն, մյուսը դրանք հասցնում է հենց հյուրընկալողին։
Հյուրընկալողին ուղղված փաթեթը մնում է հյուրընկալողում
Հեռավոր հաճախորդը IP փաթեթ է ուղարկում հասցե, որը պատկանում է հյուրընկալողին։ Երթուղայնացումը մեկ հարց է տալիս այդ փաթեթի մասին՝ արդյոք այս նպատակակետը տեղական է։ Հյուրընկալողի յուրաքանչյուր հասցե երևում է տեղական երթուղայնացման աղյուսակում, և այդ աղյուսակը դիտարկվում է գլխավորից առաջ, ուստի փաթեթը գնում է հյուրընկալողի սեփական կույտը, փոխարենը այլ ինտերֆեյսով դուրս գալու։ Պատասխանը ստեղծվում է տեղականորեն, և այն վերադառնում է թունելով, որովհետև հարցումը այնտեղից էր եկել։
Սա է ամբողջ մեխանիզմը։ Փոխանցում տեղի չի ունենում, ինտերֆեյսի վիճակի փոփոխություն չի մասնակցում, և խնդրո առարկա հասցեն պարտադիր չէ, որ հասանելի լինի այլ տեղից։
Ինչու ip_forward-ը չի կիրառվում
Փոխանցումը կարգավորում է այն փաթեթները, որոնք պետք է դուրս գան այլ ինտերֆեյսով, քան այն, որով ժամանել են։ Հյուրընկալողին հենց իրեն ուղղված փինգը երբեք չի գնում այդ ուղով՝ փաթեթը սպառվում է տեղականորեն, և պատասխանը ստեղծվում է տեղականորեն։ Ուստի net.ipv4.ip_forward=0-ի սահմանումն այստեղ ոչինչ չի փոխում, և փոխանցման շղթայի կանոնը երբեք չի տեսնում այդ հոսքը։ Ճիշտ վերահսկողությունը գտնվում է մուտքային ուղու վրա՝ սահմանափակված մուտքային ինտերֆեյսով կամ աղբյուրով։
Այդ պատճառով փոխանցումն անջատելը և ենթադրելը, թե հյուրընկալողը մեկուսացված է, ստեղծում է անվտանգության կեղծ զգացում։
Կարդացեք որոշում կայացրած տեղական աղյուսակը
ip rule show-ը սովորաբար հաղորդում է զրո առաջնահերթության կանոնի մասին, որը բոլոր որոնումները նախ ուղարկում է տեղական աղյուսակ, իսկ ip route show table local-ը թվարկում է հյուրընկալողի սեփական հասցեները տեղական շրջանակով։ Այդ աղյուսակը ներառում է ինտերֆեյսների հասցեներ, որոնք վարչականորեն անջատված են, բայց դեռ կարգավորված։ Ստատիկորեն նշանակված IPv4 հասցեները սովորաբար գոյատևում են կապի ընդհատումից, և հենց այդպես է, որ անջատված կամրջին ուղարկված փինգը կարող է դեռ հաջողվել և զարմացնել օպերատորին։
IPv6-ը տարբերվում է հենց այս կետում։ Նրա հասցեները սովորաբար հետ են վերցվում, երբ կապը կտրվում է, եթե keep_addr_on_down սահմանված չէ։ Համեմատեք ընտանիքները՝ փոխարենը ենթադրելու, որ մեկ կանոնը ծածկում է երկուսին։
Ինչի է իրականում հասնում գործընկերը
Սեգմենտի վրա երթուղիչի սեփական հասցեից ստացված պատասխանը ոչինչ չի ասում այդ սեգմենտի հետևում գտնվող մեքենաների մասին։ Գործընկերը չի կարող այս ուղով հասնել մյուս ինտերֆեյսի հետևում գտնվող հյուրընկալողին, նա հասնում է միայն այն հասցեներին, որոնք պատկանում են հենց երթուղիչին։ Առանձին LAN հյուրընկալողի վրա ծառայության փորձարկումը, երթուղիչի հասցեին փինգ անելու փոխարեն, հենց այն է, ինչը պարզում է՝ արդյոք փոխանցումն ընդհանրապես թույլատրված է։
Գործընկերոջը թունելի հասցեին կապված ծառայություններով սահմանափակելը մուտքային քաղաքականության հարց է։ Թույլատրեք ցանկալի ծառայությունը թունելի ինտերֆեյսի վրա և սահմանափակեք այն աղբյուրները, որոնք կարող են օգտագործել այն, որովհետև փաթեթն իսկապես հասնում է այնտեղ։
Ստուգեք նաև այն հասցեները, որոնք մտադիր էիք շարքից հանել։ Ինտերֆեյսից հասցե հեռացնելը ավելի հուսալի է, քան հնացած հասցեի վրա firewall-ի կանոններ դասավորելը։