VPN падключаецца, але прылады LAN недасяжныя: што праверыць

Трафік уваходзіць у тунель, шлюз адказвае на ўласны адрас, а за ім нішто не адказвае. Гэтая карціна звычайная і не з’яўляецца супярэчнасцю: адказ ад шлюза даказвае, што тунель завяршыўся, і нічога не даказвае пра тое, што адбываецца з пакетам, адрасаваным за яго межамі. Два тэсты задзейнічаюць розныя шляхі кода на адной машыне.

З гэтага моманту правярайце нешта па той бок шлюза. Уласны адрас шлюза будзе адказваць, наколькі б ні была зламаная перасылка.

Шлюз адказвае са свайго стэка

Пакет, адрасаваны шлюзу, трапляе на яго лакальны ўваходны шлях, дзе ядро вырашае, ці прыме яго сокет, што слухае. Пакет, адрасаваны хосту за шлюзам, наадварот, трапляе на шлях перасылкі, дзе дзейнічае іншы набор праверак. Перасылку можна цалкам адключыць, а можна ўключыць ядром і затым адхіліць правілам фільтра, якое зусім не згадвае тунель. Нішто з гэтага не ўплывае на ўласны адказ шлюза, таму сімптом так надзейна ўводзіць у зман.

Старонкі адміністравання, дасягнутыя праз тунель, таксама належаць да першай катэгорыі. Яны сведчаць пра тунель, а не пра сетку за ім.

Прасачыце паток да першай мяжы, якая яго скідвае

Пачніце з кліента і пацвердзіце маршрут і адрас крыніцы, які выкарыстае паток. Затым назірайце за шлюзам, каб убачыць прыход менавіта гэтага патоку, і зноў за тым жа патокам, што выходзіць да LAN. Калі ён ніколі не прыходзіць, праблема на баку кліента або ў дазволеных прэфіксах тунеля. Калі ён прыходзіць і ніколі не выходзіць, праблема ў перасылцы або ў фільтры шляху наперад, і запіс ужо паказаў, у чым менавіта.

Правядзенне таго ж тэсту са шлюза хавае цікавую палову, бо пакет, які паходзіць ад шлюза, мае іншую крыніцу і іншае патрабаванне да вяртання. Выкарыстоўвайце паток кліента з яго ўласным адрасам крыніцы на кожным кроку. Запіс, зроблены не на тым інтэрфейсе, дае ўпэўненыя глупствы.

Зваротныя маршруты і хост-фаерволы адмаўляюць паасобку

Пасля таго як пакет дасягне хоста, мусіць выконвацца яшчэ тры ўмовы. Сэрвіс мусіць слухаць на адрасе, на які быў адпраўлены пакет, хост-фаервол мусіць яго прыняць, і адказ мусіць мець маршрут назад да пула кліентаў. Апошняя ўмова часта не выконваецца, бо маршрут па змаўчанні хоста паказвае на маршрутызатар, які ніколі не чуў пра дыяпазон тунеля. Вынік — злучэнне, якое ўстанаўліваецца з пункту гледжання хоста і маўкліва памірае ў іншым кірунку.

Праверце зваротны шлях наўмысна: адпраўце з кліента і назірайце за вяртаннем. Аднабаковы запіс вырашае за секунды тое, чаго не вырашыць гадзіна разважанняў.

Пацвярджайце кожны крок адрасам крыніцы кліента

Выконвайце праверкі па чарзе і захоўвайце кожны вынік, бо каштоўнасць у параўнанні, а не ў асобным радку. Каманды ніжэй фіксуюць адрас крыніцы, паказваюць абраны маршрут і запісваюць абодва бакі перасылкі. Замяніце свой хост LAN і інтэрфейс тунеля.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Запыт маршруту паказвае, ці адправіць кліент гэты пакет у тунель наогул, а ping паказвае, ці вярнулася што-небудзь ад хоста. Параўнанне двух запісаў аддзяляе прыход ад выхаду, бо кадр на інтэрфейсе тунеля без адпаведніка на інтэрфейсе LAN — гэта рашэнне аб перасылцы, а не збой сэрвісу. Калі абодва запісы паказваюць запыт, а толькі адзін паказвае адказ, застаецца падазроны зваротны маршрут.

Запішыце, які адрас адказаў і якая мэта перасылкі не спрацавала. Гэты сказ робіць справаздачу дзейснай замест сцвярджэння, што сервер недасяжны.