VPS-ի ֆայրվոլ. բացեք միայն VPN պորտը, ապա ապացուցեք այն

Ֆայրվոլը, որը թույլ է տալիս միայն VPN պորտը, մեկ կանոն չէ։ Դա երեք առանձին որոշում է, որոնք պատահաբար վերաբերում են նույն պորտի համարին. մուտքային շղթան որոշում է, թե ինչ կարող է հասնել տեղային գործընթացին, փոխանցման շղթան որոշում է, թե ինչ կարող է անցնել հոսթով թունելի հաճախորդների անունից, իսկ NAT աղյուսակը վերագրում է աղբյուրի հասցեն դուրս գալու ճանապարհին։ Սխալվեք դրանցից մեկում, և արդյունքը հազվադեպ է մաքուր ընդհատում։ Դուք ստանում եք հոսթ, որը ընդունում է հաճախորդներին, բայց ոչինչ չի բեռնում, կամ հոսթ, որը փակ է թվում, մինչև ինչ-որ մեկը կարդա շղթաների հերթականությունը։

Միակ պորտը, որը հնարավոր չէ փակել

VPN լսողը պետք է ընդունի միացումներ հասցեներից, որոնք չեք կարող կանխատեսել, ուստի այն հանրային ծառայություն է ըստ սահմանման։ Սա է այն միակ բացառությունը, որի շուրջ կառուցված է դիզայնը. մեկ UDP պորտ OpenVPN-ի համար, մեկ UDP պորտ WireGuard-ի համար, մեկ TCP պորտ SSL VPN-ի համար։ Մնացած ամեն ինչ թունելի հետևում է, այսինքն՝ հավելվածային ծառայությունները պետք է կապվեն թունելի հասցեին կամ loopback-ին, ոչ թե բոլոր ինտերֆեյսներին։

Սակայն կապելը կատարում չէ։ 0.0.0.0-ին կապված գործընթացը հասանելի է միայն այն դեպքում, երբ կանոնը թույլ է տալիս, և լռելյայն քաղաքականությունը պահուստն է այն երթևեկության համար, որը չի համապատասխանել ոչ մի կանոնի, այլ ոչ թե պորտը կառավարող կանոնը։ Ձեր drop-ից վեր դրված accept-ը մնում է accept, և ծառայությունը հրապարակային հասցեից հեռացնելը ինքնուրույն բարելավում է, ոչ թե շղթայի փոխարինում։

Մուտքը, փոխանցումը և NAT-ը տարբեր հարցերի են պատասխանում

Մուտքային երթևեկությունը նախատեսված է հենց հոսթին, ուստի այնտեղ են ապրում VPN լսողը և վարչական ուղին։ Փոխանցման երթևեկությունն անցնում է հոսթով, և թունելի հաճախորդներին այն պետք է net.ipv4.ip_forward=1-ի հետ միասին։ Դասական կիսով չափ կոտրված կոնֆիգուրացիան թույլ է տալիս ելքային հոսքը և մոռանում վերադարձի ուղղությունը, այնպես որ հաճախորդը ավարտում է ձեռքսեղմումը, ապա ոչինչ չի բեռնվում. հաստատված և կապակցված երթևեկության համար conntrack կանոնը ծածկում է այդ ուղղությունը։

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

IPv6-ը երկրորդ քաղաքականություն է, ոչ թե հետագա միտք։ Խիստ IPv4 շղթա և ip6tables-ում բաց քաղաքականություն ունեցող հոսթը ոչինչ չի փակել. ծառայությունները դեռ հասանելի են մյուս ընտանիքով։ Կամ արտացոլեք կանոնների հավաքածուն ip6tables-ով, կամ գիտակցաբար անջատեք IPv6-ը հրապարակային ինտերֆեյսում, և գրեք, թե որն եք ընտրել։

Հենք, որը կարդացվում է մեկ անցումով

Սկսեք մերժումից, ապա ավելացրեք միայն այն, ինչ հոսթին անհրաժեշտ է։ Նախ loopback-ը և պատասխանները, ապա վարչական ուղին, ապա թունելի լսողը, ապա հաճախորդների համար փոխանցման քաղաքականությունը.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

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

Փակել վերջին պորտը՝ չկորցնելով հոսթը

Դիզայնում մի որոգայթ կա։ Եթե SSH-ը գոյություն ունի միայն թունելի միջոցով, ձախողված VPN ծառայությունը տանում է SSH-ը իր հետ, և վերադառնալու միակ ճանապարհը կարող է լինել մի կոնսոլ, որը երբեք չեք բացել։ Նախքան վերջին հրապարակային պորտը փակելը հաստատեք, որ այդ կոնսոլը գոյություն ունի և որ դուք իսկապես կարող եք օգտագործել այն, կամ պահեք մեկ նեղ վարչական ուղի, որը կախված չէ թունելից. SSH ֆիքսված հասցեից, միայն բանալիներ, գաղտնաբառով նույնականացումն անջատված։

Կիրառեք փոփոխությունը արդեն հաստատված սեսիայից, ոչ թե այն կապից, որը պատրաստվում եք զտել։ Պլանավորեք հետադարձ, որպեսզի սխալը սպառվի, այլ ոչ դառնա մշտական, օրինակ՝ systemd-run --on-active=10min աշխատանք, որը վերականգնում է նախորդ կանոնների հավաքածուն, և թողեք երկրորդ SSH սեսիան բաց, մինչ փորձարկում եք առաջինը։ Ապա ստուգեք, որ հետադարձ աշխատանքը իսկապես գործարկվում է, որովհետև չփորձարկված վերականգնումը նույնն է, ինչ վերականգնման բացակայությունը։

Ստուգեք ուղին, ոչ թե սկրիպտը

Կարդացեք բեռնված կանոնները, ոչ թե այն ֆայլը, որը պետք է բեռներ դրանք։ Լիազորված արտաքին հոսթից հաստատեք, որ պատասխանում են միայն նախատեսված պորտերը. թունելի ներսից հաստատեք, որ այն ծառայությունները, որոնք ուզում էիք հրապարակել, հասանելի են։ Լռելյայն մերժող քաղաքականությունը, որը նաև արգելափակում է թունելի երթևեկությունը, նույն տեսքն ունի, ինչ աշխատող կողպումը, մինչև ինչ-որ մեկը փորձի օգտագործել այն։

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

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

Մեկ սովորությունը ավելի արժեքավոր է, քան կանոնների հավաքածուն. յուրաքանչյուր փոփոխությունից հետո ապացուցեք փոխանցման ուղին հաճախորդի հարցումով, իսկ վերականգնման ուղին՝ երկրորդ սեսիայով։ Կողպումը, որը չեք օգտագործել, ընդամենը վարկած է։