Անջատման սկրիպտ, թե firewall կանոն՝ ո՞րն է կանգնեցնում արտահոսքը։
Միացումն ընդհատելիս ինտերֆեյսներն իջեցնելը կոպիտ է և հաճախ աշխատում է առանց լիազորությունների։ Համեմատեք այն firewall կանոնի հետ, որը դիմանում է անկմանը և փակում բացը։
Երկու նախագիծ նույնն են խոստանում՝ երբ թունելն ընկնում է, ոչինչ բաց տեսքով դուրս չի գալիս։ Մեկը անջատման պահին սկրիպտ է աշխատացնում և կտրում ինտերֆեյսները։ Մյուսը firewall կանոնը թողնում է ուժի մեջ և ոչինչ չի պահանջում VPN հաճախորդից։ Նրանք տարբերվում են նրանով, թե ով ունի գործելու լիազորություն, ինչ է կատարվում բացի ընթացքում և ինչպես է մեքենան հետո վերադառնում ցանց։ Այս երեք կետերով համեմատելը ավելի օգտակար է, քան վիճելը, թե որն է ավելի խիստ։
Նույն աշխատանքը՝ երկու մեխանիզմով
Հաճախորդը կարող է կեռիկներ աշխատացնել թունելի բարձրանալիս և անջատվելիս, եթե պրոֆիլը թույլ է տալիս սկրիպտի կատարում։ Այդ կեռիկն աշխատում է հաճախորդի կյանքի ցիկլի ներսում՝ այն պահին, երբ միացումը փակվում է։ Firewall կանոնը, ընդհակառակը, պատկանում է համակարգին և չի հոգում՝ հաճախորդը աշխատում է, ընկել է, թե սպանվել։
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
Այդ աղյուսակը ողջ փաստարկն է։ Սկրիպտը, որ աշխատում է միայն կոկիկ փակման ժամանակ, ծածկում է այն դեպքը, որն ամենաքիչն էր ձեզ անհանգստացնում. կարևոր դեպքը վթարն է կամ ցանցի անհետացումը, և ոչ մեկը մաքուր անջատում չի տալիս։
Ինչ կարող է և ինչ չի կարող անել անջատման կեռիկը
Փաստաթղթավորված ձևը շրջում է ցանցային ինտերֆեյսներով և իջեցնում ամեն ինչ, բացի loopback-ից։ Երբ ֆիզիկական սարքն իջեցված է, ոչինչ չի կարող փախչել թունելից դուրս, և դա հենց մտադրությունն է։
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
doneԱյն իջեցնում է նաև տեղական ցանցը, ցանկացած ծառայություն, որ մեքենան հյուրընկալում է, և այն ուղին, որով կուղղեիք խնդիրը։ Դյուրակիր համակարգչում անլար սարքը երբեմն հետո ձեռքով փոխարկել է պահանջում, այնպես որ կարճ ընդհատումը դառնում է վերանորոգման նստաշրջան։ Ավելի վատ՝ կեռիկին կարող են ընդհանրապես չթույլատրել այդ ամենն անել. երբ հաճախորդը հրաժարվում է լիազորություններից, անջատման սկրիպտն աշխատում է ոչ արտոնյալ հաշվով, և ինտերֆեյսի յուրաքանչյուր փոփոխություն ձախողվում է թույլտվության սխալով, որը գրվում է հենց այն պահին, երբ ոչ ոք չի կարդում մատյանը։
Ստուգեք, թե ինչպես է հաճախորդը մեկնարկվում, նախքան կեռիկին վստահելը։ Սկրիպտը, որն աշխատում է ձեռքով root-ով գործարկելիս, ոչինչ չի ապացուցում այն ծառայության մասին, որ մեկնարկում է բեռնման պահին։
Ինչն է firewall կանոնն այլ կերպ անում
Կանոնը, որը թույլ է տալիս միայն թունելի երթևեկությունը, շարունակում է աշխատել, երբ հաճախորդի պրոցեսը գնացել է, քանի որ միջուկը կախված չէ այդ պրոցեսից։ Կանոնն ավելի նեղ էլ է. այն արգելափակում է հենց այն հոսքերը, որոնց համապատասխանում է, և անվթար է թողնում loopback-ը, տեղական ենթացանցը և վերականգնման ուղին, դրա համար էլ մեքենան անելանելի չի թողնում։
Գինն այն է, որ կանոնը պետք է գրվի և պահպանվի նրա կողմից, ով տիրապետում է հոսթի firewall-ին, և այն պետք է անվանի այն թունել-սարքը, որն իրականում ստեղծում է հաճախորդը։ Դա նշանակում է, որ կանոնն ու պրոֆիլը պետք է պահպանվեն միասին. վերանվանված ինտերֆեյսը թողնում է firewall, որն արգելափակում է ամեն ինչ և ոչինչ չի բացատրում։
Մեխանիզմներից ոչ մեկը մյուսին ավելորդ չի դարձնում։ Firewall կանոնը, որը խմբագրումից հետո երբեք չի վերաբեռնվում, նույնքան հորինված է, որքան սկրիպտը, որ երբեք չի աշխատում։
persist-tun-ը որոշում է՝ բաց կա, թե ոչ
Երբ թունել-սարքը դիմանում է անջատմանը, նաև դիմանում են դեպի այն ուղղված երթուղիները։ Երթևեկությունն այդ ժամանակ դեն է նետվում, ոչ թե վերաուղղորդվում, ուստի լռելյայն երթուղին չի ընկնում հետ դեպի ֆիզիկական դարպաս։ Հենց այդ վարքն է արտահոսքը քիչ հավանական դարձնում նույնիսկ նախքան որևէ firewall կանոնի միջամտությունը։
Առանց այդ կարգավորման սարքը հեռացվում է երթուղիների հետ միասին, և լռելյայն երթուղին կարող է նորից ցույց տալ ֆիզիկական դարպասին։ Կանի դա, թե ոչ՝ կախված է հարթակից և հաճախորդից, և հենց դրա համար վիճակը պետք է դիտարկել, այլ ոչ ենթադրել։ Կարգավորումը դիտեք որպես kill switch-ի մաս, ոչ որպես արտադրողականության ընտրանք։
Կենդանի պահեք վերամիացման ուղին, ապա փորձարկեք չորս վիճակ
Խիստ արգելափակումը կարող է նաև խանգարել հաճախորդին նորից միանալ, քանի որ հաճախորդին դեռ պետք է երթուղի դեպի սերվերը ֆիզիկական դարպասով, մինչ մնացած ամեն ինչ մերժվում է։ Տեղադրեք հոսթ-երթուղի այդ մեկ հասցեի համար, նախքան թունելը կբարձրանա, և սկզբում լուծեք անունը, քանի որ DNS-ը կարող է արգելափակված լինել մինչև այն պահը, երբ այն ձեզ պետք լինի։
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0Ապա ստուգեք վիճակները, ոչ թե պիտակը։ Դիտավորյալ անցեք չորս պահով՝ սառը մեկնարկ առանց թունելի, առողջ նստաշրջան, ոչ ոքի չպահանջված անկում և նստաշրջանը վերականգնումից հետո։ Ամեն պահին կարդացեք լռելյայն երթուղին և արեք մեկ հարցում, որի ելքի հասցեն տեսանելի է։ Ծրագիրը, որ հանձնվում է, մինչ թունելն իջեցված է, ոչինչ չի ասում փոստային հաճախորդի կամ թարմացնողի մասին, ուստի կրկնեք վերջին ստուգումը մեկ ֆոնային ծրագրով։ Գրեք կանոնը, ինտերֆեյսների անունները և վերականգնման քայլերը, որովհետև այն kill switch-ը, որ ոչ ոք չի կարող ստուգել, լոկ լուր է։