Ինչպես մեկ կայքը դուրս բերել ձեր WireGuard թունելից

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

Կարդացեք նպատակակետ հասցեն, նախքան թունելին դիպչելը

Բեռնեք կայքը մեկ անգամ թունելը միացված վիճակում, ապա նայեք այն զուգընկերոջ հասցեին, որին զննարկիչը իրականում միացել էր։ Linux-ում, ss -tunp թվարկում է յուրաքանչյուր բաց սոքեթի հեռավոր հասցեն, և dig +short նույն անվան վրա ցույց է տալիս, թե ինչ վերադարձրեց լուծիչը։ Երկու թվերն էլ պահեք ձեր առջև։

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

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

Տեղադրեք մեկ հոսթի երթուղի հաճախորդի վրա

Ենթադրենք, որ ինտերֆեյսը կոչվում է home-wg, իսկ LAN երթուղիչը գտնվում է 192.168.1.1-ում։ NetworkManager-ը վերցնում է երթուղի, որի դարպասը այդ երթուղիչն է, և որի նախածանցի երկարությունը ընդգրկում է ամբողջ 32 բիթը, և միջուկը նախընտրում է այն, որովհետև ամենաերկար նախածանցն է հաղթում։

nmcli connection modify home-wg +ipv4.routes "198.51.100.20/32 192.168.1.1"
nmcli connection up home-wg
ip route get 198.51.100.20

Դարպասը պետք է հասանելի լինի առանց թունելի. հաջորդ ցատկը թունելի հասցեին ուղղելը խաթարում է նպատակը, որովհետև փաթեթը նորից կմտնի այն ինտերֆեյսը, որից փորձում եք խուսափել։ Երբ կապը նորից բարձրանա, ip route get բացառության համար պետք է տպի LAN դարպասը, և նույն հրամանը հանրային լուծիչի համար դեռ պետք է տպի թունելի սարքը։

wg-quick պրոֆիլը երթուղիների դաշտ չունի, ուստի նույն բացառությունն ապրում է մի տողում PostUp , որը հոսթի երթուղին ավելացնում է հիմնական աղյուսակին՝ LAN ինտերֆեյսը դարձնելով դրա սարքը։ Խմբագրելուց հետո իջեցրեք և նորից բարձրացրեք ինտերֆեյսը, որովհետև աշխատող ինտերֆեյսը երբեք չի վերընթերցում իր ֆայլը։ wg-quick-ի տեղադրած fwmark կանոնները ուղղորդում են միայն իր իսկ փաթաթված փաթեթները, այնպես որ սովորական զննարկիչի երթևեկությունը շարունակում է հետևել հիմնական աղյուսակին և գտնում է ձեր /32-ը։

Անջատիչը հաջորդ բանն է, որ արգելափակում է դա

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

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

Փորձարկեք երկու ուղղությունները առանձին։ Բացառության հասցեին ուղղված հարցումը պետք է հաջողվի, մինչդեռ անկապ կայքին ուղղված հարցումը դեռ դուրս է գալիս թունելով։ Եթե երկուսն էլ հաջողվում են, բայց երկրորդը հաղորդում է տնային հասցեն, ապա հրդեհային պատի կանոնների հերթականությունն է սխալ, ոչ թե երթուղին։

DNS-ն է որոշում, թե որ հասցեին զննարկիչը զանգահարի

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

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

Նույն բացառությունը երթուղիչի վրա, մեկ անգամ, յուրաքանչյուր սարքի համար

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

Թողեք թունելը որպես լռելյայն ելք բոլոր մյուս հաճախորդների համար, ապա ստուգեք հաճախորդ մեքենայից, ոչ թե երթուղիչի կոնսոլից։ Բեռնեք բացառության կայքը և երկրորդ կայքը նույն զննարկիչի նստաշրջանում և համեմատեք ելքի հասցեները. եթե երկրորդը դեռ ցույց է տալիս թունելը, ապա քաղաքականության աղյուսակը անում է այն, ինչ դուք խնդրել եք։

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