Filtrele farului Nebula față de firewall: ce blochează fiecare

Priviți un handshake Nebula din partea greșită și cele două mecanisme par interschimbabile. Unul decide ce adrese anunță un nod farului și ce adrese îndepărtate va încerca; celălalt decide ce poate trece după ce tunelul există. Un filtru poate opri o conexiune înainte de a fi evaluată orice regulă de firewall, iar o regulă de firewall nu poate readuce la viață un punct final pe care descoperirea l-a eliminat. Cele două straturi răspund la întrebări diferite, iar ordinea în care acționează este cheia.

Urmați o conexiune prin patru etape: adresa locală anunțată, punctul final îndepărtat luat în considerare, handshake-ul și traficul din stratul suprapus. Fiecare etapă are propria configurație și propria semnătură de eșec.

Începeți cu adresa locală pe care o anunță nodul

local_allow_list filtrează adresele locale ale acestui host înainte de a fi raportate farurilor. Intrările pot fi intervale de adrese, iar configurația acceptă și modele de nume de interfață. Acest lucru este util când un host are punți de containere sau interfețe de tunel suplimentare care nu ar trebui să devină puncte finale pentru parteneri.

Parcurgeți interfețele hostului și întrebați la care un partener îndepărtat poate ajunge cu adevărat. O adresă de punte Docker este locală pentru acel host și inutilă pentru un partener dintr-o altă rețea. Anunțarea ei risipește descoperirea și poate trimite un partener spre o adresă care nu răspunde niciodată. Tot ceea ce un partener nu poate ruta este zgomot în răspunsul farului.

O listă îngustă de permisiuni este aici mai sigură decât o listă largă de blocări. Dacă există doar intrări de permisiune, restul nespecificat este exclus; adăugarea ulterioară a unei intrări de blocare schimbă logica implicită și necesită propria revizuire. Acea schimbare merită o a doua privire asupra valorii implicite.

Apoi observați selecția punctului final îndepărtat

remote_allow_list filtrează adresele pe care acest host le va lua în considerare pentru un partener îndepărtat în timpul unui handshake. Se aplică adresei din stratul de bază, nu adresei din stratul suprapus pe care partenerul o va folosi după ce tunelul este ridicat.

Un interval privat poate fi perfect utilizabil într-o rețea de birou partajată și lipsit de sens când cele două hosturi se află în rețele neînrudite care folosesc ambele 10.0.0.0/8. Filtrul vă permite să preferați calea rutabilă și să ignorați coincidența.

Când un partener nu se poate conecta, comparați adresa încercată cu regula care îi corespunde. Activați jurnalele handshake-ului și citiți adresa îndepărtată selectată; linia de jurnal numește punctul final care a supraviețuit filtrării, ceea ce este mai util decât lista adreselor pe care le deține partenerul.

Un filtru de nume de interfață pe partea care anunță poate elimina punctul final înainte ca partea receptoare să îl vadă. Verificați ambele noduri când eșuează doar o direcție.

După handshake se aplică regulile de acces ale stratului suprapus

Regulile de firewall ale Nebula funcționează în interiorul stratului suprapus, după ce tunelul este stabilit. Ele potrivesc hosturi, grupuri, porturi și protocoale și decid dacă un pachet poate intra sau ieși din hostul local. Nu selectează un punct final din stratul de bază.

Această separare explică un diagnostic greșit frecvent. Un operator adaugă o regulă de firewall pentru un port și tot nu se poate conecta, pentru că filtrul farului a eliminat singurul punct final accesibil. Un alt operator deschide filtrul de adrese și tot nu ajunge la serviciu, pentru că firewall-ul stratului suprapus respinge portul.

Citiți eșecul la stratul potrivit. Un handshake care nu se finalizează niciodată indică descoperirea, filtrarea punctelor finale sau calea de rețea. Un handshake finalizat urmat de o conexiune la serviciu respinsă sau abandonată indică firewall-ul stratului suprapus sau aplicația.

Citiți valoarea implicită când amestecați permisiunea și blocarea

Configurația farului acceptă liste doar cu permisiuni, doar cu blocări și mixte, iar valoarea implicită pentru restul nespecificat diferă între aceste forme. O listă mixtă are nevoie de o valoare implicită explicită pentru familia de adrese; presupunerea că restul se comportă ca configurația anterioară este felul în care un punct final funcțional dispare în tăcere.

lighthouse:
  local_allow_list:
    interfaces:
      docker0: false
  remote_allow_list:
    192.168.0.0/16: true
    default: false

Tratați valoarea implicită ca parte a regulii, nu ca text de șablon. Dacă valoarea implicită a familiei este blocarea, fiecare adresă nelistată este exclusă, inclusiv un nou interval de birou adăugat după ce configurația a fost scrisă.

Notați ce adrese trebuiau să fie accesibile și testați din ambele părți. Un filtru care funcționează pentru o pereche de parteneri poate eșua pentru altă pereche a cărei singură cale comună folosește o adresă pe care lista o exclude.

Folosiți relay când niciun punct final direct nu este accesibil

Dacă fiecare punct final candidat este filtrat sau inaccesibil, răspunsul nu este o listă de permisiuni mai largă care readmite adrese în care nu aveți încredere. Configurația relay a Nebula oferă o cale alternativă pentru partener când conectivitatea directă nu este fezabilă.

Relay rezolvă transportul și descoperirea, nu autorizarea, și nu lărgește firewall-ul. Firewall-ul stratului suprapus decide în continuare ce servicii pot fi folosite, iar relay nu transformă filtrarea farului într-un mecanism de control al accesului.

Testați calea relay cu punctele finale directe dezactivate și confirmați că serviciul dorit funcționează în continuare, în timp ce unul nedorit nu. Acel singur test separă o corecție de transport de o schimbare de politică și menține cele două straturi oneste.