Երթուղիչը ինտերնետին հասնում է իր թունելով, մինչդեռ նրա հետևում գտնվող նոթբուքը դեռևս հայտնում է ISP-ի հասցեն։ Ընդունման կանոններ ավելացնելը չի օգնում, և այդ ձախողումը խրատական է՝ զտումը պատասխանում է՝ թույլատրվո՞ւմ է փաթեթին անցնել, ոչ թե ուր է այն գնում։ Ինտերֆեյսի ընտրությունն արդեն կատարել է երթուղային որոնում, որը ոչինչ չգիտի ձեր հաճախորդների ցանկի մասին։ Ուղղեք որոնումը, և հրե պատը այլևս կասկածելի չէ։

Զտիչի կանոնը չի կարող ինտերֆեյս ընտրել

Linux երթուղիչում փաթեթների հոսքը նախ կատարում է երթուղային որոշումը, ապա՝ forward կեռիկը։ Երբ կանոնը համընկնում է ելքային թունելային սարքի հետ, միջուկն արդեն որոշել է, որ թունելը ելքի ճանապարհն է։ Եթե հիմնական աղյուսակը դեռ նախընտրում է WAN-ի լռելյայն երթուղին, փաթեթը գնում է դեպի ISP, և ձեր նոր գրած ընդունման կանոնը երբեք չի տեսնում այն։ Հերթականության այս մեկ փաստը բացատրում է, թե ինչու նոր հրե պատի կանոնների մի ամբողջ էջ ոչինչ չի փոխում։

Ստորև բերված օրինակը օգտագործում է 192.168.8.0/24 LAN br-lan-ի վրա, tun0 թունելային սարք և մեկ set-top box 192.168.8.23 հասցեով, որը պետք է անցնի թունելով։

Կարդացեք որոնումը՝ նախքան կանոնները խմբագրելը

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

ip -4 route get 198.51.100.7 from 192.168.8.23

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

Կապակցեք աղյուսակը ձեր ուզած հաճախորդներին

Քաղաքականության երթուղավորումը կանոնների որոնում է մտցնում հիմնական աղյուսակից առաջ։ Կառուցեք աղյուսակ, որի լռելյայն երթուղին թունելն է, ապա կապակցեք այդ աղյուսակը ընտրիչին՝ մուտքային ինտերֆեյս, աղբյուրի հասցե կամ հրե պատի նշան։ Առաջնահերթությունները որոշում են հերթականությունը, և հիմնական աղյուսակը ցանկում շատ ներքևում է՝ 32766-ում, ուստի ցածր համարով կանոնը դիտարկվում է առաջինը։ Ինտերֆեյսի ընտրիչները ծածկում են կամուրջի բոլոր հաճախորդներին, հասցեի ընտրիչները՝ մեկ մեքենա։

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

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

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

Պահեք տեղական նպատակակետերը թունելից դուրս

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

ip -4 route add throw 192.168.8.0/24 table 200

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

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

Առնչվող հոդվածներ