OpenVPN клиентот стигнува до серверот, но не до LAN домаќините: контролна листа

Клиентот вели дека е поврзан, адресата на тунелот одговара на ping, а ништо на канцелариската LAN мрежа не одговара. Ова го гледам по речиси секое ажурирање на клиентот, и првиот инстинкт е да се отвори огнениот ѕид, што обично е погрешен чекор: тунелот е во ред, а прекинот е на еден од трите скока што пакетот мора да ги помине. Поминете го патот по редоследот по кој оди пакетот, прво рутата на клиентот, потоа препраќањето на серверот, потоа враќањето, и ќе го најдете сопственикот на дефектот за неколку минути.

Прв чекор: следете ја одлуката за рутирање на клиентот

Пред да го допрете серверот, докажете дека клиентот го праќа пакетот во тунелот. Прашајте го јадрото кој интерфејс би го користел за еден конкретен LAN домаќин, наместо да ја читате целата табела:

ip route get 192.168.50.10

Ако одговорот го наведе вашиот физички адаптер и канцелариската порта, никаква промена на страната на серверот не може да помогне. OpenVPN дели рути само кога серверот ги турка, затоа побарајте push "route 192.168.50.0 255.255.255.0" во конфигурацијата на серверот и потоа повторно поврзете го клиентот. Повеќето клиенти ги применуваат турканите рути при поврзување, не кога го вчитувате профилот повторно.

На Windows истото прашање има друга команда. Find-NetRoute -RemoteIPAddress 192.168.50.10 го печати интерфејсот и следниот скок што би го избрал стекот, а route print -4 покажува дали турканиот префикс воопшто постои.

Втор чекор: потврдете дека серверот ќе го препрати пакетот

Ако рутата на клиентот е точна, пакетот стигнува до серверот и серверот мора да се согласи да го препрати. Прекинувачот на јадрото е првата порта, и sysctl net.ipv4.ip_forward мора да врати 1. Поставувањето со echo 1 > /proc/sys/net/ipv4/ip_forward работи до следното рестартирање, и токму затоа истата жалба се враќа по неколку недели.

Запишете го некаде каде што преживува рестартирање:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Втората порта е табелата за филтрирање. Домаќин со инсталиран Docker често носи FORWARD политика со вредност DROP, и тунелот ја наследува таа одлука. iptables -L FORWARD -v -n ја покажува и политиката и бројачите на пакети; ако политиката е DROP, препраќањето бара изречна дозвола за насоката од тунелот кон LAN и уште една за одговорот.

Трет чекор: следете го пакетот до LAN и побарајте одговор

Гледајте ги двете страни на серверот истовремено. Снимајте на тунелот и на LAN интерфејсот, филтрирано на еден клиент и еден домаќин за излезот да остане читлив:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Барањата што се појавуваат на tun0 и повторно на eth0 со извор 10.8.0.x, по што следи тишина, значат дека пакетот стигнал, а одговорот отишол на друго место. LAN домаќинот одговара на својата стандардна порта, таа порта нема рута за VPN базенот, и одговорот умира на LAN рутерот. Ping до LAN домаќинот од серверот не докажува ништо за овој пат, зашто тој сообраќај никогаш не го поминува тунелот.

Четврт чекор: изберете меѓу превод и повратна рута

Две поправки ја затвораат дупката, и изборот има последици надвор од тоа дали ping работи. Преводот на изворот го прави серверот очигледен испраќач:

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

Ограничете го правилото на базенот и на LAN интерфејсот, потоа направете го трајно, инаку следното вчитување на огнениот ѕид тивко ќе ја отстрани вашата поправка. Цената е идентитет: секој клиент изгледа како VPN серверот во LAN дневниците и правилата за пристап, и per-client policy becomes guesswork.

Статична рута за 10.8.0.0/24 на LAN рутерот, насочена кон VPN серверот, ги држи адресите на клиентите видливи и е подобар долгорочен одговор кога тој рутер е ваш. Многу локации извесно време ги возат двете, NAT за итната поправка и рутата штом политиката на огнениот ѕид е напишана. Ако серверот е site-to-site партнер, а не базен, страната на серверот исто така бара iroute за далечната подмрежа, инаку партнерската рута постои, но сообраќајот на клиентите никогаш не се поврзува со неа.

Петти чекор: проверете од клиентот и запишете што се промени

Затворете ја јамката од клиентот, не од серверот. Поврзете се со вистинска услуга на LAN домаќинот, потоа потврдете дека бројачите на преводот се поместиле со iptables -t nat -L POSTROUTING -v -n, зашто правило со нула пакети е правило што никогаш не се совпаднало. conntrack -L -s 10.8.0.5 ја покажува струјата и нејзината состојба кога ви треба доказ дека повратната насока се следи.

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