Пристапот до LAN преку OpenVPN е расипан? Проверете зони, рути и повратен пат

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

Кој филтер гледа пакет наменет за LAN

Пакетот адресиран на рутерот се троши локално; пакетот адресиран на хост зад него мора да се препрати, а ѕидовите за заштита ги оценуваат овие два случаи одделно. Затоа дозволата да се стигне до рутерот не кажува ништо за дозволата да се помине низ него. Фирмверот што ги крие своите множества правила сепак ги спроведува и двете, обично како избирач што нуди LAN, интернет или и двете. Ако избирачот го испушти LAN, ниедна подоцнежна проверка нема да биде важна.

OpenWrt ја прави поделбата прегледна и разликата вреди да се прочита еднаш. Зоната што го завршува тунелот бара правило за препраќање кон LAN зоната, додека влезното правило управува само со услугите на самиот рутер. Работна административна страница до мртов LAN е вообичаениот резултат од тоа правило за препраќање што недостига.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

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

Зошто разделен тунел бара туркање на префиксот

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

push "route 192.168.50.0 255.255.255.0"

Профилите што содржат route-nopull ги игнорираат турканите рути, затоа истиот префикс припаѓа на клиентската датотека. Во секој случај потврдете дека записот пристигнал наместо да претпоставувате, бидејќи тивкото пребришување изгледа исто како проблем со ѕид за заштита.

ip route show | grep 192.168.50

Партнер од локација до локација бара повеќе од туркање. Серверот мора да научи кои префикси стојат зад тој партнер, што го прави линија iroute во неговата датотека client-config-dir, а неговата сопствена табела бара соодветна рута во тунелот.

Одговорот бара адреса до која може да стигне

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

tcpdump -ni tun0 host 192.168.50.20

Изведете го ова на рутерот додека клиентот го повторува барањето и читајте го одредиштето на одговорот, а не самото барање. Одговор адресиран на базенот значи дека повратниот пат работи и дефектот е подлабоко. Целосно отсуство на одговор значи дека хостот никогаш не го прифатил пакетот, што ве враќа на множеството правила.

Скалило што завршува на вистинското место

Четири проверки го лоцираат слојот и секоја е една наредба, а не проценка. Изведете ги по ред и застанете на првиот неуспех. Редоследот е поважен од наредбите, бидејќи подоцнежен поминат чекор го крие причината зошто претходен не успеал.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Имињата припаѓаат на крајот од скалилото, никогаш на почетокот. Споделување што одговара како 192.168.50.20 но не како nas.local упатува на резолуција на имиња или на суфикс за пребарување, а измените на ѕидот за заштита не можат да го сменат ниту едното.

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