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. Тај квар се појављује одмах након што честитате себи на поправљеној рути.

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