Како направити политику пребацивања VPN-а на рутеру без цурења
Одлучите шта саобраћај треба да ради када омиљени тунел падне: резервни тунел, обичан WAN или блокада. Затим то направите и тестирајте на рутеру.
Пребацивање је радило тачно онако како је конфигурисано, и то је био проблем. Када је главни тунел пао, рутер је преместио подразумевану руту на кабловски модем, лаптопови су наставили да прегледају, и нико није позвао. Два дана касније неко је приметио да је финансијски директоријум био доступан преко отворене интернет путање шест сати. Политика пребацивања VPN-а на рутеру није трик рутирања; то је одлука о томе шта саобраћај треба да ради када омиљена путања нестане, а та одлука мора постојати пре него што путања нестане.
Одлучите о исходу пре него што изаберете детектор
Обично су три исхода на столу: послати погођене клијенте кроз резервни тунел, пустити их да користе обичан WAN или их потпуно блокирати. Запишите који важи за који VLAN, SSID или класу уређаја. Једно равно правило „пребаци на WAN” је разлог зашто је горњи финансијски директоријум завршио на јавној путањи.
Та три нису заменљива. Повратак на WAN држи подршку да одговара на телефоне, али излаже интерна имена локалном резолверу. Резервни тунел чува политику, али може слетети на излазну адресу коју друга страна не прихвата. Блокада је исправна за VLAN обрачуна плата и погрешна за гостујућу мрежу која никада није користила тунел.
| Outcome | Right for | What breaks |
|---|---|---|
| Backup tunnel | Policy must hold, remote access required | New exit address, return route, slower rekey |
| Plain WAN | Guest or public-only traffic | Internal names, DNS and IPv6 exposure |
| Block | Payroll, admin, anything VPN-only | Users lose all access and call you |
Упарите детектор са кваром ког се заиста плашите
Стање руковања, стање интерфејса и употребљиво прослеђивање су три различита сигнала, а кориснику је важан само последњи. WireGuard peer може показивати свеже руковање док upstream провајдера одбацује пакете. OpenVPN клијент може остати на „повезано” након што рута коју је гурнуо престане да се решава.
На pfSense практично решење је група гејтвеја коју напаја dpinger, који испитује адресу за надзор и означава гејтвеј као недоступан када губитак или кашњење пређу прагове. Усмерите тај надзор на нешто изван тунела, као што је хост у удаљеном LAN-у или јавна адреса до које стижете кроз њега. Усмеравање на сопствену адресу peer-а тунела мери део за који већ знате да је жив.
Направите групу тако да резерва остане последње средство
Користите слојеве, а не једну равну листу чланова. Главни на слоју 1, резервни тунел на слоју 2, WAN на слоју 3 само за VLAN-ове чија политика то дозвољава. У pfSense-у то стоји под System > Routing > Gateway Groups: додајте оба гејтвеја, дајте им различите слојеве, поставите Trigger Level на недоступност члана плус губитак пакета, сачувајте, па примените групу као подразумевани гејтвеј интерфејса или у пољу Gateway правила firewall-а којима је потребна.
За инстанцу OpenVPN клијента на pfSense 2.5 и новијем, подешавање Default Gateway инстанце одлучује да ли тунел уопште замењује системску подразумевану руту. Рутирање по правилима понаша се онако како очекујете само када је рута коју претпостављате заиста инсталирана. После измене проверите Status > Gateways уместо да верујете икони стања тунела.
Две поставке изазивају већину треперења. Једна је интервал испитивања краћи од сопствене реконвергенције провајдера. Друга је група у којој главни и резервни деле слој, па оба остају подобна све време. Додајте хистерезу кроз прагове губитка и кашњења пре него што корисници сами осете преласке.
Затворите путање које тунел никада није држао
Прво цурења DNS-а. Резолвер наставља да одговара на WAN-у и прослеђује кроз њега, па се имена и даље решавају кроз ISP док је саобраћај прикован за тунел. Ограничите излазне интерфејсе резолвера, прогурајте интерни резолвер до клијената и блокирајте порт 53 за све остало на VLAN-овима само са VPN-ом.
IPv6 тражи сопствену одлуку. Dual-stack LAN може изгубити тунел и задржати исправну глобалну IPv6 подразумевану руту, па претраживачи преферирају IPv6 и излазе кроз WAN док IPv4 изгледа савршено затворен. Или рутирајте IPv6 у тунел, или престаните да оглашавате глобални префикс док је тунел пао. Пола политике је горе од никакве, јер изгледа као да ради.
Затим повратна путања. Ако резервни излаз користи другу изворну адресу, друга страна мора знати како да пошаље саобраћај назад на њу, а свако стање везано за стару адресу је већ мртво. Сесије отворене када је главни пао не мигрирају; стоје док не истекну и апликација не одлучи шта ће с њима.
Тестирајте пад, треперење и пут назад
Извуците главни док ради безопасан саобраћај, па прочитајте четири ствари: Status > Gateways за стања чланова групе, pfctl -ss за стања још прикована за стари гејтвеј, traceroute са клијента за излазну путању и упит резолверу да видите који је сервер одговорио.
Сада изазовите треперење. Подигните главни на тридесет секунди, спустите на тридесет, два пута. Ако саобраћај јури сваки прелаз, прагови су преуски или су слојеви погрешни. Поправите то по свом распореду, јер ће иначе провајдер то урадити по свом.
На крају потврдите да још можете да администрирате рутер. Држите путању ван опсега, као што је конзолни кабл, управљачки VLAN или мобилни модем. Тест пребацивања који вас закључа напољу је тест који не можете да завршите, а рутер до ког се не може доћи не може сам да се врати.
Пре него што прогласите политику готовом, треба да можете да одговорите на четири питања без отварања терминала: који VLAN-ови смеју да користе WAN док је тунел пао, шта детектор посматра и колико чека, који сервери имена и IPv6 руте се селе са путањом, и како се враћате ако и резерва падне. Ако је било који одговор „шта год је било подразумевано”, политика још припада рутеру, а не вама.