Уеб сървърът изчезва, когато се свърже VPN клиент

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

Симптомът: заявки влизат, отговорите излизат през грешната врата

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

Потвърдете го, като наблюдавате къде отива отговорът, а не като наблюдавате пристигането на заявката.

Улавяйте едновременно на физическия интерфейс и на устройството на тунела. Ако заявката се появи на физическия интерфейс, а отговорът — на тунела, диагнозата е приключена. Отговор, който не се появява никъде, означава, че услугата никога не е приела връзката, а това е отделно разследване с отделна причина.

Два маршрута по подразбиране и едно решение за маршрутизация

Клиент, който инсталира маршрут по подразбиране, добавя втори запис с по-добра метрика от LAN шлюза. Някои клиенти вместо това инсталират два маршрута за половин обхват, които покриват същото пространство по-конкретно и печелят търсенето по същия начин. И двете техники оставят обикновените изходящи пакети да избират интерфейса на тунела.

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

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

Поправете обратния път, без да счупите тунела

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

Избирайте според това какво трябва да прави хостът, а не според това кой фрагмент сте намерили първи.

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

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Когато хостът маршрутизира и за LAN зад себе си

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

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

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