Заявката пристига, сървърът я записва в журнала, а клиентът продължава да отчита изтичане на времето. Тази комбинация означава, че отговорът не е намерил пътя обратно, и това е една от малкото неизправности, които можете да потвърдите от двата края едновременно. Изпълнявайте проверките по ред и спрете, когато една от тях се провали.

Започнете от мястото, където е пристигнала заявката

Потвърдете, че пакетът е стигнал до услугата, преди да проверявате каквото и да е друго. Запис в журнала на сървъра, брояч на връзките или разрешен захват в далечния край отговарят на същия въпрос, а липсата им ви връща към тунела, а не напред към отговора. Това е проверката, която разделя проблем с препращането от проблем с обратния път.

Ако заявката никога не е пристигнала, спрете тук. Тунелът, маршрутизирането към частния префикс или правилото за достъп са темата, а пътят на отговора още не е от значение. Отбележете и адреса на източника, който сървърът е видял. Той е или адресът от пула, който клиентът е получил, или транслационен адрес, и тази разлика определя коя от следващите проверки се прилага.

Отговорът се нуждае от маршрут до пула

Клиентът за отдалечен достъп обикновено получава адрес от пул, а частната мрежа се нуждае от маршрут обратно към този пул. Сървър, чийто маршрут по подразбиране сочи към собствения му шлюз, предава пакета на този шлюз, който няма представа къде се намира пулът, и отговорът умира там. Клиентът вижда изтичане на времето, защото нищо не се е върнало, което е неразличимо от заявка, която никога не е излязла.

Проверете маршрута, който сървърът избира за адреса на клиента, а не маршрута, който използва за собствената си подмрежа. Тези две търсения могат да дадат различни отговори и тук значение има второто. Транслацията е алтернативният дизайн и тя променя това, което сървърът вижда. Тя може да опрости обратния път, а също премахва оригиналния адрес на клиента от журналите на сървъра, което засяга всяко правило или отчет, изградени върху това поле.

Сравнете захвата на сървъра със захвата на шлюза

Сравнете какво напуска сървъра с какво пристига на шлюза. Захват на изходящия интерфейс на сървъра и захват на тунелния шлюз отговарят на различни половини от въпроса, а разликата между тях локализира загубата.

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 stopsWhat it proves
Request in the server log, nothing on its outbound captureThe server picked a gateway that cannot reach the pool
Reply leaves the server but never shows up at the gatewayLoss on the LAN path, not on the tunnel
Reply reaches the gateway but not the clientReturn translation or tunnel policy, not the server route

Заявка, генерирана от самия шлюз, е слаб заместител на клиентски тест, защото произхожда от различен адрес и попада под различни правила. Затова успешен ping от шлюза и неуспешна заявка от клиента могат да бъдат верни едновременно.

Когато по пътя има няколко маршрутизатора, проверете всеки, на който му трябва маршрут до пула. Дизайнът сайт към сайт често изисква отдалеченият префикс да е известен на повече от едно устройство, а самият шлюз трябва да препраща между тунела и локалната мрежа; бележките на strongSwan за препращане покриват страната на sysctl и защитната стена.

Запишете пула, префикса и отговорника

Четири факта принадлежат в бележката: пулът, който клиентът е получил, частният префикс, който му е бил нужен, маршрутизаторът, отговорен за отговора, и правилото за транслация, ако съществува. С тях по-късна промяна на шлюза е сравнение, а не разследване.

След това тествайте отново с обикновен клиент и реалния акаунт на приложението. Разширяването на правата на приложението не може да поправи обратния път на пакета, а промяна на акаунта по време на тази диагностика ще обърка следващото сравнение. Ако дизайнът разчита на транслация, документирайте я там, където се четат журналите на сървъра. Човекът, който види непознат адрес на източника в одитен запис, не би трябвало да преоткрива съответствието от тикет.

Подобни статии