IPsec blokkeer sonder om die selfoon se Wi-Fi Calling te breek

Die versoek kom altyd in dieselfde vorm: sluit IPsec by die rand omdat dit tonnels dra wat niemand goedgekeur het nie, en die eerste klagte kom van iemand wie se selfoon opgehou het om oproepe oor Wi-Fi te maak. Albei feite is gelyktydig waar, en nie een regverdig om die beheer te laat vaar nie. Wat die vuurmuur nodig het, is 'n diensuitsondering met 'n benoemde funksie, 'n begrensde bron, gedokumenteerde bestemmings en 'n eienaar. Vyf stappe maak daarvan 'n reël wat 'n vreemdeling volgende jaar kan hersien.

Benoem die diens voordat jy die protokol benoem

'n Tafeltelefoon op 'n SIP-diens en 'n selfoon wat die netwerk se Wi-Fi Calling gebruik, deel nie dieselfde netwerkprofiel nie, en VoIP as vuurmuurterm beskryf nie een van hulle nie. Poort- en bestemmingsdata moet van die verskaffer of die netwerk kom wat die diens bedryf, nie van 'n onthoude poortlys van 'n ander telefoonstelsel nie. Dit is die verskil tussen 'n reël wat 'n funksie beskerm en 'n reël wat 'n woord beskerm.

Apple se dienspoortverwysing lys UDP 500 en 4500 vir Wi-Fi Calling, wat toevallig die presiese paar is wat die meeste allesomvattende IPsec-blokke laat val. Skryf die funksienaam in die veranderingrekord langs daardie poorte. Voeg die weergawe of datum van die verwysing wat jy gebruik het by, want verskaffertabelle word geredigeer. 'n Reël wat die diens noem waarvoor dit bestaan, kan hersien word; een wat 'n protokolkategorie noem, kan nie.

Skryf die uitsondering as 'n kontrak, nie 'n guns nie

Die uitsondering noem die toegelate funksie, die toestelklasse wat dit gebruik, die transport wat dit nodig het en die bestemmings wat die verantwoordelike party dokumenteer. Dit dra ook 'n eienaar en 'n hersieningsdatum, want netwerkeindpunte en selfoonmodelle verander sonder om die vuurmuurspan in te lig. Gee die hersiening aan 'n persoon eerder as aan 'n spannaam wat die span sal oorleef. Hou die bewoording spesifiek genoeg dat 'n vreemdeling die reël uit die rekord alleen kan herlei.

Plaas die uitsondering op dieselfde siklus as die res van die randbeleid, sodat 'n netwerk wat 'n bestemming skuif of 'n vloot wat van selfoonmodel verander, by die hersiening opgemerk word eerder as by die volgende onderbreking. Sluit die lus met wie ook al die gebreekte oproepe gerapporteer het, want hulle is die enigste persoon wat die regstelling kan bevestig sonder om die tonnel te heropen wat die blok moes sluit. Daardie bevestiging hoort ook in die rekord, met 'n datum.

'n Permanente toelating wat as 'n tydelike selfoonoplossing gemerk is, is twee jaar later onverdedigbaar. 'n Toelating wat aan 'n geïdentifiseerde diens gekoppel is, het 'n vervaldatum wat doelbewus vernuwe word.

Baken die bron eerlik af

Om die uitsondering tot 'n bestuurde toestelsegment te beperk, is wesenlik sterker as om die protokol vir elke skootrekenaar in die gebou oop te maak. As die netwerk daardie segment nie kan identifiseer nie, skryf dit neer eerder as om te impliseer dat die reël toestelbewus is. Die goedkoopste goeie uitkoms is om 'n grens te hergebruik wat reeds om 'n ander rede bestaan, sodat die uitsondering 'n beheer oorneem eerder as om een te vind. Filtering op adres is nie toestelverifikasie nie, en die veranderingrekord moet nie anders aandui nie.

'n Bronadres of 'n hardeware-adres is nie bewys van 'n fisiese selfoon nie. Of enige van hulle betekenis dra, hang heeltemal af van die ander kontroles binne daardie segment. As die argument vir die reël op 'n MAC-adres rus, kyk wat 'n gebruiker keer om dit te verander voordat die reël uitgestuur word.

Aanvaar wat 'n poortreël jou nie kan sê nie

Poorte identifiseer transporteindpunte, nie sakebedoeling nie. Wanneer 'n goedgekeurde oproepdiens en 'n nie-goedgekeurde tonnel albei op UDP 4500 ry, skei geen poortgebaseerde reël hulle nie. 'n Reël wat beweer dat dit dit doen, lyk presies en is dit nie, wat erger is as 'n reël wat sy eie vorm erken. Dit is 'n beperking van die meganisme, nie 'n fout van die persoon wat dit geskryf het nie.

Sê dit langs die reël, en paar die uitsondering met watter handhawing die netwerk ook al het, soos toestelbestuur of 'n bestemmingstoelaatlys. Druk die uitsondering dan so eng uit as wat die instrument toelaat, byvoorbeeld met nftables-reëls wat die segment en die poortpaar noem en die algemene weiering daarna plaas:

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 evalueer in volgorde en stop by die eerste passing, so die afgebakende toelating moet bo die algemene weiering sit. Draai die twee om en die uitsondering doen stilweg niks.

Valideer die funksie en die weiering

Voer die goedgekeurde validering op 'n gewone Wi-Fi-oproep uit, vanaf die toestelklas waarvoor die uitsondering bestaan, en bevestig dat 'n uitgeslote kliënt steeds misluk. Moet onder geen omstandighede noodoproepe as toetsgeval gebruik nie. Inspekteer dan die reël wat uitgestuur is, want 'n teller wat op nul vassteek is die vinnigste bewys dat die uitsondering nooit gepas het nie:

nft -a list chain inet edge forward

Sluit 'n herverbinding of 'n netwerkverandering by die toets in, en herhaal dit vanaf 'n koue begin waarin die selfoon by die netwerk aansluit eerder as reeds aangeheg is. As die teller beweeg terwyl oproepe steeds misluk, het die probleem die vuurmuur verlaat en hoort dit by die netwerk se bestemmingslys.