ufw allow 443-ը ոչինչ չարեց VPN-ի հետևում գտնվող ծառայության համար

Ping-ը հաջողվում է VPN հաճախորդից, TCP ծառայությունը ժամանակը սպառում է, և ufw allow 443/tcp ընդհանրապես ոչինչ չի փոխում։ Երբ հավելվածն աշխատում է դարպասի հետևի հոսթի վրա, այլ ոչ թե դարպասի վրա, այդ թույլտվությունը գրված է եղել սխալ երթևեկության ուղու համար։ Փաթեթը հասցեագրված չէ հրակայանին և չի հանձնվում տեղական գործընթացին, ուստի մուտքային կանոնները երբեք չեն տեսնում այն։ Ուղղումը փոխանցվող հոսքին ուղղված երթուղու կանոն է, և դրա ապացույցն արդեն կա մատյանում։

Որոշեք՝ նպատակակետը տեղական է, թե փոխանցվող

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

Մատյանի տողը, որը ցույց է տալիս նույն ինտերֆեյսը ինչպես IN, այնպես էլ OUT դաշտերում, դեռ կարող է նկարագրել երթուղավորված փաթեթ, որովհետև մեկ սարքից հաճախորդներ ներս և դուրս տանող թունելը հենց այդպիսին է թվում։ Նպատակակետի հասցեն լուծում է հարցը ավելի արագ, քան ինտերֆեյսների անունները։ Նույն անունը երկու անգամ տեսնելը չի ապացուցում տեղական առաքում, և այնպիսի թունելային ինտերֆեյս հորինելը, որը տեղակայումը երբեք չի ստեղծել, նույնպես չի օգնում։

Կարդացեք արգելափակումը ցանկացած կանոն ավելացնելուց առաջ

Կրկնեք մեկ լիազորված միացման փորձ և գրանցեք դրա աղբյուրը, նպատակակետը, արձանագրությունը և նպատակակետ նավահանգիստը այնպես, ինչպես դարպասը գրանցել է դրանք։ Համեմատեք այդ չորս արժեքները մատյանի գրառման և ծառայության իրական գտնվելու վայրի հետ։ Ավելի վաղ հաջող ping-ը ապացուցում է միայն, որ իր սեփական փոխանակումը թույլատրված էր, և հրակայանը կարող է բոլորովին այլ կերպ վարվել հավելվածին ուղղված TCP SYN-ի հետ։

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

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

Գրեք ամենանեղ տեղավորվող երթուղու կանոնը

Այս օրինակում հաճախորդները գալիս են tun0-ով 172.20.8.0/24-ից, ծառայությունը լսում է 10.30.0.15-ում 8443 նավահանգստում, և դարպասը դուրս է գալիս ens5-ով։ Այդ արժեքները ընտրվել են, որպեսզի բոլորովին նման չլինեն ամպային VPC-ի 10.0.0.0/16 կանխադրվածին կամ տնային 192.168.0.0/16 ցանցին, և 8443-ը օրինակը հեռու է պահում դարպասի սեփական 443 լսողից։

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

Պահեք վերադարձի ուղին վիճակով

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Ստուգեք, ինչ UFW-ը չի կարող պարտադրել ձեր փոխարեն

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

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Ապա նայեք հոսթից դուրս։ Ամպային օրինակում հյուրի UFW քաղաքականությունը չի փոխարինում անվտանգության խմբերին, ենթացանցի ACL-ներին կամ մատակարարի սեփական փոխանցման կարգավորումներին, ուստի տեղական արգելքը ապացույց է մեկ շերտի մասին, ոչ թե ապացույց, որ բոլոր մյուս շերտերը թույլատրում են ծառայությունը։

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