Помилка 809 — це проблема шляху, а не входу

Три умови визначають, що вам каже помилка 809: чи протокол профілю той, про який ви думаєте, чи пропускає шлях цей протокол і чи бачив шлюз спробу взагалі. Доки на це немає відповіді, помилка — це тайм-аут, а тайм-аут не є вироком обліковим даним. Порядок важливий, бо зміна не тієї умови першою знищує докази для двох інших.

Заблокований порт і неправильний пароль дають цілком різні повідомлення, і 809 рідко буває другим.

Підтвердьте протокол, який використовує профіль

Перевірте ім'я сервера, адресу й тип тунелю за поточними інструкціями оператора, потім занотуйте, від якого транспорту залежить цей тип. Ці три значення пов'язані; правильне ім'я із застарілим типом тунелю падає так само, як неправильне ім'я. IKEv2 спирається на UDP 500 і 4500, а власний трафік ESP треба дозволяти як окремий протокол, а не як TCP чи UDP. Профіль, скопійований зі старої конфігурації, може вказувати тип тунелю, який сервер уже не пропонує. Візьміть значення в оператора, а не виводьте його з підпису в діалозі.

Сторінка браузера на тому самому імені хоста перевіряє цілком іншу службу. Вона може довести, що хост живий, і нічого не доводить про невдалі переговори.

Змініть мережу, а не облікові дані

Якщо політика дозволяє, перевірте той самий профіль з іншої довіреної мережі, залишивши клієнт і сервер незмінними, щоб єдиною відмінністю був шлях доступу. Успіх в іншому місці вказує на фільтрацію на початковому шляху, а відмова всюди — на кінцеву точку або сам профіль. Запитайте в оператора, чи бачив шлюз спробу, бо клієнт без відповідної події на сервері — це інша межа, ніж явна відмова.

Випадкові правки реєстру й вимкнення брандмауера — популярна порада для цього коду, і жодна з них не випливає з підтвердженого діагнозу. Запитайте в оператора, яке документоване виправлення для цього розгортання.

Простежте код до наступного етапу

Якщо пізніша спроба доходить до автентифікації й дає інший код, дотримуйтеся цього нового етапу й відкиньте початковий діагноз тайм-ауту. Перенесення проблеми шляху в розслідування облікового запису марнує час з обох боків. Запишіть протокол, етап, на якому стався збій, і чи проводилося порівняння мереж, щоб наступна людина починала з доказів, а не з тексту діалогу.

Ставтеся до коду як до маркера етапу, а не як до вироку; таке читання — це різниця між п'ятихвилинною перевіркою і втраченим днем.

Що не варто змінювати першим

Облікові дані, стан блокування й сховище сертифікатів зрештою всі заслуговують на увагу. Жодне з них не є місцем, де 809 зазвичай починається, а зміна одного першим прибирає порівняння, яке знайшло б шлях. Відкладіть ці перевірки до після тесту мережі. Тримайте клієнт, профіль і сервер нерухомими, поки змінюєте мережу, і записуйте, що саме змінили.

Якщо оператор нещодавно змінив кінцеву точку, запитайте актуальні дані, замість відновлювати їх із пам'яті. Адреса, якої більше не існує, дає саме цей клас збою.

Запишіть протокол, перевірені мережі й погляд шлюзу. Ці три вирішують більшість повідомлень про 809.