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 маршрутизаторунда өлөт. Серверден LAN хостко ping жасоо бул жол тууралуу эч нерсени далилдебейт, анткени ал трафик туннелден эч качан өтпөйт.

Төртүнчү кадам: трансляция менен кайтаруу маршрутунун ортосунда тандаңыз

Эки оңдоо тешикти жабат, жана тандоонун ping иштегенинен тышкаркы кесепеттери бар. Булакты трансляциялоо серверди көрүнгөн жиберүүчү кылат:

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

Эрежени пул жана LAN интерфейси менен чектеңиз, андан кийин аны туруктуу кылыңыз, болбосо кийинки брандмауэр кайра жүктөө сиздин оңдооңузду унчукпай жок кылат. Баасы — инсандык: ар бир кардар LAN журналдарында жана кирүү эрежелеринде VPN серверине окшош болуп көрүнөт, жана per-client policy becomes guesswork.

LAN маршрутизаторунда VPN серверине багытталган 10.8.0.0/24 үчүн статикалык маршрут кардарлардын даректерин көрүнүктүү кармап турат жана ошол маршрутизатор сиздики болсо, узак мөөнөттүү жакшыраак жооп. Көптөгөн аянтчалар бир аз убакыт экөөнү тең жүргүзөт: NAT шашылыш оңдоо үчүн жана брандмауэр саясаты жазылгандан кийин маршрут. Эгер сервер пул эмес, сайттан сайтка өнөктөш болсо, сервер тарабына алыскы кошумча тармак үчүн iroute да керек, болбосо өнөктөштүн маршруту бар, бирок кардар трафиги ага эч качан байланышпайт.

Бешинчи кадам: кардардан текшерип, эмне өзгөргөнүн жазыңыз

Циклди серверден эмес, кардардан жабыңыз. LAN хосттогу реалдуу кызматка туташыңыз, андан кийин трансляция эсептегичтери iptables -t nat -L POSTROUTING -v -n аркылуу жылганын ырастаңыз, анткени нөл пакеттүү эреже — эч качан дал келбеген эреже. Кайтаруу багыты көзөмөлдөнүп жатканына далил керек болгондо, conntrack -L -s 10.8.0.5 агымды жана анын абалын көрсөтөт.

Сервер конфигурациясында жазуу калтырыңыз: кайсы кошумча тармак, кайсы интерфейс, кайсы эреже жана LAN маршрутизаторунда кайтаруу маршруту барбы. Кийинки жолу кардар жаңыртуусу түртүлгөн маршрутту өчүргөндө, бул жазуу өрт өчүрүү сессиясын бир саптуу оңдоого айландырат.