Ограничете го правилото SNAT за OpenVPN пред да го скрши 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 погрешно го преведува следниот.