Две неисправности стално долазе са исте врсте хоста. У првој се клијенти аутентификују и затим не достижу ништа изван тунела. У другој се 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 погрешно преводи следећи.

Повезани чланци