OpenVPN са пуним тунелом: додајте интернет излаз на страни сервера

Клијент се аутентификује, добија адресу из базена и стиже до услуга на VPN домаћину, али свака јавна дестинација завршава истеком времена. Тако изгледа тунел без излаза и тако остаје док се не испуне четири одвојене ствари. Клијент мора да прихвати подразумевану руту, сервер мора да прослеђује, заштитни зид мора да дозволи пролаз, а одговорима је потребан пут назад до базена. Сва четири квара деле један симптом, зато мењајте по једну ставку по покушају и бележите резултат.

Гурните подразумевану руту и проверите шта је клијент инсталирао

Линија на страни сервера је кратка, и утиче само на клијенте који прихватају гурнуте опције. Форма def1 инсталира две полуподразумеване руте уместо да избрише постојећу подразумевану, што одржава тренутну везу живом и истовремено хвата сваку дестинацију.

push "redirect-gateway def1"

Након поновног повезивања прочитајте табелу рутирања клијента уместо да верујете профилу. На Linux-у два уноса /1 појављују се поред изворне подразумеване руте, а Windows приказује исти пар као 0.0.0.0/1 и 128.0.0.0/1. Клијент који игнорише гурнуте опције, или онај који је подешен да их одбије, задржава стару подразумевану руту и никада не шаље интернет саобраћај у тунел. Решите то питање пре него што било шта промените на серверу, јер ниједно правило на страни сервера не може то да надокнади.

Прослеђивање је подешавање сервера, не подешавање VPN-а

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

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

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

Дозволите тачно онај пролаз који желите, и ништа друго

Прослеђени пакети пролазе кроз путању forward; саобраћај упућен самом VPN домаћину пролази кроз input. То су различите одлуке, а отварање путање input не дозвољава пролаз кроз машину. Њихово мешање је најчешћи разлог зашто заштитни зид изгледа као да дозвољава све, а клијенти ипак добијају истек времена.

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

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Пребацивање сваког ланца на прихватање пушта тест да прође и уклања разлог постојања заштитног зида. Држите обухват на базену и излазном интерфејсу, а неповезано прослеђивање оставите на миру.

Дајте одговорима место где да иду

Адресе базена су приватне, па јавни сервер не може директно да им достави одговор. Или VPN домаћин преводи изворну адресу на излазу, или уређај изнад држи руту назад до базена.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Додајте тачно један слој превода. Други NAT изнад крије први и чини оба дневника скоро бескорисним када се касније нешто поквари. Ако рутер изнад већ рутира базен назад, додавање превода на домаћину је сувишно, а пут назад тада зависи од конфигурације тог рутера, а не од ваше.

Облачне инстанце додају још једна врата, јер неке платформе одбацују пакете чија изворна адреса није адреса инстанце, осим ако се та провера не ублажи. То подешавање стоји изван госта и лако се заборави када локална тест машина ради.

Докажите то са клијента, не из љуске сервера

Почните са бројчаним IPv4 захтевом, затим претрагом имена, затим апликацијом. ping доказује прослеђивање и превод;он не доказује ништа о разрешавању имена, јер DNS опције ступају на снагу само када их клијентска интеграција инсталира.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Бележите измене и корак враћања у току, да би излазна политика могла да се врати једном радњом када тест не успе. Овај рецепт покрива само IPv4; одвојено пописујте IPv6 пре него што тврдите да распоређивање носи сав саобраћај.