Blocarea IPsec fără a strica Wi-Fi Calling al telefonului

Cererea vine mereu în aceeași formă: închideți IPsec la margine pentru că transportă tuneluri pe care nimeni nu le-a aprobat, iar prima reclamație vine de la cineva al cărui telefon a încetat să mai sune prin Wi-Fi. Ambele fapte sunt adevărate în același timp, și niciunul nu justifică renunțarea la control. De ce are nevoie paravanul este o excepție de serviciu cu o funcție numită, o sursă limitată, destinații documentate și un responsabil. Cinci pași o transformă într-o regulă pe care un străin o va putea revizui anul viitor.

Numiți serviciul înainte de a numi protocolul

Un telefon de birou pe un serviciu SIP și un aparat care face Wi-Fi Calling al operatorului nu împart același profil de rețea, iar VoIP ca termen de paravan nu descrie niciunul. Datele despre porturi și destinații trebuie să vină de la furnizorul sau operatorul care administrează serviciul, nu dintr-o listă de porturi memorată care aparține altui sistem telefonic. Aceasta este diferența dintre o regulă care protejează o funcție și o regulă care protejează un cuvânt.

Referința porturilor de serviciu a Apple listează UDP 500 și 4500 pentru Wi-Fi Calling, exact perechea pe care majoritatea blocărilor generale de IPsec o elimină. Scrieți numele funcției în registrul de modificări lângă acele porturi. Adăugați versiunea sau data referinței folosite, pentru că tabelele furnizorilor sunt editate. O regulă care numește serviciul pentru care există poate fi revizuită; una care numește o categorie de protocol nu.

Scrieți excepția ca un contract, nu ca o favoare

Excepția declară funcția permisă, clasele de dispozitive care o folosesc, transportul necesar și destinațiile pe care le documentează partea responsabilă. Are și un responsabil și o dată de revizuire, pentru că punctele terminale ale operatorului și modelele de aparat se schimbă fără să anunțe echipa paravanului. Dați revizuirea unei persoane, nu unui nume de echipă care va supraviețui echipei. Păstrați formularea suficient de precisă încât un străin să poată reconstrui regula doar din registru.

Puneți excepția în același ciclu ca restul politicii de margine, astfel încât mutarea unei destinații de către operator sau schimbarea modelului de aparat într-o flotă să fie observată la revizuire, nu la următoarea defecțiune. Închideți ciclul cu cel care a raportat apelurile întrerupte, pentru că doar el poate confirma remedierea fără a redeschide tunelul pe care blocarea trebuia să îl închidă. Acea confirmare aparține și registrului, cu o dată.

O permisiune permanentă etichetată drept reparație temporară de telefon este de neapărat doi ani mai târziu. O permisiune legată de un serviciu identificat are o expirare care se reînnoiește intenționat.

Limitați sursa cu onestitate

Limitarea excepției la un segment de dispozitive administrate este substanțial mai puternică decât deschiderea protocolului pentru fiecare laptop din clădire. Dacă rețeaua nu poate identifica acel segment, scrieți acest lucru în loc să sugerați că regula cunoaște dispozitivele. Cel mai ieftin rezultat bun este reutilizarea unei granițe care există deja din alt motiv, astfel încât excepția moștenește un control în loc să inventeze unul. Filtrarea după adresă nu este autentificare de dispozitiv, iar registrul de modificări nu trebuie să sugereze contrariul.

O adresă de sursă sau o adresă de hardware nu este dovada unui aparat fizic. Dacă vreuna are semnificație depinde în întregime de celelalte controale din acel segment. Dacă argumentul regulii se sprijină pe o adresă MAC, verificați ce îl împiedică pe utilizator să o schimbe înainte ca regula să fie publicată.

Acceptați ce nu vă poate spune o regulă de porturi

Porturile identifică puncte terminale de transport, nu intenția de afaceri. Când un serviciu de apeluri aprobat și un tunel neaprobat merg amândouă pe același UDP 4500, nicio regulă bazată pe porturi nu le separă. O regulă care pretinde că o face pare precisă și nu este, ceea ce este mai rău decât o regulă care își recunoaște propria formă. Este o limită a mecanismului, nu o greșeală a celui care l-a scris.

Spuneți acest lucru lângă regulă și împerecheați excepția cu orice aplicare are rețeaua, cum ar fi administrarea dispozitivelor sau o listă de destinații permise. Apoi exprimați excepția cât mai îngust permite instrumentul, de exemplu cu reguli nftables care numesc segmentul și perechea de porturi și pun refuzul general după ele:

nft add rule inet edge forward ip saddr 10.40.0.0/24 udp dport { 500, 4500 } counter accept
nft add rule inet edge forward udp dport { 500, 4500 } counter drop

nftables evaluează în ordine și se oprește la prima potrivire, așa că acceptarea limitată trebuie să stea deasupra refuzului general. Inversați-le și excepția nu face nimic în tăcere.

Validați funcția și refuzul

Rulați validarea aprobată pe un apel Wi-Fi obișnuit, din clasa de dispozitiv pentru care există excepția, și confirmați că un client exclus eșuează în continuare. Nu folosiți niciodată apelurile de urgență ca caz de test, sub nicio circumstanță. Apoi inspectați regula publicată, pentru că un contor blocat la zero este cea mai rapidă dovadă că excepția nu a corespuns niciodată:

nft -a list chain inet edge forward

Includeți o reconectare sau o schimbare de rețea în test și repetați-l de la un start rece, cu telefonul alăturându-se rețelei în loc să fie deja conectat. Dacă contorul se mișcă în timp ce apelurile încă eșuează, problema a părăsit paravanul și aparține listei de destinații a operatorului.