PPP peer հասցեն կամ VPN վերջնակետը. ինչն է գրվում via-ում

PPP միջերեսի մեկ տողը լուծում է VPN տուփի երթուղավորման վեճի մեծ մասը. ներքին հասցեն և դրա կողքին տպված peer-ը։ Կարդացեք այդ զույգը որպես փոքրիկ ենթացանց և դուք կփնտրեք դարպաս, որը գոյություն չունի։ Կարդացեք այն որպես մեկ կապի երկու ծայր և հաջորդ ցատկը դառնում է ակնհայտ։ Այստեղի համեմատությունը այս երկու ընթերցումների միջև է, որովհետև հետո կառուցված ամեն աղյուսակ ժառանգում է ընտրածը։ Արտաքին VPN վերջնակետի մասին նրանցից ոչ մեկը ոչինչ չի որոշում։

Մեկ միջերեսի տողի երկու ընթերցում

Վերցրեք մի սեսիա, որտեղ միջերեսը հաղորդում է inet 10.64.3.9 peer 10.64.3.1/32։ Ենթացանցային ընթերցումը 10.64.3.9-ը դիտարկում է որպես միայնակ հանգույց /32 կղզում և հետո փնտրում է երթուղիչ՝ դրանից այն կողմ ինչ-որ բանի հասնելու համար։ Քանի որ կապի միակ մյուս հասցեն peer-ն է, այդ ընթերցումը վերջում առաջարկում է հենց 10.64.3.9-ը որպես դարպաս, ինչը շրջանաձև է։

Վերջնակետային ընթերցումը փաստաթղթավորվածն է։ Կետ-կետ միջերեսում peer անվանում է այդ մեկ կապի հեռավոր ծայրը, ուստի 10.64.3.1-ը օգտագործելի հաջորդ ցատկն է, իսկ 10.64.3.9-ը միշտ միայն աղբյուրի հասցե է։

Այդ տարբերությունը որոշում է, թե ինչ կարող է լինել via-ում։ Այնտեղ տեղական հասցեն գրելը ստեղծում է երթուղի, որը միջուկը չի կարող կապել հարևանի հետ, ուստի գրառումը կա՛մ ձախողում է ստուգումը, կա՛մ կլանում է տրաֆիկը՝ ցանկում լրիվ առողջ երևալով։ Peer-ը աշխատում է, որովհետև այն կապի իրական նպատակակետն է։ Երկու ընթերցումներն էլ համաձայն են արտաքին VPN վերջնակետի հարցում, որը լրիվ առանձին ինքնություն է. դրան հասնում են underlay-ի միջով, ոչ թե այն ավարտող թունելի միջով։

Ինչ արդեն տեղադրել է սեսիան

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

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9-ի նման սարքի երթուղին դարպաս չի կրում, որովհետև միջերեսն ինքն է ճանապարհը։ Երթուղին, որը peer-ին անվանում է via-ով, այլ օբյեկտ է՝ այլ կյանքի տևողությամբ, և այն անհետանում է, երբ սեսիան ընկնում է։ Երկու ձևերից մեկը մշտական աղյուսակում պատճենելը՝ առանց ստուգելու, թե ինչպես է այն նորից տեղադրվում, սովորական պատճառն է, թե ինչու աշխատող թունելը վերամիացումից հետո կորցնում է իր երթուղին։

Համեմատեք երկու ցանկերը՝ հիշողությանը վստահելու փոխարեն։ Եթե peer-ի երթուղին գոյություն ունի main-ում, բայց ձեր լրացուցիչ աղյուսակը դատարկ է, դուք սովորել եք մի բան, ինչ հասցեի տողը երբեք չի ասել։

Կանոնը և աղյուսակը առանձին որոշումներ են

Աղյուսակ ընտրելը և այն լրացնելը անկախ քայլեր են, և համեմատությունն այստեղ կարևոր է, որովհետև վրիպազերծման ժամանակ այդ երկուսը հաճախ շփոթում են։ Կանոնը, որը նշված տրաֆիկը ուղարկում է 100 աղյուսակ, ոչինչ չի անում, եթե 100 աղյուսակում համապատասխան երթուղի չկա, և լավ լցված աղյուսակը անհասանելի է, եթե դրան ոչ մի կանոն չի ցույց տալիս։

Լռելյայն երթուղու կեսը լռելյայն երթուղի չէ։ Մեկ 0.0.0.0/1 ընդգրկում է IPv4 տարածության ստորին կեսը, ուստի ամեն ինչ բռնելու մտադրություն ունեցող քաղաքականությանը պետք է նաև համապատասխան 128.0.0.0/1 կամ իսկական default։ Աշխատող կոնֆիգուրացիա կարդալը և երկու կեսերից մեկը պատճենելը այն ձևն է, թե ինչպես մարդիկ հայտնվում են երթուղավորման օղակի մեջ, որը կոտրվում է միայն որոշ նպատակակետերում։

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

Տվեք որոնմանը այն հարցը, որ տալիս է ձեր հավելվածը

ip route get լուծում է ուղին. ip route show թվարկում է պահված գրառումները, և երկուսը կարող են չհամաձայնել՝ առանց որևէ մեկի սխալ լինելու։ Ներառեք աղբյուրի կոնտեքստը, որովհետև աղբյուրի վրա հիմնված կանոնները համընկնում են միայն այն դեպքում, երբ որոնումը աղբյուր է կրում։

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

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

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

Որտեղ համեմատությունը շրջվում է

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

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

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