Зашто функционалан VPN ипак истекне на одговору
То што захтев стигне до приватног сервера је само половина размене. Његов одговор мора да пронађе клијента тунела кроз предвиђену капију, руту или превод.
Захтев стиже, сервер га забележи, а клијент и даље пријављује истек времена. Та комбинација значи да одговор није нашао пут назад, и то је једна од ретких кварова који можете потврдити са оба краја истовремено. Изведите провере по реду и зауставите се када нека од њих не прође.
Почните од места на које је захтев стигао
Пре него што прегледате било шта друго, потврдите да је пакет стигао до сервиса. Запис у дневнику на страни сервера, бројач веза или дозвољено снимање на далеком крају сви одговарају на исто питање, а њихово одсуство вас враћа ка тунелу, а не напред ка одговору. Ово је провера која одваја проблем прослеђивања од проблема повратног пута.
Ако захтев никада није стигао, зауставите се овде. Тунел, рутирање ка приватном префиксу или правило приступа су тема, а пут одговора још није релевантан. Забележите и изворну адресу коју је сервер видео. Она је или адреса из базена коју је клијент добио или преведена адреса, и та разлика одређује која од каснијих провера важи.
Одговору је потребна рута до базена
Клијент за даљински приступ обично добија адресу из базена, а приватна мрежа захтева руту назад до тог базена. Сервер чија подразумевана рута показује на његову сопствену капију предаје пакет тој капији, која појма нема где се базен налази, па одговор тамо умире. Клијент види истек времена јер се ништа није вратило, а то се не може разликовати од захтева који никада није изашао.
Проверите руту коју сервер бира за адресу клијента, а не руту коју користи за сопствену подмрежу. Та два претраживања могу дати различите одговоре, и овде је важан други. Превод је алтернативни дизајн и мења оно што сервер види. Може да поједностави повратни пут, а такође уклања оригиналну адресу клијента из дневника сервера, што утиче на свако правило или извештај изграђен на том пољу.
Упоредите снимање на серверу са снимањем на капији
Упоредите шта напушта сервер са оним што стиже на капију. Снимање на излазном интерфејсу сервера и снимање на капији тунела одговарају на различите половине питања, а јаз између њих лоцира губитак.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
Захтев који сама капија генерише слаба је замена за тест од клијента, јер потиче са друге адресе и сусреће друга правила. Зато успешан ping са капије и неуспешан захтев од клијента могу бити истинити истовремено.
Када на путу има више рутера, проверите сваки коме је потребна рута до базена. Дизајн од локације до локације често захтева да далеки префикс буде познат на више од једног уређаја, а сама капија мора да прослеђује између тунела и локалне мреже; белешке strongSwan о прослеђивању покривају страну sysctl и заштитног зида.
Забележите базен, префикс и одговорног
У белешку улазе четири чињенице: базен који је клијент добио, приватни префикс који му је био потребан, рутер одговоран за одговор и правило превода ако постоји. Са њима је каснија промена капије поређење, а не истрага.
Затим поново тестирајте са обичним клијентом и правим налогом апликације. Проширење привилегија апликације не може да поправи повратни пут пакета, а промена налога током ове дијагностике збуниће следеће поређење. Ако се дизајн ослања на превод, документујте га тамо где се читају дневници сервера. Онај ко у трагу ревизије види непознату изворну адресу не би требало поново да открива мапирање из тикета.