Как да изградим политика за преминаване при отказ на VPN на рутера без изтичания

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

Решете изхода, преди да изберете детектора

Обикновено са на масата три изхода: да насочите засегнатите клиенти през резервен тунел, да им позволите да ползват обикновения WAN или да ги блокирате напълно. Запишете кой за кой VLAN, SSID или клас устройства се отнася. Едно плоско правило “превключи на WAN” е начинът финансовата папка по-горе да се озове на публичен път.

Трите не са взаимозаменяеми. Резервният WAN държи бюрото за поддръжка да отговаря на телефони, като същевременно излага вътрешните имена на локалния резолвер. Резервният тунел запазва политиката, но може да попадне на адрес за изход, който другата страна не приема. Блокирането е правилно за VLAN на заплатите и грешно за гостуваща мрежа, която никога не е ползвала тунела.

Свържете детектора с отказа, от който наистина се страхувате

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

В pfSense практичната схема е група от шлюзове, захранвана от dpinger, който проверява адрес за мониторинг и маркира шлюз като недостъпен, когато загубата или латентността преминат праговете му. Насочете този мониторинг към нещо отвъд тунела, например хост в далечната LAN или публичен адрес, до който стигате през него. Насочването му към собствения адрес на партньора на тунела измерва частта, за която вече знаете, че е жива.

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

Използвайте нива, а не един плосък списък от членове. Основен в ниво 1, резервен тунел в ниво 2, WAN в ниво 3 само за VLAN, чиято политика го позволява. В pfSense това се намира под System > Routing > Gateway Groups: добавете двата шлюза, дайте им различни нива, задайте Trigger Level на member down plus packet loss, запазете и след това приложете групата като стандарт на интерфейса или в полето Gateway на правилата на защитната стена, които се нуждаят от нея.

За клиентска инстанция на OpenVPN в pfSense 2.5 и по-късно настройката Default Gateway на инстанцията решава дали тунелът изобщо замества системния маршрут по подразбиране. Политическата маршрутизация по правило се държи както очаквате само когато маршрутът, който предполагате, наистина е инсталиран. След промяната проверете Status > Gateways вместо да се доверявате на иконата за състояние на тунела.

Две настройки причиняват повечето трептения. Едната е интервал на проверка, по-кратък от собствената реконвергенция на доставчика. Другата е група, в която основният и резервният споделят ниво, така че и двамата остават допустими по всяко време. Добавете хистерезис чрез прагове за загуба и латентност, преди потребителите ви да усетят преходите вместо вас.

Затворете пътищата, които тунелът никога не е притежавал

Първо изтичанията на DNS. Резолверът продължава да отговаря на WAN и препраща навън през него, така че имената продължават да се резолвват през доставчика, докато трафикът е закован към тунела. Ограничете изходящите интерфейси на резолвера, изпратете вътрешния резолвер към клиентите и блокирайте порт 53 за всичко останало във VLAN само-VPN.

IPv6 се нуждае от собствено решение. Двустекова LAN може да загуби тунела и да запази работещ глобален маршрут по подразбиране за IPv6, така че браузърите предпочитат IPv6 и излизат през WAN, докато IPv4 изглежда напълно затворен. Или насочете IPv6 в тунела, или спрете да обявявате глобален префикс, докато тунелът е долу. Половин политика е по-лоша от никаква, защото изглежда, че работи.

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

Тествайте отпадането, трептенето и пътя обратно

Извадете основния при безвреден трафик, после прочетете четири неща: Status > Gateways за състоянията на членовете на групата, pfctl -ss за състояния, все още заковани към стария шлюз, traceroute от клиент за пътя на изхода и заявка към резолвера, за да видите кой сървър е отговорил.

Сега го разтрепете. Вдигнете основния за тридесет секунди, свалете го за тридесет, два пъти. Ако трафикът гони всеки преход, праговете са твърде стегнати или нивата са грешни. Оправете го по свой график, защото иначе доставчик ще го направи по своя.

Накрая потвърдете, че все още можете да администрирате рутера. Дръжте извънлентов път, например конзолен кабел, VLAN за управление или клетъчен модем. Тест за преминаване при отказ, който ви заключва, е тест, който не можете да завършите, а недостъпният рутер не може да се върне сам.

Преди да обявите политиката за готова, трябва да можете да отговорите на четири въпроса, без да отваряте терминал: кои VLAN могат да ползват WAN, докато тунелът е долу, какво следи детекторът и колко чака, кои сървъри за имена и IPv6 маршрути се местят с пътя и как се връщате, ако резервът също се провали. Ако някой отговор е “каквото беше по подразбиране”, политиката все още принадлежи на рутера, а не на вас.