Ինչու VPN հաճախորդի հետևում գտնվող սերվերը պատասխանում է թունելով

Մուտքային կապերը դեպի հոսթ, որը նաև գործարկում է VPN հաճախորդ, ձախողվում են շատ յուրահատուկ ձևով՝ ձեռքսեղմումը հասնում է, դեմոնը պատասխանում է, և հաճախորդը ոչինչ չի ստանում վերադարձ: Ոչինչ չի արգելափակում պորտը: Պատասխանը դուրս եկավ թունելով, որովհետև թունելը տիրապետում է լռելյայն երթուղուն, և միջուկը պատասխանները երթուղավորում է ըստ նպատակակետի, ոչ թե ըստ հիշողության, թե որտեղից է եկել հարցումը: Դեմոնը կարգին է, և պորտը բաց է:

Պատասխանը երթուղավորվում է, ոչ թե հիշվում

Լռելյայն երթուղի տեղադրող VPN հաճախորդը ավելացնում է գրառում, որը գերազանցում է LAN դարպասին՝ կա՛մ մետրիկայով, կա՛մ տարածությունը երկու ավելի կոնկրետ կեսերի բաժանելով: Ելքային փաթեթներն այժմ ընտրում են թունելի ինտերֆեյսը: Միջուկը երբեք չի հարցնում, թե որտեղից է ի սկզբանե ժամանել այն փաթեթը, որին պատասխանում են: Այդ մեկ բացթողումը բացատրում է հետևյալ բոլոր ախտանիշները:

Առաջ ուղղությունը երթուղավորվում է ըստ նպատակակետի, և հակառակ ուղղությունը նույնպես: Պատասխանը հասցեագրված է հանրային հաճախորդի, որին թունելը սիրով կտեղափոխի: Հեռավոր ծայրը ստանում է փաթեթ, որի աղբյուրը իրենը չէ, դեն է նետում այն, և սկզբնական հաճախորդը սպասում է մինչև ժամանակը սպառվի:

Խիստ հակադարձ ուղու զտումը կարող է գցել մուտքային փաթեթը նախքան դեմոնը կկարդա այն: Նախ ստուգեք այդ հաշվիչը, որովհետև զտիչի գցումը և երթուղավորման սխալը դրսից նույն տեսքն ունեն:

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Առաջին հրամանը ցույց է տալիս, թե որ լռելյայն երթուղին է հաղթում հիմա: Երկրորդը հայտնում է՝ խիստ զտումը գործում է գլոբալ, թե յուրաքանչյուր ինտերֆեյսի համար, իսկ երրորդը ցույց է տալիս փոխանցման շղթայի ցանկացած կանոն, որը կարող է ներգրավված լինել:

Վերադարձի ուղին պահելու երեք եղանակ

Ծառայության նպատակակետը թունելից բացառելը ամենափոքր տարբերակն է: LAN դարպասին ուղղված հոսթ-երթուղին, գումարած ֆիզիկական հասցեին, այլ ոչ թե ամեն հասցեին կապված դեմոնը, այդ մեկ հոսքը պահում է թունելից դուրս: Փոփոխությունը տեղական է և հեշտ հետարկելի:

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

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Առաջին երկու հրամանները կառուցում են այլընտրանքային ուղին հանրային հասցեից եկող պատասխանների համար: Երրորդը հարցնում է միջուկին, թե կոնկրետ այդ աղբյուրն ու նպատակակետը որ ուղին կանցնեն, և այդպես հաստատում եք, որ կանոնը որևէ ազդեցություն ունի:

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

Երբ տուփը երթուղավորում է նաև LAN-ի համար

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

Այնուհետև կապերի հետևումը տեսնում է պատասխան մի հոսքի համար, որը երբեք չի գրանցել, և գցում է այն: Նպատակակետի թարգմանությունը մուտքային կապը հասցնում է սարքին, իսկ աղբյուրի թարգմանությունը պատասխանը ցույց է տալիս այնպես, ասես այն ինքը երթուղիչից է եկել:

Քաղաքականության երթուղին, որը փոխանցված պորտը պահում է WAN-ի վրա, մինչ երթուղիչի սեփական երթևեկությունն օգտագործում է թունելը, ավելի մաքուր համարժեքն է: Աղբյուրի թարգմանության բացակայության դեպքում պատասխանը հասցեագրված է արտաքին հաճախորդին, և ներքին սարքն ընդհանրապես երթուղի չունի դեպի այդ հասցեն:

Երեք փորձարկում, որոնք բաժանում են պատճառները

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

Նախ շտկեք երթուղավորման հարցը, հետո նայեք անուններին: Երկուսը խառնելը հենց այն է, ինչպես աշխատող սերվերը մեղադրվում է կոտրված լուծիչի համար:

Գրանցեք, թե որ ինտերֆեյսն է անվանում բացառությունը, և պահեք կոնֆիգուրացիան տարբերակների վերահսկողության տակ: Ինտերֆեյսի դեմ գրված կանոնը, որը թարմացումից հետո վերանվանվում է, այսօր անցնում է և ձախողվում է հաջորդ վերագործարկումից հետո: