Ierobežojiet OpenVPN SNAT kārtulu, pirms tā salauž nginx

Divi bojājumi pastāvīgi nāk no viena tipa resursdatora. Pirmajā klienti autentificējas un pēc tam nekur aiz tuneļa nenokļūst. Otrajā VPN paceļas un paša servera vietne pārstāj atbildēt, kas ir satraucošāk, jo izskatās pēc blakus bojājumiem. Uz konteineru balstītā VPS abi parasti atgriežas pie tā paša īsā pārbaužu saraksta, un secība ir svarīga: vispirms ierīce, otrkārt tulkojums, treškārt apjoms.

Pārliecinieties, ka konteiners var izveidot tun ierīci

Nekas cits nav svarīgs, ja tuneļa saskarne nevar pastāvēt. Pārbaudiet, vai /dev/net/tun pastāv un vai testa ierīces izveide izdodas, jo daudzi pakalpojumu sniedzēji pēc noklusējuma konteineros izslēdz tun. Nekāds firewall darbs nekompensē ierīci, kas nekad nav izveidota.

Ja ierīces nav, to var iespējot tikai resursdators vai pakalpojumu sniedzējs. Cits plāns bieži ir lētāks par nedēļu ilgu atvērtu atbalsta sarunu. Apstipriniet to pirms jebkuras OpenVPN žurnāla rindas lasīšanas. Pretējā gadījumā vakaru pavadīsiet, regulējot kārtulas, kas nekad neredzēs paketi.

Izlemiet, ko MASQUERADE dara šajā saskarnē

Parastā virtuālajā mašīnā parastā izejas kārtula ir POSTROUTING MASQUERADE no galvenās saskarnes. OpenVZ konteinerā redzamā ierīce bieži ir venet0, resursdatora pārvaldīta virtuāla saskarne, nevis maršrutēta tīkla karte, un MASQUERADE tur ne vienmēr uzvedas tā, kā pieņem apmācības.

Darboties spējīgā forma ir skaidrs tulkojums uz adresi, ko klienti jau sasniedz, ar atļautu pārsūtīšanu abos virzienos. Pool aizstāšana servera konfigurācijā ir tikpat svarīga kā adreses aizstāšana. Izlasiet katru rindu pirms ielīmēšanas.

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

Bez pārsūtīšanas kārtulām tulkojums joprojām notiek un kodols joprojām atsakās pārsūtīt. Šī kombinācija rada mulsinošu stāvokli, kurā NAT kārtulas skaitītāji aug, kamēr klients neko nesaņem. Abām FORWARD rindām arī jāatrodas pirms jebkuras plašas drop kārtulas tajā pašā ķēdē. Secība ir konfigurācijas daļa, nevis ieviešanas detaļa.

Ierobežojiet kārtulu ar vienu pool un vienu saskarni

Otrajam simptomam ir cits cēlonis: POSTROUTING kārtula bez avota un bez izejas ierobežojuma. Šāda kārtula pārraksta katru paketi, kas atstāj resursdatoru.

Pakalpojumi, kas atkarīgi no sākotnējā avota, pēc tam uzvedas nepareizi. Tīmekļa serveris aiz vietējā starpniekservera var pārstāt atbildēt, un tā restartēšana neko nemaina, jo kārtula joprojām ir ceļā. Tiek ietekmēta arī plūsma, ko resursdators sūta uz savu publisko adresi, tāpēc bojājums var izskatīties kā DNS vai sertifikāta problēma, nevis firewall. Kārtula gandrīz noteikti tika pievienota pirmā simptoma labošanai.

Risinājums ir sašaurināt atbilstību uz tuneļa pool un izejas saskarni, pēc tam pievienot vienu kārtulu katram pool, nevis paplašināt vienu kārtulu vairāku aptveršanai.

Padariet kārtulas noturīgas un noskaidrojiet, kam vēl tās pieder

Ar roku pievienotās kārtulas pēc pārstartēšanas pazūd, tāpēc saglabājiet tās ar iptables-save vai pārvaldiet tās ar netfilter-persistent tur, kur tas ir instalēts. Apstipriniet, ka atjaunošana notiek pirms OpenVPN starta. Pēc tam vienu reizi apzināti pārstartējiet, nevis atklājiet plaisu incidenta laikā.

Uz konteineru resursdatora arī apstipriniet, ka noturības fails atrodas rakstāmā konteinera krātuvē un ka pakalpojumu sniedzējs startēšanas laikā neaizstāj filtrēšanu. Dažas platformas pārvalda politiku ārpus konteinera, kur vietējās kārtulas vai nu tiek ignorētas, vai konfliktē ar paša resursdatora kārtulām.

Pārbaudiet ar skaitītājiem un vienu ierakstītu plūsmu

No savienota klienta pārbaudiet publisko adresi, ko ziņo ārējs pakalpojums. Ja tā sakrīt ar servera adresi, tulkojums darbojas; ja ne, pakete iziet pa citu ceļu vai neiziet vispār. Pēc tam izmēģiniet gan serverī mitinātu pakalpojumu, gan vienu publiskajā internetā, jo tie iet dažādus ceļus caur vienu un to pašu kārtulu kopu.

Serverī lasiet pakešu skaitītājus NAT un FORWARD kārtulās ar iptables -t nat -L -v -n un vērojiet vienu plūsmu ierakstā. Ja klienta adrese parādās ierakstā un atbilde neseko, plaisa ir atgriešanās ceļā vai pakalpojumu sniedzēja filtrēšanā, nevis klienta profilā. Salīdziniet ierakstīto avotu ar adresi, uz kuru kārtula tulko, jo neatbilstība nozīmē, ka vispirms atbilda cita kārtula. Viena novērota plūsma izšķir vairāk nekā viena konfigurācijas lasīšanas lapa.

Turiet pool, tulkoto adresi un saskarnes nosaukumu kopā izmaiņu žurnālā. Kārtula, kas pareiza vienam pool, nepareizi tulko nākamo.