iptables հոսթ միայն VPN-ով՝ անվանեք tun սարքը, ոչ թե tun+

-o tun+ գրելը ճշգրիտ հրահանգ է թվում, բայց իրականում նիշ է, որը համապատասխանում է միջուկի բոլոր թունելներին։ Երկրորդ VPN հաճախորդը, կոնտեյների կամուրջը կամ ընկած սեսիայից մնացած ինտերֆեյսը բոլորը բավարարում են այն, և հոսթն այդժամ թույլ է տալիս երթևեկություն, որը քաղաքականությունը պետք է կանխեր։ Ստորև տրված ընթացակարգը ամրագրում է մեկ սարքի անուն, դասավորում բացառություններն այնպես, որ թունելն իսկապես ձևավորվի, և ձեզ թողնում է վերադարձի ուղի, եթե կանոնները վատ դասավորվեն։ Յուրաքանչյուր քայլ բավական կարճ է, որ ինքնուրույն հետարկվի։

Քայլ 1․ գրանցեք այն կանոնները, որ հիմա ունեք

Նախքան լռելյայն քաղաքականությունը փոխելը պահեք ընթացիկ վիճակը, որպեսզի հետգլորումը հրահանգ լինի, ոչ թե հիշողություն։ iptables-save > /root/iptables.pre-ը գրում է յուրաքանչյուր աղյուսակ այնպիսի ֆայլում, որը կարող եք վերականգնել, և բաց root սեսիայով երկրորդ տերմինալը պարանոյա չէ, երբ ձեր սահմանելիք քաղաքականությունը գցում է այն կրող կապը։ Եթե հեռվից եք աշխատում, պլանավորեք նաև flush՝ որպես անվտանգության անջատիչ։

Ապա թվարկեք ինտերֆեյսները, որովհետև ենթադրված անունն այն անունն է, որը պետք է կարդացած լինեիք՝ ip -br link-ը ցույց է տալիս, թե ինչ կա հենց հիմա, և թունելը չի երևա, մինչև այն վեր չկենա։ Գրեք սարքերի անունները, երբ կարդում եք դրանք։

Քայլ 2․ տվեք թունելին իր անունը

OpenVPN-ը հաճախորդի կարգավորումներում ընդունում է dev tun_work, և այդժամ Linux-ը ստեղծում է հենց այդ անունով ինտերֆեյս՝ tun0 հատկացնելու փոխարեն։ Անունը մնում է կայուն վերամիացումների միջև, քանի դեռ ուրիշ ոչինչ չի հավակնում դրան, և հենց դա է սարքին անվանող կանոնը իմաստալից դարձնում։

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

Քայլ 3․ գրեք քաղաքականությունը՝ endpoint-ի բացառությամբ առաջինը

Միայն VPN-ով հոսթը լռելյայն մերժման հոսթ է՝ կարճ բացառությունների ցանկով, և ամենակարևոր բացառությունն այն է, որը թույլ է տալիս թունելին գոյություն ունենալ, Կառուցեք այն այս հերթականությամբ՝ endpoint-ի կանոնը թունել-սարքի կանոնից առաջ, որպեսզի ձեռքսեղմումն ունենա ուր գնալու տեղ։

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

Քայլ 4․ ստուգեք հերթականությունը, ոչ միայն առկայությունը

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

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

Քայլ 5․ դարձրեք այն դիմացկուն բեռնարկման և հասցեների ընտանիքի նկատմամբ

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

Ապա ստուգեք IPv6-ը առանձին, որովհետև IPv4-ի լավ լռելյայն մերժման քաղաքականությունը ոչինչ չի ասում մյուս ընտանիքի մասին։ ip -6 route-ը ձեզ կասի՝ արդյոք հոսթն ունի երթուղի, որը կարող է երթևեկություն տանել միայն IPv4-ը սպասարկող թունելի շուրջը, և ip6tables-ը կամ nftables-ը պահանջում են իրենց համարժեք կանոնները։ Փորձարկեք IPv6-only նպատակակետով՝ կանոնախմբի համաչափությանը վստահելու փոխարեն։

Քայլ 6․ ստուգեք և պատրաստ եղեք վերականգնել

Բարձրացրեք թունելը, հաստատեք, որ ձեր նախատեսած ծառայությունն աշխատում է, ապա փորձեք մի բան, որը քաղաքականությունը պետք է մերժի։ Վերականգնեք iptables-restore < /root/iptables.pre-ով, եթե պատասխանը զարմացնում է ձեզ, և միայն դրանից հետո սկսեք խմբագրել կանոնները։ Կայունությունը՝ զուգորդված փորձարկված վերականգնման ուղու հետ, այն է, ինչը սա դարձնում է փոփոխություն, որը կարող եք երկու անգամ անել։