VPN клиентите стигнуваат до серверот, но не до LAN мрежата: кое решение?

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

Најпрво утврдете кој правец е расипан

Барањето доаѓа на интерфејсот на тунелот со изворна адреса од VPN базенот. Серверот го препраќа до домаќинот во LAN мрежата, а тој домаќин одговара на портата што ја наведува неговата сопствена табела, обично рутерот на LAN мрежата. Ако рутерот нема рута кон базенот, одговорот таму умира или талка кон интернетот.

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Ако домаќинот во LAN мрежата веќе покажува на VPN серверот, проблемот е правило на огнениот ѕид или ограничување на MTU, а не недостигачка повратна патека. Не додавајте рута за да поправите филтер.

Прво прашање: можете ли да го уредувате рутерот на далечната LAN мрежа?

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

Тивко откажува оној ден кога некој ќе го смени базенот. Запишете ја вредноста еднаш и третирајте промена на кое било од трите места како промена на сите три.

NAS или Layer 3 преклопник што ја хостира услугата бара истата рута, освен ако сето не го испраќа низ рутер што ја има. Проверете го уредот што ја завршува подмрежата, не само оној свртен кон интернетот. Малите мрежи често имаат три уреди со мислење за рутирањето.

Второ прашање: може ли LAN мрежата да престане да ги гледа адресите на клиентите?

Кога рутерот припаѓа на некој друг, преведувањето на VPN серверот не бара соработка. Домаќинот во LAN мрежата ја гледа адресата на LAN мрежата на серверот, одговара на неа, а серверот преведува назад. Затоа уредите и улогите за далечински пристап базирани на NAT се однесуваат така.

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

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

Изберете преведување кога соработката не е достапна, а не кога е само незгодна. Го крие клиентот од секоја идна истрага, вклучително и оние каде што треба да знаете кој преносен компјутер отворил врска. Може да ги расипе и протоколите што вградуваат адреси во корисниот товар, бидејќи преведувањето живее во заглавието. Ниту една можност не е понапредна; тие одговараат на различни прашања за сопственоста.

Трето прашање: дали серверот самиот е клиент на друг тунел?

Замислете ја другата топологија: VPN серверот исто така ѕвони кај комерцијален провајдер, па има два тунела и две групи адреси. Сообраќајот што го препраќа за сопствените клиенти излегува низ провајдерот, а тој нема да ги насочи одговорите назад кон адресите на базенот. Затоа одговорите исчезнуваат иако двата тунели се здрави.

Решението е да се маскира и излезниот тунел, за провајдерот да ја гледа само адресата на тунелот на серверот. Спротивниот правец бара сопствено правило, бидејќи серверот што отвора врска кон сопствен клиент е друг тек. Без тоа правило клиентот одговара на адреса што не може да ја насочи. Поставете го тесното правило пред секое широко маскирање за да победи конкретниот превод.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Домаќините со повеќе интерфејси додаваат сроден дефект што од страната на клиентот изгледа исто. Одговорот излегува низ интерфејсот со пониска метрика бидејќи изворната адреса е избрана од друга табела. Проверете ја повратната патека со пребарување наместо да претпоставувате дека патеката напред ја подразбира.

Потоа проверете ги двата правци и двете големини

По промената пингнете од клиентот до домаќин во LAN мрежата, а потоа од домаќинот во LAN мрежата до клиентот. Вториот правец е оној што луѓето го прескокнуваат, и тој го открива нецелосното правило за преведување. Забележете ги двата резултати со временска ознака за да биде подоцнежната регресија споредлива.

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

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