Միայն մեկ տեղական վեբ ծառայություն շրջանցել VPN-ը՝ ըստ պորտի

Մեկ հոսթի ծառայություն պետք է պատասխանի ինտերնետին ֆիզիկական վերին կապուղու միջով, մինչ մեքենայի մնացած ամեն ինչ շարունակում է օգտագործել թունելը։ Երեք պայման են որոշում՝ արդյոք քաղաքականության վրա հիմնված երթուղավորումը կարող է կրել այդ բեռը, և դրանցից յուրաքանչյուրը էժան է ստուգել նախքան կանոն գրելը։ Ծառայությունը պետք է ավարտվի այս հոսթի վրա, ոչ թե DNAT-ի կամ փոխանցված պորտի հետևում, VPN-ի սեփական կանոնները պետք է թույլատրեն բացառությունը, և դուք պետք է համեմատեք պատասխանը, ոչ թե հարցումը։ Եթե երեքից որևէ մեկը ձախողվի, ստորև բերված հրամանները մաքուր կբեռնվեն, բայց ոչ մի օգտակար բան չեն անի։

Ստուգեք երեք պայմանները նախքան կանոն գրելը

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

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

Համեմատեք պատասխանը, ոչ թե հաճախորդի նպատակային պորտը

TCP 443-ում լսող սերվերի պատասխանը լքում է հոսթը աղբյուր պորտ 443-ով։ Նույն հոսթի զննարկիչը հեռավոր HTTPS կայքին միանալիս ուղարկում է անցողիկ աղբյուր պորտ և նպատակային պորտ 443։ Երկուսն էլ 443 պորտի երթևեկություն են և դրանցից միայն մեկը պետք է վերցնի WAN աղյուսակը, դրա համար էլ նպատակային պորտի համեմատումը կբռներ սխալ կեսը։

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

Կառուցեք ամբողջական վերադարձի աղյուսակ նախքան կանոնը դրան կուղղվի

Դատարկ աղյուսակը նշանակում է երթուղի չկա, ինչը կոտրված ծառայության տեսք ունի, ոչ թե կոտրված քաղաքականության։ Սկզբում լրացրեք այն, այնպիսի աղյուսակի համարով և առաջնահերթությամբ, որոնք հոսթի վրա ուրիշ ոչինչ չի պահանջում:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

Թվերը կարդացեք կենդանի հոսթից՝ դրանք պատճենելու փոխարեն։ ip -4 rule show ասում է, թե որ առաջնահերթություններն են զբաղված, և արդեն գոյություն ունեցող առաջնահերթությանը կանոն ավելացնելը լուռ փոխում է երկու կանոնների հերթականությունը, որոնք առանձին-առանձին կարգին են թվում։

Այստեղ իրական աշխատանքը կատարում են երկու ընտրիչ։ iif lo այն է, թե ինչպես է միջուկը հաղորդում հոսթի ինքնաստեղծ փաթեթների մասին, ուստի կանոնը չի կարող պատահաբար բռնել դրսից եկող փոխանցված երթևեկությունը։ ipproto tcp sport 443 այն նեղացնում է մեկ տրանսպորտի և մեկ պորտի, ինչը այնքան խիստ է, որքան թույլ է տալիս պահանջը։ Հեռացրեք արձանագրության ընտրիչը, և կանոնը կբռնի նաև UDP 443-ը, որ այլ վարքագիծ ունեցող այլ ծառայություն է։

Պահեք մասնավոր պատասխանները թունելի ներսում

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

ip -4 route add table 100 throw 10.90.0.0/24

throw երթուղին ավարտում է որոնումը այս աղյուսակում և փաթեթը վերադարձնում կանոնների ցանկին, ուստի հաջորդող VPN քաղաքականությունը ստանում է իր հնարավորությունը։ Այն ինքը ոչինչ չի երթուղավորում թունել, և եթե ոչ մի հետագա կանոն համապատասխան երթուղի չունի, փաթեթը միևնույն է ձախողվում է. ստուգեք հաջորդ քաղաքականությունը՝ throw-ը լուծում համարելու փոխարեն։

Հակադարձ ուղու զտումը և հոսթի հրդեպատի կանոնները դեռ կիրառվում են ժամանող հարցման վրա։ Նայեք նրանց փաստացի վճիռներին նախքան վավերացումը թուլացնելը, որովհետև երթուղային բացառությունը չի ստիպում rp_filter-ին ընդունել վերադարձի ուղի, որը նա համարում է անհնար։

Փորձարկեք TCP, ապա QUIC, ապա վերագործարկում

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

HTTP/3-ը մատուցվում է UDP-ով և TCP կանոնով չի համեմատվի, ուստի QUIC լսողին պետք է իր սեփական ընտրիչը, այլապես այն կշարունակի օգտագործել թունելը, մինչ HTTPS-ը աշխատում է։ Պահպանեք այն կանոնները, որոնց վրա կանգ եք առել, ինտերֆեյսին տիրող բաղադրիչում, և հաստատեք դրանք վերամիացումից կամ DHCP նորոգումից հետո։ Երբ մրցակից կառավարիչը վերագործարկումից հետո հեռացնում է աշխատանքային երթուղի, դա սեփականության խնդիր է, որը պետք է լուծել աղբյուրում, ոչ թե պատճառ՝ վերևում ավելի լայն NAT կանոններ ավելացնելու։