Դու մուտք ես գործում երթուղիչ, ֆորումի գրառումից տեղադրում ես անվտանգության անջատիչի կանոնների հավաքածու, և LAN-ը դադարում է զննել այն պահին, երբ թունելն ընկնում է։ Երկու օր անց երթուղիչը դեռ թարմացնում է իր dynamic DNS գրառումը սովորական WAN-ով, իսկ հյուրի նոթբուքը դեռ հասնում է IPv6 կայքեր։ Երկու վարքագիծն էլ նորմալ են, որովհետև տեղադրված կանոնները ծածկում էին մեկ շղթա և մեկ հասցեների ընտանիք, և դրանցից ոչ մեկը ամբողջ երթուղիչը չէ։ Փաթեթների ուղիները հերթով անցնելը ցույց է տալիս հենց այն, ինչ բաց է թողնվել։

Սկսիր երթուղիչից, ոչ թե նոթբուքից

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

Որևէ բան խմբագրելուց առաջ թղթի վրա նշիր երեք փաստ՝ WAN ինտերֆեյսի անունը, LAN կամրջի անունը և VPN վերջնակետի հասցեն ու պորտը։ Դրանք բոլոր երեքը պետք կգան կանոններում, և ինտերֆեյսների անունները գուշակելը ճիշտ տեսք ունեցող կանոնների հավաքածուի անգործության ամենատարածված պատճառն է։

Անցիր փաթեթի երեք ուղիներով

Նոթբուքից ինտերնետ գնացող թրաֆիկը փոխանցվում է, ուստի անցնում է FORWARD շղթայով։ Թրաֆիկը, որն ինքը երթուղիչն է առաջացնում, օրինակ DNS փոխանցումը, NTP հարցումները, DDNS թարմացումները և VPN-ի կառավարման ալիքը, անցնում է OUTPUT-ով։ Երթուղիչին ուղղված կառավարման թրաֆիկը հասնում է INPUT-ով։

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

Packet pathExampleChain that sees it
LAN client to WAN or tunnelBrowser requestFORWARD
Router-originatedDDNS update, NTPOUTPUT
Addressed to the routerSSH from the LANINPUT

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

Դասավորիր կանոններն այնպես, որ թունելը դեռ կարողանա բարձրանալ

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

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

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

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

IPv6-ին պետք է իր սեփական մուտքի դուռը

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

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Այստեղ նույնպես հերթականությունը կարևոր է՝ loopback-ի թույլտվությունը պետք է նախորդի WAN-ի մերժմանը, այլապես երթուղիչի տեղական ծառայությունները կսկսեն տարօրինակ ձևով ձախողվել։ Եթե ցանցն ընդհանրապես IPv6 չի օգտագործում, այն WAN-ում և LAN-ում անջատելն ավելի պարզ է և ոչինչ մոռանալու տեղ չի թողնում։

Որոշ VPN կլիենտներ լռելյայն ուղի են տեղադրում միայն IPv4-ի համար և անձեռնմխելի են թողնում IPv6-ի գոյություն ունեցող լռելյայնը։ Ստուգիր երթուղային աղյուսակը թունելի միանալուց հետո, այլ ոչ թե ենթադրիր, որ կլիենտը դա լուծել է։

Ապացուցիր դա՝ թունելն անջատած

Կանգնեցրու թունելը երթուղիչից և փորձարկիր երեք տեղից այս հերթականությամբ՝

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

Երթուղու որոնումը ցույց է տալիս, թե ուր կգնա փաթեթը, իսկ հաշվիչները՝ արդյոք քո կանոնները երբևէ համընկել են։ Չհաջողված փորձարկումից հետո զրո փաթեթ ունեցող կանոնը ոչինչ չի պաշտպանում, և սովորական պատճառը ինտերֆեյսի անունն է, որը տարբերվում է մուտքագրածից։ Փորձարկիր երթուղիչի առաջացրած թրաֆիկը բացահայտորեն, որովհետև LAN-ի կողմից փորձարկումը չի կարող գործարկել OUTPUT-ը։

Որոշիր խափանման ռեժիմը նախքան այն քեզ պետք կգա։ Fail-closed-ը կլիենտներին պահում է անցանց, քանի դեռ թունելը չվերադառնա, իսկ fail-open-ը վերականգնում է սովորական WAN հասանելիությունը և չեղարկում է նպատակը այն թրաֆիկի համար, որի մասին մտածում էիր։ VPN հասցեների լողավազանին ուղղված blackhole ուղին բարձր մետրիկով օգտակար երկրորդ շերտ է fail-closed ձևավորումների համար, քանի որ այն պահպանվում է, երբ թունելի ուղին անհետանում է, փոխանակ ընկնելու լռելյայնին։

Ընդունիր կարգավորումը միայն այն ժամանակ, երբ LAN կլիենտը, երթուղիչի առաջացրած հարցումը և IPv6 հարցումը բոլորը ձախողվեն թունելն անջատած, և բոլոր երեքը նորից աշխատեն, երբ այն միանա։

Առնչվող հոդվածներ