Чаму працоўны 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 і файрвола.
Запішыце пул, прэфікс і ўладальніка
У нататку ўваходзяць чатыры факты: пул, які атрымаў кліент, патрэбны яму прыватны прэфікс, маршрутызатар, адказны за адказ, і правіла трансляцыі, калі яно ёсць. З імі наступная змена шлюза — гэта параўнанне, а не расследаванне.
Затым паўтарыце тэст са звычайным кліентам і рэальным уліковым запісам праграмы. Пашырэнне правоў праграмы не можа выправіць зваротны шлях пакета, а змена ўліковага запісу падчас гэтай дыягностыкі заблытае наступнае параўнанне. Калі схема абапіраецца на трансляцыю, апішыце яе там, дзе чытаюць журналы сервера. Чалавек, які бачыць незнаёмы адрас крыніцы ў журнале аўдыту, не павінен нанава выяўляць адпаведнасць з тыкета.