Legătură fără fir ca rezervă: comutare rutată sau un singur segment?

Două clădiri, o legătură radio punct-la-punct și o VPN de internet care ar putea servi drept a doua cale. Înainte ca rezerva să devină automată, o singură întrebare decide aproape tot restul: ce trebuie să supraviețuiască — accesibilitatea IP între subrețele separate sau un singur segment Ethernet partajat? Faptul că radioul se comportă ca un cablu nu este un argument pentru a extinde fiecare cadru de difuzare prin internet. Răspundeți mai întâi la întrebare, pentru că cele două răspunsuri cer un control al buclelor diferit, verificări de stare diferite și idei diferite despre ce înseamnă recuperare.

Decideți ce trebuie să supraviețuiască întreruperii

Enumerați aplicațiile care trebuie să continue să funcționeze și notați dacă depind de accesibilitatea la Layer 3 sau de adiacența la Layer 2. Partajarea fișierelor, conexiunile la baze de date și serviciile web se preocupă de obicei doar de rute; protocoalele de descoperire, unele produse de cluster și tot ce așteaptă un singur domeniu de difuzare se preocupă de adiacență. O rezervă care restabilește tipul greșit de accesibilitate produce un sit conectat tehnic și inutil în practică.

Scrieți acea listă și atașați-o proiectului, pentru că răspunsul se deplasează de obicei imediat ce primul proprietar de aplicație aude de noua legătură.

Comutare rutată: două prefixe, o cale preferată

Cu prefixe de sit distincte, rezerva devine o problemă de rutare. Fiecare router are o cale preferată prin radio și una mai puțin preferată prin tunel, iar calea preferată este retrasă când radioul nu mai livrează trafic. Partea opusă are nevoie de propria cale de întoarcere, iar ambele părți ar trebui să cadă de acord asupra căii preferate în fiecare direcție, ca traficul să nu ocolească mult doar într-o singură direcție.

ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1

Citiți a treia comandă la fel ca pe a doua: o regulă de politică, un al doilea tabel sau o decizie bazată pe sursă pot trimite traficul dintr-o subrețea altfel decât din alta, iar o singură căutare implicită ascunde acest lucru.

Comutare punte: un segment, o cale care blochează

Dacă adiacența este într-adevăr necesară, rezerva trebuie să transporte cadre Ethernet, ceea ce un tunel IP rutat nu face. Punerea unei interfețe VPN într-un segment local este acceptată de unele platforme, iar acele interfețe devin apoi membre ale punții cu consecințele aferente. Două căi Layer 2 care transmit simultan formează o buclă, așa că proiectul are nevoie de un arbore de acoperire care să cuprindă ambele situri și de o declarație clară despre ce cale trebuie să blocheze.

Aceasta este o decizie de proiectare substanțială și nu o casetă de bifare, iar documentația de punte pentru platforma dumneavoastră, cum ar fi prezentarea generală a punților pentru pfSense, este locul unde confirmați la ce participă de fapt un membru VPN. Activarea unei opțiuni de arbore de acoperire pe un singur dispozitiv fără legătură nu demonstrează nimic despre aranjamentul cap la cap.

Monitorizați granița care contează

Un radio alimentat, o interfață activă și un tunel sănătos descriu fiecare un fapt local. Niciunul nu demonstrează că un pachet dintr-o clădire a ajuns la un gazdă din cealaltă, iar acesta este singurul fapt pe care logica de comutare ar trebui să acționeze. Monitorizați o țintă dincolo de routerul îndepărtat dacă politica permite, și monitorizați ambele direcții separat, ca o defecțiune asimetrică să fie vizibilă.

ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10

Țineți verificarea ieftină și limitată: un interval scurt, un număr mic și un timp de așteptare care se potrivește toleranței aplicației. Un monitor care depinde el însuși de calea pe care o testează va raporta succes până în momentul în care încetează să mai raporteze orice.

Exersați ambele direcții sub sarcină

Nu copiați o singură țintă de convergență din topologia altcuiva. Timpul de detectare, convergența rutei sau a punții, pregătirea tunelului și recuperarea aplicației contribuie fiecare cu propria întârziere, iar suma pe echipamentul dumneavoastră este singurul număr care contează. Exersați în timp ce rulează trafic reprezentativ, astfel încât măsurătoarea să includă cozile și sesiunile care există în producție.

sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10

Testați recuperarea la fel de atent ca defecțiunea. Un radio instabil care apare și dispare va târî traficul înainte și înapoi dacă logica de preferință nu are amortizare, iar utilizatorii percep asta ca mai rău decât o singură întrerupere curată. Înregistrați calea selectată la fiecare etapă, care cereri noi au reușit și ce s-a întâmplat cu sesiunile care erau deschise când calea s-a schimbat. Exact acea înregistrare transformă un al doilea cablu într-o politică operațională.