Јавни префикс кроз OpenVPN: поправити повратни пут

Посматрајте како се тунел подиже и клијент пингује другу страну, а затим јавна адреса која припада иза VPN-а одговара са другог места, или уопште не одговара. Овај симптом обично нема никакве везе са шифром или сертификатима. Префикс који рутира провајдер доставља се као IP рута, и његово преношење кроз OpenVPN значи репродуковати ту руту на два нивоа и сачувати изворну адресу на повратном путу. Није потребно премостити WAN, и додавање адресе на интерфејс не ствара горњу руту.

Префикс прво мора бити рутиран ка вама

Питајте провајдера како се блок доставља. Префикс рутиран на главну адресу вашег сервера је нешто друго од адреса које провајдер очекује да достигне директно на WAN сегменту. Само први модел ради са дизајном овде.

Ако провајдер рутира 198.51.100.64/28 на ваш улазни сервер, пакети за тај опсег стижу на сервер и заустављају се тамо, осим ако их прослеђујете. Ако провајдер уместо тога премости опсег на ваш uplink, сервер мора да одговори ARP-ом за њега, што је други проблем.

Тестирајте модел достављања пре него што дотакнете OpenVPN: споља пингујте адресу у блоку и видите који интерфејс је прима. Ако ништа не стигне, никаква конфигурација тунела не помаже. Ако адреса одговара директно на WAN-у, провајдер премошћује уместо да рутира, и дизајн испод се не примењује.

Два нивоа рутирања: рута у језгру и iroute

OpenVPN-у је потребан префикс на два места. Језгро мора да зна да префикс припада тунелском уређају, да би прослеђени пакети ушли у OpenVPN уместо у подразумевану руту. OpenVPN такође мора да зна који аутентификовани клијент поседује префикс, а то је iroute запис у директоријуму специфичном за клијента.

Рута на страни сервера изгледа овако, при чему префикс и маска морају да одговарају додели:

ip route add 198.51.100.64/28 dev tun0

Конфигурација специфична за клијента додељује власништво. Ставите је у CCD датотеку названу по заједничком имену клијентског сертификата, и потврдите да сервер заиста чита тај директоријум:

iroute 198.51.100.64 255.255.255.240

Документација OpenVPN-а о рутираним мрежама описује оба нивоа и зашто су одвојени. Рута у језгру без iroute шаље пакете у тунел без власника, и OpenVPN их одбацује. iroute без руте у језгру оставља пакете на подразумеваној путањи сервера. Обе грешке изгледају са клијентске стране као покварен тунел.

Где живи адреса услуге

Делегирани префикс није исто што и сопствене адресе тунела. Нумеришите везу из приватног простора ако желите, и поставите јавну адресу услуге тамо где услуга заиста ради.

На Linux клијенту који услугу завршава локално, довољна је једна адреса хоста:

ip address add 198.51.100.70/32 dev lo

Ако се префикс рутира даље на VM хост или другу LAN, конфигуришите уместо тога ту низводну путању и њену повратну руту. Додељивање сваке адресе у блоку VPN клијенту није потребно и касније ствара конфликте.

Сачувајте јавни извор на повратном путу

Одговор из делегираног префикса мора да изађе кроз тунел и стигне до руте провајдера. Ако удаљени хост шаље га преко сопственог ISP-а, изворна адреса изгледа лажно, и провајдер или одредиште га одбацују. Решење је правило засновано на извору или посебна табела рутирања, а не шири NAT. Без њега услуга ради од партнера у тунелу и не успева са сваког другог места.

На улазном серверу широко masquerade правило је уобичајени кривац. Оно преписује јавни извор на главну адресу сервера, и клијент никада не види прави:

iptables -t nat -S POSTROUTING

Ограничите NAT на приватне VPN клијенте којима је потребан и оставите делегирани префикс непреведен. Затим потврдите да сервер уопште прослеђује префикс, јер ланац прослеђивања са подразумеваном забраном га тихо одбацује.

Проверите оба смера пре него што му верујете

Провера је четири запажања, не једно. Потврдите да рута провајдера стиже, језгро шаље префикс у тунел, OpenVPN га приписује правом клијенту, и одговор се враћа са нетакнутим јавним извором. Свако запажање има своју команду, тако да неуспех указује на слој, а не на цео дизајн. Покрените их тим редом после сваке промене конфигурације.

Питајте језгро којом путањом иде делегирана адреса, и посматрајте тунел док захтев траје:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Филтрирање повратне путање може да поништи исправну руту. Проверите ефективну поставку на тунелу и на uplink-у, и запамтите да строги режим одбија саобраћај чији извор не одговара интерфејсу на који је стигао:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

На крају, тестирајте случај отказа. Зауставите тунел и потврдите да јавни префикс не цури кроз обичан uplink. Враћање VPN-а треба да врати услугу без проширивања портова које хост отвара.