Kufizoni rregullin SNAT të OpenVPN përpara se të thyejë nginx

Dy dështime vijnë gjithmonë nga i njëjti lloj hosti. Në të parën, klientët autentikohen dhe më pas nuk arrijnë asgjë përtej tunelit. Në të dytën, VPN ngrihet dhe faqja e vetë serverit ndalon së përgjigjuri, e cila është më alarmante sepse duket si dëmtim kolateral. Në një VPS të bazuar në kontejnerë, të dyja zakonisht kthehen në të njëjtën listë të shkurtër kontrollesh, dhe rendi ka rëndësi: së pari pajisja, pastaj përkthimi, në fund fushëveprimi.

Konfirmoni se kontejneri mund të krijojë një pajisje tun

Asgjë tjetër nuk ka rëndësi nëse ndërfaqja e tunelit nuk mund të ekzistojë. Kontrolloni që /dev/net/tun është i pranishëm dhe që krijimi i një pajisjeje testuese ka sukses, sepse shumë ofrues e çaktivizojnë tun brenda kontejnerëve si parazgjedhje. Asnjë punë me firewall nuk kompenson një pajisje që nuk u krijua kurrë.

Nëse pajisja mungon, vetëm hosti ose ofruesi mund ta aktivizojnë. Një plan tjetër është shpesh më i lirë se një temë e hapur mbështetjeje që zgjat një javë. Konfirmojeni këtë përpara se të lexoni edhe një rresht të logut të OpenVPN. Përndryshe do ta kaloni mbrëmjen duke rregulluar rregulla që nuk do të shohin kurrë një paketë.

Vendosni çfarë bën MASQUERADE në këtë ndërfaqe

Në një makinë virtuale të zakonshme rregulli i zakonshëm i daljes është POSTROUTING MASQUERADE nga ndërfaqja kryesore. Në një kontejner OpenVZ pajisja e dukshme është shpesh venet0, një ndërfaqe virtuale e administruar nga hosti dhe jo një kartë rrjeti e rutuar, dhe MASQUERADE nuk sillet gjithmonë atje siç supozojnë tutorialet.

Forma e zbatueshme është një përkthim i qartë drejt adresës që klientët arrijnë tashmë, me përcjelljen e lejuar në të dy drejtimet. Zëvendësimi i pool nga konfigurimi i serverit ka po aq rëndësi sa zëvendësimi i adresës. Lexoni çdo rresht përpara se ta ngjitni.

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

Pa rregullat e përcjelljes përkthimi ndodh gjithsesi dhe kerneli vazhdon të refuzojë përcjelljen. Ky kombinim prodhon gjendjen konfuze ku numëruesit në rregullin NAT rriten ndërsa klienti nuk merr asgjë. Të dy rreshtat FORWARD duhet gjithashtu të qëndrojnë përpara çdo rregulli drop të gjerë në të njëjtin zinxhir. Rendi është pjesë e konfigurimit, jo detaj implementimi.

Kufizoni rregullin në një pool dhe një ndërfaqe

Simptoma e dytë ka një shkak tjetër: një rregull POSTROUTING pa kufizim burimi dhe pa kufizim daljeje. Një rregull i tillë rishkruan çdo paketë që lë hostin.

Shërbimet që varen nga burimi origjinal sillen atëherë gabimisht. Një server web pas një proxy lokal mund të ndalojë së përgjigjuri, dhe rindezja nuk ndryshon asgjë sepse rregulli është ende në rrugë. Preket edhe trafiku që hosti dërgon në adresën e vet publike, prandaj dështimi mund të duket si problem DNS ose certifikate dhe jo firewall. Rregulli pothuajse me siguri u shtua për të rregulluar simptomën e parë.

Zgjidhja është të ngushtohet përputhja në pool-in e tunelit dhe në ndërfaqen e daljes, pastaj të shtohet një rregull për çdo pool në vend që një rregull të zgjerohet për të mbuluar disa.

Bëjini rregullat të përhershme dhe zbuloni kush tjetër i zotëron

Rregullat e shtuara me dorë zhduken në rindezje, prandaj ruajini me iptables-save ose administrojini përmes netfilter-persistent aty ku është i instaluar. Konfirmoni që rikthimi ekzekutohet përpara se OpenVPN të nisë. Pastaj rindizni një herë me qëllim në vend që ta zbuloni boshllëkun gjatë një incidenti.

Në një host kontejnerësh, konfirmoni gjithashtu se skedari i këmbënguljes ndodhet në ruajtje kontejneri të shkrueshme dhe se ofruesi nuk e zëvendëson filtrimin në nisje. Disa platforma e administrojnë politikën jashtë kontejnerit, ku rregullat lokale ose injorohen ose përplasen me ato të vetë hostit.

Verifikoni me numërues dhe një rrjedhë të kapur

Nga një klient i lidhur, kontrolloni adresën publike që raporton një shërbim i jashtëm. Nëse përputhet me adresën e serverit, përkthimi funksionon; nëse jo, paketa del nga një rrugë tjetër ose nuk del fare. Më pas provoni si një shërbim të strehuar në server ashtu edhe një në internetin publik, sepse ndjekin rrugë të ndryshme përmes të njëjtit grup rregullash.

Në server, lexoni numëruesit e paketave në rregullat NAT dhe FORWARD me iptables -t nat -L -v -n dhe vëzhgoni një rrjedhë në një kapje. Nëse adresa e klientit shfaqet në kapje dhe nuk vjen asnjë përgjigje, boshllëku është në rrugën e kthimit ose në filtrimin e ofruesit, jo në profilin e klientit. Krahasoni burimin e kapur me adresën në të cilën përkthen rregulli, sepse mospërputhja do të thotë që një rregull tjetër përputhej i pari. Një rrjedhë e vëzhguar zgjidh më shumë se një faqe lexim konfigurimi.

Mbani pool-in, adresën e përkthyer dhe emrin e ndërfaqes bashkë në regjistrin e ndryshimeve. Një rregull i saktë për një pool e përkthen gabimisht tjetrin.