macOS pf անջատիչ OpenVPN-ի համար՝ կանոններ, որոնք փակվում են

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

Ինչ կարող է որոշել փաթեթների զտիչը, և ինչ չի կարող

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

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

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

Նախ կարդացեք ինտերֆեյսի և վերջնակետի փաստերը

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

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

route -n get default
ifconfig -l
scutil --nc list

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

Գրեք կանոնների հավաքածուն թունելի ուղու շուրջ

Ներքևի ֆայլը լռելյայն մերժում է և վերաընդունում հինգ բան՝ loopback, թունելի սարքը, հաճախորդի ուղին դեպի իր սերվերը, թունելից առաջ օգտագործվող լուծիչը, և այն երկու փոխանակումները, որոնք անլար կապը պիտանի են պահում։ Ինտերֆեյսների անունները և սերվերի հասցեն գալիս են ձեր մեքենայից, ուստի փոխարինեք ձեր հաստատած արժեքները։ Թունելի համարը նույնպես չի համընկնի ձերին։

set skip on lo0
block all
pass out quick on utun0
# maintain this line when the server address changes
pass out quick on en1 inet proto udp to 203.0.113.10 port 1194
# only the resolver the client uses before the tunnel exists
pass out quick on en1 inet proto udp to 192.0.2.53 port 53
pass out quick on en1 inet proto udp from any port 68 to any port 67
pass out quick on en1 inet proto udp to 224.0.0.251 port 5353

DHCP տողը գոյություն ունի, որովհետև Mac-ը հասցե է խնդրում նախքան այն ունենալը, ուստի հարցումը դուրս է գալիս 68 պորտից դեպի 67 պորտ՝ առանց պիտանի աղբյուրի հասցեի։ Multicast տողը թույլ է տալիս համակարգին դատել՝ արժե արդյոք օգտագործել անլար կապը, և այն հեռացնելը ստեղծում է մեքենա, որը աշխատող ցանցում հայտնում է կապի բացակայության մասին։ Վերջնակետի տողը թույլ է տալիս OpenVPN-ին ընդհանրապես հասնել իր սերվերին. առանց դրա block all-ը գցում է արտաքին ձեռքսեղմումը, և թունելը երբեք չի բարձրանում։ Լուծիչի տողը նեղ է ընդհանուր DNS թույլտվությունից, որովհետև անվանում է մեկ հասցե և մեկ պորտ՝ մեքենայի արած յուրաքանչյուր հարցման փոխարեն։

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

Իջեցրեք թունելը, ապա վերագործարկեք

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

sudo pfctl -n -v -f /etc/pf.conf
sudo pfctl -f /etc/pf.conf
sudo pfctl -e
sudo pfctl -s rules
sudo pfctl -s Anchors
sudo pfctl -a <anchor> -s rules
sudo pfctl -s info

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

Վերագործարկումը այն մասն է, որը մարդիկ բաց են թողնում։ macOS-ը բեռնման ժամանակ կարդում է /etc/pf.conf-ը, բայց ֆայլը կարդալը նույնը չէ, ինչ զտիչը միացնելը, ուստի հիմա աշխատող կանոնների հավաքածուն կարող է անգործուն լինել վերագործարկումից հետո։ Դրանից հետո գործարկեք sudo pfctl -s info-ը և հաստատեք, որ կարգավիճակի տողը զտիչը հաղորդում է որպես միացված։

Ելքն ու վերագործարկման ուղին պահեք ազնիվ

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

sudo pfctl -d
sudo pfctl -f /etc/pf.conf.previous
sudo pfctl -s rules

Կայունության համար պետք է launch daemon, որը գործարկում է pfctl -e-ը և բեռնման ժամանակ բեռնում ձեր ֆայլը։ Վերաբերվեք դրան ինչպես ցանկացած այլ արտոնյալ աշխատանքի՝ բացարձակ ուղիներ, մատյան, որը կարող եք հետո կարդալ, և փորձարկում մեքենայի վրա, որին ֆիզիկապես կարող եք հասնել։ Լուռ ձախողվող daemon-ը մեքենային թողնում է անպաշտպան և նորմալ տեսքով։

Փաստաթղթավորեք բացերը՝ սկսած երկրորդ VPN հաճախորդից, որը ստեղծում է իր սեփական թունելի սարքը։ Ձեր կանոնները անվանում են մեկ թունելի ինտերֆեյս, ուստի երկրորդը մնում է արգելափակված կամ բռնվում է ավելի ուշ ավելացված լայն կանոնով։ Tethering-ի և hotspot-ի ինտերֆեյսները հայտնվում են միայն երբեմն և արժանի են նույն նշումին։ Այդ բացերից ոչ մեկը պատճառ չէ քաղաքականությունը բաց թողնելու. դրանք այն պայմաններն են, որոնցում այն դեռ գործում է։