Ուղղել libvirt հյուրի DNS-ը, որն արգելափակում է նշիչային VPN պատնեշը

Լռելյայն libvirt ցանցի հյուրերը անունները կատարելապես լուծում են, քանի դեռ WireGuard ինտերֆեյսը չի բարձրանում, և այնուհետև յուրաքանչյուր որոնում կանգ է առնում նույն տեղում։ dnsmasq դեռ լսում է 192.168.122.1:53 հասցեում, հյուրը դեռ այդ հասցեն ունի որպես լուծիչ, և հարցումը դեռ հասնում է։ Ինչ փոխվել է՝ հենց զետեղարանի վերին հոսքի հարցումը կամ դրա պատասխանը այժմ գցվում է մի կանոնով, որը գնահատվում է ցանկացած զտիչ շղթայից առաջ, որը դուք կմտածեիք խմբագրել։ Ելքը նշիչ է, որը կիրառվում է բավական վաղ, այն կապի վրա, որը պատասխանը ժառանգում է։

Հյուրերը կորցնում են DNS-ը թունելի բարձրանալու պահին

Հաստատեք ձևը նախքան ինչ-որ բան փոխելը։ Իջեցրեք թունելը, գործարկեք dig @192.168.122.1 example.com-ը հյուրից և տեսեք, որ այն պատասխանում է։ Բարձրացրեք թունելը, կրկնեք և տեսեք, որ այն ժամանակը սպառում է։ Արդյունքների այս զույգը մեկ քայլով բացառում է կոտրված libvirt ցանցը, սխալ լուծիչի հասցեն և մեռած dnsmasq-ը։

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

Ինչու ավելի ուշ շղթայում accept կանոնը երբեք չի գործարկվում

Նշիչային VPN պատնեշը որոշում է՝ նայելով փաթեթի նշիչին կամ կապի նշիչին, ոչ ձեր աղբյուրի հասցեին։ Այն ամենը, ինչ գալիս է ֆիզիկական ինտերֆեյս սպասվող նշիչի բացակայությամբ, մերժվում է, և այդ մերժումը տեղի է ունենում այն կանոնների հավաքածուում, որին պատկանում է նշիչի ստուգումը։ Ավելի ուշ շղթային ավելացված ip saddr 192.168.122.0/24 accept տողը պարզապես երբեք չի դիտարկվում այդ փաթեթի համար, և այդ պատճառով ակնհայտ կանոնը ճիշտ է թվում և ոչինչ չի փոխում։

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

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

Նշեք հարցումը նախքան VPN աղյուսակը այն կտեսնի

Տեղադրեք բացառությունը իր սեփական աղյուսակում, որ ավելի ուշ ընթերցողը գտնի այն առանց VPN կանոնները վերլուծելու:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

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

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

Պահեք անցքը 53 պորտի լայնությամբ

Ինչպես գրված է, սա թույլատրում է DNS libvirt ենթացանցից դեպի զետեղարան TCP կամ UDP 53 պորտով և ուրիշ ոչինչ։ Այն թույլ չի տալիս հյուրերին հասնել համացանց թունելից դուրս, և թույլ չի տալիս զետեղարանին կապեր բացել դեպի հյուրեր։ Եթե հյուրին հետագայում անհրաժեշտ լինի զետեղարանի մեկ այլ ծառայություն, ավելացրեք առանձին կանոն, որը նշում է այդ նպատակակետ պորտը, փոխանակ այս մեկը թուլացնելու։

Եղեք ազնիվ այն մասին, թե ինչ եք փոխանակում։ Հյուրը, որը կարող է հասնել լուծիչի, կարող է նաև կամայական տվյալներ թունելավորել DNS հարցումներով, և այս բացառությունը VPN սահմանի մեջ դիտավորյալ բացվածք է, ոչ թե հայտարարություն, որ տեղական ցանցը վստահելի է։ Աղբյուրը 192.168.122.0/24-ով սահմանափակելը բացվածքը հեռու է պահում յուրաքանչյուր այլ տեղական ենթացանցից, և այդ աղբյուրի դեմ հարցումները հաշվելը էժան է, եթե սպառնալիքը ձեզ համար կարևոր է։

Թող այն վերապրի վերագործարկումը և ապացուցեք երկու կեսերը

Shell հուշման մեջ մուտքագրված կանոնը անհետանում է հաջորդ բեռնարկման ժամանակ, և այն կանոնը, որը բեռնվում է այն բանից հետո, երբ VPN ինտերֆեյսն արդեն անցկացնում է երթևեկություն, պարտվում է մրցավազքում առաջին կապի ժամանակ։ Տեղադրեք աղյուսակը զետեղարանի մշտական nftables կոնֆիգուրացիայի մեջ կամ VPN ծառայությունից առաջ դասավորված unit-ում, և ստուգեք կարգը՝ այն ենթադրելու փոխարեն։

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

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