Три врсте OpenVPN пребацивања на pfSense-у, три механизма

„OpenVPN failover“ на pfSense-у покрива најмање три неповезана дизајна и сваки од њих тражи другачији механизам. Одржавати тунел живим преко резервне интернет везе, поново се повезивати на други сервер и усмеравати LAN саобраћај у други већ успостављени тунел нису варијанте једне функције. Изаберите квар од кога се браните пре него што изградите групу пролазника. Група која решава један од њих не чини ништа за друга два.

Именујте квар пре него што изградите групу

Напишите реченицу коју желите да буде истинита током испада. „Тунел се поново повезује преко резервног WAN-а“ и „филијала и даље долази до апликације преко другог тунела“ различите су реченице. Само прва говори о транспорту.

Затим је повежите с механизмом. Губитак локалног WAN-а је проблем избора интерфејса, мртва удаљена крајња тачка је проблем листе веза, а неупотребљива путања унутар успостављеног тунела је проблем усмеравања и политике.

Локални WAN: преместити транспорт

За pfSense OpenVPN клијента подржани распоред више WAN-ова бира одговарајућу групу пролазника као интерфејс на који се клијент везује. То је оно што омогућава спољној вези да оде преко резервне везе када примарна откаже. Само по себи не мења како се усмерава унутрашњи саобраћај.

Серверска страна истог дизајна је одвојена. OpenVPN серверу који мора бити доступан преко неколико јавних адреса потребан је слушалац и улазна политика за сваки од тих уноса, а не само клијент који уме да бира преко две везе. Један функционалан јавни унос није доказ да је други конфигурисан.

Правило усмеравања према политици за прослеђене LAN пакете није подешавање које премешта локално створену VPN транспортну везу. То су два различита претраживања и промена једнога не мења друго.

Удаљена крајња тачка: други сервер

Алтернативни remote је функција листе веза. Клијент покушава следећи унос када тренутни не одговара, што је корисно када је пао одређени хост, а не када је пала ваша сопствена узлазна веза. Два квара са корисничког стола изгледају слично и траже различите поправке.

Сваки кандидат мора бити стварна замена: компатибилна аутентификација, компатибилна клијентска политика и приступ истим приватним ресурсима. Друго име хоста које се разрешава на исту неисправну инфраструктуру није резерва. Сервер без потребне руте такође није, колико год његово руковање изгледало здраво.

Овај механизам такође не чини да два тунела прослеђују истовремено. Замењује једну везу другом, узастопно, а размак између њих видљив је свему што је радило.

Путања тунела: изабрати други излаз

Када су два тунела већ подигнута и саобраћај треба да користи здравији, механизам је додељени VPN интерфејс са сопственим пролазником, плус изричито правило политике које тамо шаље прави саобраћај. Група пролазника преко тих додељених интерфејса може изразити приоритет и надзор.

Тај дизајн говори о избору, а не о опоравку. Премештање нових веза на други тунел не говори ништа о сесијама већ успостављеним на првоме ни о томе да ли ће супротна страна прихватити нову изворну адресу. Третирати то као механизам опоравка значи поставити очекивања превисоко.

Ако је захтев да постојеће сесије преживе, реците то изричито. Већина имплементација не мигрира живи ток између тунела, а пројектовање као да то чине даје пребацивање које на дијаграму изгледа исправно, а у пракси одбацује сваку отворену везу.

Надзорници, NAT и правило fail-closed

Надзорник треба да тестира нешто што тунел треба да доставља. Циљ који одговара са тунелског партнера, али не из апликационе мреже иза њега, пријавиће здраво стање док корисници не виде ништа. Недоступан дијагностички циљ пријавиће мртво стање док је путања у реду. Изаберите адресу намерно и потврдите да је доступна само кроз предвиђени тунел.

Проверите одлазни NAT за оба излаза. Исправно превођење на примарноме не описује изворну адресу резерве, а удаљена приватна мрежа треба повратну руту која одговара извору који представљате. Превођење исправно на једној путањи може бити тихо погрешно на другој.

Затим одлучите шта се дешава са саобраћајем који никада не сме да користи WAN. pfSense има дефинисано понашање за правила чији је изабрани пролазник пао, а касније широко правило пропуштања или подразумевана рута могу да пониште вашу намеру. Запишите блокирани исход као захтев и проверите га тако што спустите путању.

Тестирајте губитак и опоравак одвојено, саобраћајем који смете да генеришете, и посматрајте три ствари одједном: WAN који носи спољну везу, тунел који носи захтев апликације и путању којом иде одговор. Пар зелених показатеља пролазника није једна од те три. Netgate водич за више WAN-ова описује везивање транспорта и извезене клијентске алтернативе на којима то почива.