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 отделно, преди да твърдите, че внедряването носи целия трафик.

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