UFW բացառություն VPN-ի համար, երբ ծայրակետի հասցեն փոխվում է

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

Թունելը նորից միանում է, հետո ոչինչ չի հեռանում

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

Հանրային որոնման վերադարձրած հասցեն ամրացնելը այսօր աշխատեցնում է և վաղը թողնում կոտրված։ Դա մեկանգամյա փոփոխություն է, ոչ թե սպասարկման քաղաքականություն։

Նկարագրեք այն բացառությունը, որը իրականում նկատի ունեք

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

Ստորև բերված հրամանը ցույց է տալիս ձևը մեկ IPv4 UDP ծայրակետի համար լարային uplink-ի վրա։ Փոխարինեք երկու արժեքներն էլ նրանցով, որոնք ստուգել եք տեղակայման դեմ։

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

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

Թարմացրեք այն որպես մեկ աշխատահոսք

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

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

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

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

Դիտավորյալ հետ կանչեք հին թույլտվությունը

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

Կրկնեք ամբողջ վերանայումը, երբ uplink-ը փոխվում է Ethernet-ից Wi-Fi, երբ փոխվում է տրանսպորտը, կամ երբ ծառայությունը պտտվում է մի քանի հասցեներով։ Ինտերֆեյսին հատուկ կանոնը պետք է դադարի համապատասխանել ցանցի փոփոխությունից հետո, և այդ վարքը ճիշտ է, թեև թվում է հետընթաց։

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