Ograničite OpenVPN SNAT pravilo prije nego što pokvari nginx

Dvije vrste kvarova stalno dolaze s iste vrste hosta. U prvom se klijenti autentificiraju i zatim ne dosegnu ništa izvan tunela. U drugom se VPN podigne i vlastita web stranica servera prestane odgovarati, što je alarmantnije jer izgleda kao kolateralna šteta. Na VPS-u temeljenom na kontejneru oba se obično svode na isti kratki popis provjera, a redoslijed je važan: prvo uređaj, drugo prevođenje, treće opseg.

Provjerite može li kontejner stvoriti tun uređaj

Ništa drugo nije važno ako tunelno sučelje ne može postojati. Provjerite da /dev/net/tun postoji i da stvaranje testnog uređaja uspijeva, jer mnogi pružatelji prema zadanim postavkama isključuju tun unutar kontejnera. Nikakav rad na firewallu ne nadoknađuje uređaj koji nikada nije stvoren.

Ako uređaj nedostaje, samo ga host ili pružatelj mogu omogućiti. Drugi plan je često jeftiniji od otvorene teme podrške koja traje tjedan. Potvrdite to prije nego što pročitate i jedan redak OpenVPN zapisa. Inače provedete večer podešavajući pravila koja nikada neće vidjeti paket.

Odredite što MASQUERADE radi na ovom sučelju

Na običnom virtualnom stroju uobičajeno pravilo izlaza je POSTROUTING MASQUERADE iz glavnog sučelja. U OpenVZ kontejneru vidljivi uređaj je često venet0, virtualno sučelje kojim upravlja host, a ne usmjerena mrežna kartica, i MASQUERADE se tamo ne ponaša uvijek kako vodiči pretpostavljaju.

Izvediv oblik je izričito prevođenje na adresu koju klijenti već dosežu, uz dopušteno prosljeđivanje u oba smjera. Zamjena poola iz konfiguracije servera jednako je važna kao i zamjena adrese. Pročitajte svaki redak prije lijepljenja.

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 pravila prosljeđivanja prevođenje se i dalje događa, a kernel i dalje odbija prosljeđivati. Ta kombinacija stvara zbunjujuće stanje u kojem brojači na NAT pravilu rastu dok klijent ne prima ništa. Dva FORWARD retka također moraju stajati prije bilo kojeg širokog drop pravila u istom lancu. Redoslijed je dio konfiguracije, a ne pojedinost implementacije.

Ograničite pravilo na jedan pool i jedno sučelje

Drugi simptom ima drugi uzrok: POSTROUTING pravilo bez ograničenja izvora i bez ograničenja izlaza. Takvo pravilo prepisuje svaki paket koji napušta host.

Usluge koje ovise o izvornom izvoru zatim se ponašaju pogrešno. Web poslužitelj iza lokalnog proxyja može prestati odgovarati, a ponovno pokretanje ništa ne mijenja jer je pravilo još uvijek na putu. Promet koji host šalje na vlastitu javnu adresu također je pogođen, zato kvar može izgledati kao problem s DNS-om ili certifikatom, a ne s firewallom. Pravilo je gotovo sigurno dodano da popravi prvi simptom.

Rješenje je suziti podudaranje na tunelni pool i izlazno sučelje, pa dodati jedno pravilo po poolu umjesto širenja jednog pravila na nekoliko.

Učinite pravila trajnima i otkrijte koga još posjeduje

Ručno dodana pravila nestaju pri ponovnom pokretanju, pa ih spremite s iptables-save ili njima upravljajte kroz netfilter-persistent gdje je instaliran. Potvrdite da se vraćanje izvodi prije nego što OpenVPN krene. Zatim jednom namjerno ponovno pokrenite sustav umjesto da prazninu otkrijete tijekom incidenta.

Na hostu s kontejnerima također potvrdite da datoteka trajnosti živi u zapisivom spremištu kontejnera i da pružatelj ne zamjenjuje filtriranje pri podizanju. Neke platforme upravljaju politikom izvan kontejnera, gdje se lokalna pravila ili ignoriraju ili se bore s vlastitima hosta.

Provjerite brojačima i jednim snimljenim tokom

S povezanog klijenta provjerite javnu adresu koju prijavljuje vanjska usluga. Ako se podudara s adresom servera, prevođenje radi; ako ne, paket izlazi drugim putem ili uopće ne izlazi. Zatim isprobajte i uslugu hostanu na serveru i onu na javnom internetu, jer one idu različitim putevima kroz isti skup pravila.

Na serveru čitajte brojače paketa na NAT i FORWARD pravilima s iptables -t nat -L -v -n i promatrajte jedan tok u snimci. Ako se adresa klijenta pojavi u snimci i odgovor ne uslijedi, praznina je na povratnom putu ili u filtriranju pružatelja, a ne u profilu klijenta. Usporedite snimljeni izvor s adresom na koju pravilo prevodi, jer nesklad znači da se prvo podudarilo drugo pravilo. Jedan promatrani tok rješava više od stranice čitanja konfiguracije.

Držite pool, prevedenu adresu i naziv sučelja zajedno u zapisu promjena. Pravilo ispravno za jedan pool pogrešno prevodi sljedeći.