Exemple de configurare a unei conexiuni de birou la Internet prin Ethernet cu redundanță prin intermediul a 2 operatori

Conectarea biroului prin Ethernet
cu redundanță prin intermediul a doi operatori LTE

Vom complica exemplul anterior. Este necesar să furnizeze acces la Internet în următoarele condiții:







  • Există un canal Ethernet și doi operatori LTE.
  • Canalul Ethernet este în orice caz o prioritate.
  • Ambii operatori LTE sunt echivalenți.
  • Este necesar să se asigure timpul minim de comutare la canalul de așteptare.
  • Aplicații sau tuneluri care rulează printr-un dispozitiv care nu răspunde foarte bine la schimbare canal - lung pereinitsializirutsya restabili sesiunile lor, etc. Din acest motiv, este necesar să se reducă numărul de switch-uri, și anume, în cazul în care dispozitivul este deja de lucru pe unul dintre canalele LTE, aceasta ar trebui să fie pe ea, și să nu se mute la alta fără o nevoie clară. Trebuie să părăsiți acest canal numai atunci când îl abandonați sau când ridicați canalul Ethernet principal.

Este utilizat dispozitivul NSG-1700 cu două opțiuni LTE / 3G. Ca și în exemplul anterior, performanța fiecărui canal este controlată de ping. Particularitatea acestei probleme este că un astfel de algoritm complex și ramificat pentru selectarea unui canal de comunicație (și, de regulă, unic pentru fiecare client) nu poate fi descris de o ierarhie consecventă de metrici sau de alte criterii. Pentru a oferi toate opțiunile posibile, va trebui să scrieți un script complet de mai jos cu un număr mare de tranziții condiționate.

Exemple de configurare a unei conexiuni de birou la Internet prin Ethernet cu redundanță prin intermediul a 2 operatori

  • Cartela SIM a primului operator este instalată în slotul superior
  • Cartela SIM a celui de-al doilea operator este instalată în slotul inferior
  • Solicitarea PIN la cartele dezactivate

Pentru a trimite un ping la controlul gazdă 3 (fiecare dintre operatorii) de rute fixe este mai ușor de utilizat de rutare bazată pe reguli stabilite și tabele de rutare separate. la tabelul de rutare Ethernet este populat cu scriptul de start (este posibil, în loc să se utilizeze un mecanism de protocol de rutare dinamic static). Interfețele LTE primesc rute prin DHCP și le scriu fiecare în propriul tabel.







Apoi fiecare dintre ping-uri este trimis pe masa proprie; dacă nu a fost posibil să se facă acest lucru (nu există o conexiune LTE și nu există rute în acest tabel), atunci acesta este distrus de următoarea regulă, astfel încât să nu fie ratată accidental de alte reguli.

Dacă dispozitivul trece prin trafic, NAT este necesar pe fiecare dintre interfețe. Dacă tot traficul LAN trebuie să meargă numai în tunel, nu este necesar (precum și curățarea tabelelor NAT folosind -F conntrack de mai jos în script-uri).

Script-ul pentru selectarea unui canal de comunicare, se face referire mai sus, este convenabil să emită sub forma unui generator de evenimente. În cadrul procesorului de evenimente, acesta va reprezenta un senzor virtual cu canalul numelui și posibile stări nul. ETH. m1 și m2. respectiv. Din moment ce acest script este mai convenabil pentru a scrie un rând voluminos și indentat, pentru a începe cu, de a crea o ramură de configurare:

Manipulatorul de evenimente reacționează la evenimentele acestui senzor, adică privind trecerea de la un stat la altul, după cum urmează:

Scripturile pot fi scrise într-un șir sau, așa cum sa procedat mai sus, în mai multe rânduri. Pentru claritate, a fost adăugat înregistrarea evenimentului în syslog.

Setați traseul prin interfața de difuzare este folosind doar numele său (dev) în loc să specifice în mod explicit următoarele gateway-ul (via) - nu foarte bine, dar pentru interfețele LTE existente pe dispozitive NSG este permisă. Și atunci trebuie să determine numele interfeței dinamic, deoarece nu este identic cu numele portului fizic și poate varia în funcție de anumite interfețe cip LTE și ordine de toamna / lift. Mai corect să fie definite gateway implicit atribuit interfeței LTE selectată (și interfață Ethernet, în cazul în care este configurat dinamic prin DHCP) și specificați în mod explicit. În următoarele versiuni ale NSG Linux, va fi propus un simplu mecanism în acest scop.

În configurații mai simple (Ethernet + LTE sau 2 × LTE), această configurație poate fi simplificată, dar, în principiu, este eficientă și astfel - ruta spre interfața lipsă nu va fi niciodată atribuită.

Indicația explicită a APN, a numelui de utilizator și a parolei în rețelele celulare moderne nu este necesară. Dacă acestea sunt specificate explicit de către operator (rețelele 2G, unele rețele învechite 3G sau serviciul VPN al operatorilor celulari), acestea sunt specificate în nodurile provider.main și provider.aux. respectiv.

Trebuie să introduceți o parolă pentru a accesa dispozitivul.

Din motive de securitate, se recomandă cu tărie:

  • Dezactivați Telnet și utilizați numai SSH pentru gestionarea la distanță
  • Blocați HTTP cu filtre și utilizați numai HTTPS pentru gestionare la distanță






Trimiteți-le prietenilor: