Սահմանափակեք OpenVPN-ի SNAT կանոնը, նախքան այն կկոտրի nginx-ը

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

Համոզվեք, որ կոնտեյները կարող է ստեղծել tun սարք

Ուրիշ ոչինչ նշանակություն չունի, եթե թունելի ինտերֆեյսը չի կարող գոյություն ունենալ։ Ստուգեք, որ /dev/net/tun-ը առկա է և որ թեստային սարքի ստեղծումը հաջողվում է, որովհետև շատ մատակարարներ լռելյայն անջատում են tun-ը կոնտեյներներում։ firewall-ի ոչ մի աշխատանք չի փոխհատուցում այն սարքը, որը երբեք չի ստեղծվել։

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

Որոշեք, թե MASQUERADE-ը ինչ է անում այս ինտերֆեյսում

Սովորական վիրտուալ մեքենայում սովորական ելքի կանոնը POSTROUTING MASQUERADE է հիմնական ինտերֆեյսից։ OpenVZ կոնտեյներում տեսանելի սարքը հաճախ venet0-ն է՝ հոսթի կողմից կառավարվող վիրտուալ ինտերֆեյս, ոչ թե երթուղավորված ցանցային քարտ, և MASQUERADE-ը այնտեղ միշտ չէ, որ իրեն պահում է այնպես, ինչպես ենթադրում են ձեռնարկները։

Աշխատունակ ձևը հստակ թարգմանությունն է դեպի այն հասցեն, որին հաճախորդները արդեն հասնում են, երկու ուղղությամբ էլ թույլատրված փոխանցմամբ։ Սերվերի կոնֆիգուրացիայից pool-ը փոխարինելը նույնքան կարևոր է, որքան հասցեն փոխարինելը։ Կարդացեք յուրաքանչյուր տողը նախքան այն տեղադրելը։

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

Սահմանափակեք կանոնը մեկ pool-ով և մեկ ինտերֆեյսով

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

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

Լուծումն այն է, որ համընկնումը նեղացվի թունելի pool-ին և ելքի ինտերֆեյսին, ապա ավելացվի մեկ կանոն յուրաքանչյուր pool-ի համար՝ մի քանիսը ծածկելու համար մեկ կանոն լայնացնելու փոխարեն։

Դարձրեք կանոնները մշտական և պարզեք, թե ով էլ է դրանց տերը

Ձեռքով ավելացված կանոնները անհետանում են վերագործարկման ժամանակ, այնպես որ պահպանեք դրանք iptables-save-ով կամ կառավարեք netfilter-persistent-ի միջոցով այնտեղ, որտեղ այն տեղադրված է։ Հաստատեք, որ վերականգնումը աշխատում է մինչև OpenVPN-ի մեկնարկը։ Այնուհետև մեկ անգամ դիտավորյալ վերագործարկեք՝ միջադեպի ընթացքում բացը հայտնաբերելու փոխարեն։

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

Ստուգեք հաշվիչներով և մեկ գրանցված հոսքով

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

Սերվերի վրա կարդացեք փաթեթների հաշվիչները NAT և FORWARD կանոնների վրա iptables -t nat -L -v -n-ով և դիտեք մեկ հոսք գրանցման մեջ։ Եթե հաճախորդի հասցեն հայտնվում է գրանցման մեջ և պատասխան չի հաջորդում, բացը վերադարձի ուղու վրա է կամ մատակարարի զտման մեջ, ոչ թե հաճախորդի պրոֆիլում։ Համեմատեք գրանցված աղբյուրը այն հասցեի հետ, որին թարգմանում է կանոնը, որովհետև անհամապատասխանությունը նշանակում է, որ սկզբում համընկել է այլ կանոն։ Մեկ դիտարկված հոսքը լուծում է ավելին, քան կոնֆիգուրացիա կարդալու մեկ էջը։

Պահեք pool-ը, թարգմանված հասցեն և ինտերֆեյսի անունը միասին փոփոխությունների գրանցամատյանում։ Մեկ pool-ի համար ճիշտ կանոնը սխալ է թարգմանում հաջորդը։