Три вида 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 го опишува врзувањето на транспортот и извезените клиентски алтернативи на кои тоа се потпира.