OpenVPN клијент стиже до сервера, али не до LAN домаћина: контролна листа

Тунел је активан и сервер одговара, али LAN домаћини ћуте. Пратите пакет од руте клијента до повратног пута, а затим изаберите NAT или статичку руту.

Клијент каже да је повезан, адреса тунела одговара на 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 рутеру. Пинговање 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 рутер носи повратну руту. Следећи пут када ажурирање клијента избрише гурнуту руту, та белешка претвара сесију гашења пожара у поправку од једне линије.

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