nginx pozulmazdan əvvəl OpenVPN SNAT qaydasını məhdudlaşdırın

Eyni tipli hostlardan iki nasazlıq gəlməyə davam edir. Birincisində müştərilər autentifikasiyadan keçir və sonra tuneldən kənarda heç nəyə çatmır. İkincisində VPN qalxır və serverin öz vebsaytı cavab verməyi dayandırır; bu, yan təsir kimi göründüyü üçün daha narahat edicidir. Konteyner əsaslı VPS-də hər ikisi adətən eyni qısa yoxlama siyahısına qayıdır və sıra vacibdir: əvvəlcə cihaz, ikinci tərcümə, üçüncü əhatə dairəsi.

Konteynerin tun cihazı yarada bildiyini təsdiqləyin

Tunel interfeysi mövcud ola bilmirsə, başqa heç nə vacib deyil. /dev/net/tun faylının olduğunu və test cihazının yaradılmasının uğurlu olduğunu yoxlayın, çünki bir çox provayder konteynerlərdə tunu standart olaraq söndürür. Heç bir firewall işi heç vaxt yaradılmamış cihazı kompensasiya etmir.

Cihaz yoxdursa, onu yalnız host və ya provayder aktivləşdirə bilər. Fərqli bir plan çox vaxt bir həftə davam edən açıq dəstək müzakirəsindən daha ucuzdur. Tək bir OpenVPN log sətrini oxumazdan əvvəl bunu təsdiqləyin. Əks halda axşamı heç vaxt paket görməyəcək qaydaları tənzimləməyə sərf edirsiniz.

MASQUERADE-in bu interfeysdə nə etdiyini müəyyənləşdirin

Adi virtual maşında adətən çıxış qaydası əsas interfeysdən POSTROUTING MASQUERADE olur. OpenVZ konteynerində görünən cihaz çox vaxt venet0 olur, yəni host tərəfindən idarə olunan virtual interfeys, marşrutlaşdırılmış NIC deyil, və MASQUERADE orada həmişə dərsliklərin fərz etdiyi kimi davranmır.

İşlək forma müştərilərin artıq çatdığı ünvana açıq tərcümədir və hər iki istiqamətdə yönləndirməyə icazə verilir. Server konfiqurasiyasından hovuzun dəyişdirilməsi ünvanın dəyişdirilməsi qədər vacibdir. Yapışdırmazdan əvvəl hər sətri oxuyun.

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

Yönləndirmə qaydaları olmadan tərcümə yenə baş verir və kernel yenə yönləndirməkdən imtina edir. Bu kombinasiya NAT qaydasındakı sayğaclar artarkən müştərinin heç nə almadığı çaşdırıcı vəziyyət yaradır. İki FORWARD sətri də eyni zəncirdəki hər hansı geniş drop qaydasından əvvəl durmalıdır. Sıra konfiqurasiyanın bir hissəsidir, tətbiq detalları deyil.

Qaydanı bir hovuz və bir interfeyslə məhdudlaşdırın

İkinci simptomun fərqli səbəbi var: nə mənbə, nə də çıxış məhdudiyyəti olan POSTROUTING qaydası. Belə bir qayda hostdan çıxan hər paketi yenidən yazır.

Orijinal mənbədən asılı olan xidmətlər sonra düzgün işləmir. Yerli proksi arxasındakı veb server cavab verməyi dayandıra bilər və onu yenidən başlatmaq heç nəyi dəyişmir, çünki qayda hələ də yoldadır. Hostun öz publik ünvanına göndərdiyi trafik də təsirlənir; buna görə nasazlıq firewall problemi deyil, DNS və ya sertifikat problemi kimi görünə bilər. Qayda demək olar ki, birinci simptomu düzəltmək üçün əlavə edilmişdi.

Həll uyğunluğu tunel hovuzuna və çıxış interfeysinə daraltmaq, sonra bir neçəsini əhatə etmək üçün tək qaydanı genişləndirmək əvəzinə hər hovuz üçün bir qayda əlavə etməkdir.

Qaydaları qalıcı edin və onlara başqa kimin sahib olduğunu öyrənin

Əl ilə əlavə edilmiş qaydalar yenidən başlatmada yox olur, ona görə onları iptables-save ilə saxlayın və ya quraşdırıldığı yerdə netfilter-persistent vasitəsilə idarə edin. Bərpanın OpenVPN başlamazdan əvvəl işlədiyini təsdiqləyin. Sonra hadisə zamanı boşluğu kəşf etmək əvəzinə bir dəfə qəsdən yenidən başladın.

Konteyner hostunda həmçinin qalıcılıq faylının yazıla bilən konteyner yaddaşında olduğunu və provayderin açılışda filtrləməni əvəz etmədiyini təsdiqləyin. Bəzi platformalar siyasəti konteynerdən kənarda idarə edir və orada yerli qaydalar ya nəzərə alınmır, ya da hostun öz qaydaları ilə toqquşur.

Sayğaclarla və bir tutulmuş axınla yoxlayın

Qoşulmuş müştəridən xarici xidmətin bildirdiyi publik ünvanı yoxlayın. Əgər o, serverin ünvanı ilə üst-üstə düşürsə, tərcümə işləyir; düşmürsə, paket başqa yolla çıxır və ya heç çıxmır. Sonra həm serverdə yerləşən xidməti, həm də publik internetdəki xidməti sınayın, çünki onlar eyni qayda dəstindən fərqli yollarla keçir.

Serverdə NAT və FORWARD qaydalarındakı paket sayğaclarını iptables -t nat -L -v -n ilə oxuyun və tutmada bir axını izləyin. Müştərinin ünvanı tutmada görünürsə və cavab gəlmirsə, boşluq qayıdış yolunda və ya provayder filtrləməsindədir, müştəri profilində deyil. Tutulan mənbəni qaydanın tərcümə etdiyi ünvanla müqayisə edin, çünki uyğunsuzluq başqa qaydanın əvvəl uyğunlaşdığını bildirir. Bir müşahidə edilən axın bir səhifə konfiqurasiya oxumaqdan çoxunu həll edir.

Hovuzu, tərcümə edilmiş ünvanı və interfeys adını dəyişiklik qeydində birlikdə saxlayın. Bir hovuz üçün düzgün olan qayda növbətini səhv tərcümə edir.