Ограничете правилото SNAT за OpenVPN, преди да счупи nginx

Клиентите се удостоверяват, но нищо не се маршрутизира, или сайтът умира след вдигане на VPN. Проверете достъпа до tun, после ограничете транслацията до пула и един интерфейс.

Две повреди идват от един и същ тип хост. При първата клиентите се удостоверяват и после не достигат нищо извън тунела. При втората VPN се вдига и собственият сайт на сървъра спира да отговаря, което е по-тревожното, защото изглежда като странична щета. На VPS, базиран на контейнер, и двете обикновено се свеждат до един кратък списък проверки и редът е важен: първо устройството, второ транслацията, трето обхватът.

Потвърдете, че контейнерът може да създаде tun устройство

Нищо друго няма значение, ако тунелният интерфейс не може да съществува. Проверете дали /dev/net/tun присъства и дали създаването на тестово устройство успява, защото много доставчици изключват tun в контейнерите по подразбиране. Никаква работа по firewall не компенсира устройство, което никога не е създадено.

Ако устройството липсва, само хостът или доставчикът могат да го включат. Друг план често е по-евтин от отворена тема в поддръжката, която трае седмица. Потвърдете това, преди да прочетете дори един ред от лога на OpenVPN. Иначе прекарвате вечерта в настройка на правила, които никога няма да видят пакет.

Решете какво прави MASQUERADE на този интерфейс

На обикновена виртуална машина обичайното правило за изход е POSTROUTING MASQUERADE от основния интерфейс. В контейнер OpenVZ видимото устройство често е venet0, тоест виртуален интерфейс, управляван от хоста, а не маршрутизирана мрежова карта, и MASQUERADE там не винаги се държи така, както предполагат уроците.

Работещата форма е явна транслация към адреса, който клиентите вече достигат, с разрешено препращане в двете посоки. Замяната на пула от конфигурацията на сървъра е също толкова важна, колкото замяната на адреса. Прочетете всеки ред, преди да го поставите.

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 в същата верига. Редът е част от конфигурацията, а не детайл на реализацията.

Ограничете правилото до един пул и един интерфейс

Вторият симптом има друга причина: правило POSTROUTING без ограничение по източник и без ограничение по изход. Такова правило пренаписва всеки пакет, който напуска хоста.

Услугите, които зависят от оригиналния източник, после се държат неправилно. Уеб сървър зад локален прокси може да спре да отговаря и рестартирането не променя нищо, защото правилото е все още по пътя. Трафикът, който хостът изпраща към собствения си публичен адрес, също е засегнат, затова повредата може да изглежда като проблем с DNS или сертификат, а не с firewall. Правилото почти сигурно е добавено, за да оправи първия симптом.

Решението е съвпадението да се стесни до пула на тунела и изходния интерфейс, после да се добави по едно правило на пул, вместо едно правило да се разширява за няколко.

Направете правилата постоянни и разберете кой друг ги притежава

Добавените на ръка правила изчезват при рестарт, затова ги запазете с iptables-save или ги управлявайте чрез netfilter-persistent там, където е инсталиран. Потвърдете, че възстановяването се изпълнява преди стартирането на OpenVPN. После рестартирайте веднъж нарочно, вместо да откриете пропуска по време на инцидент.

На хост с контейнери също потвърдете, че файлът за постоянство е в записваемо хранилище на контейнера и че доставчикът не подменя филтрирането при зареждане. Някои платформи управляват политика извън контейнера, където локалните правила или се игнорират, или се борят със собствените правила на хоста.

Проверете с броячи и един уловен поток

От свързан клиент проверете публичния адрес, който съобщава външна услуга. Ако съвпада с адреса на сървъра, транслацията работи; ако не, пакетът излиза по друг път или не излиза въобще. После изпробвайте и услуга, хоствана на сървъра, и такава в публичния интернет, защото те минават по различни пътища през един и същ набор правила.

На сървъра четете броячите на пакетите по правилата NAT и FORWARD с iptables -t nat -L -v -n и наблюдавайте един поток в запис. Ако адресът на клиента се появи в записа и не последва отговор, пропускът е по обратния път или във филтрирането на доставчика, а не в профила на клиента. Сравнете уловения източник с адреса, към който транслацията води, защото несъвпадението значи, че първо е съвпаднало друго правило. Един наблюдаван поток решава повече от страница четене на конфигурация.

Дръжте пула, транслатирания адрес и името на интерфейса заедно в записа за промени. Правило, което е правилно за един пул, транслира грешно следващия.

Подобни статии