Blockera IPsec utan att bryta telefonens Wi-Fi Calling

Begäran kommer alltid i samma form: stäng IPsec vid kanten eftersom det bär tunnlar som ingen har godkänt, och det första klagomålet kommer från någon vars telefon slutade ringa över Wi-Fi. Båda fakta är sanna samtidigt, och ingen av dem rättfärdigar att släppa kontrollen. Det brandväggen behöver är ett tjänsteundantag med namngiven funktion, avgränsad källa, dokumenterade destinationer och en ägare. Fem steg gör det till en regel som en främling kan granska nästa år.

Namnge tjänsten innan du namnger protokollet

En bordstelefon på en SIP-tjänst och en apparat som utför operatörens Wi-Fi Calling delar inte nätverksprofil, och VoIP som brandväggsterm beskriver ingen av dem. Port- och destinationsdata måste komma från leverantören eller operatören som driver tjänsten, inte från en ihågkommen portlista som tillhör ett annat telefonsystem. Det är skillnaden mellan en regel som skyddar en funktion och en regel som skyddar ett ord.

Apples översikt över tjänsteportar listar UDP 500 och 4500 för Wi-Fi Calling, vilket råkar vara exakt det par som de flesta breda IPsec-blockeringar tappar. Skriv funktionsnamnet i ändringsregistret bredvid de portarna. Lägg till versionen eller datumet för översikten du använde, eftersom leverantörstabeller redigeras. En regel som namnger tjänsten den finns för kan granskas; en som namnger en protokollkategori kan inte.

Skriv undantaget som ett avtal, inte som en tjänst

Undantaget anger den tillåtna funktionen, de enhetsklasser som använder den, den transport som behövs och de destinationer som den ansvariga parten dokumenterar. Det bär också en ägare och ett granskningsdatum, eftersom operatörens ändpunkter och apparatmodeller ändras utan att brandväggsteamet informeras. Ge granskningen till en person i stället för ett teamnamn som överlever teamet. Håll formuleringen så specifik att en främling kan härleda regeln enbart från registret.

Lägg undantaget i samma cykel som resten av kantpolicyn, så att en operatör som flyttar en destination eller en flotta som byter apparatmodell upptäcks vid granskningen och inte vid nästa avbrott. Slut cirkeln med den som rapporterade de trasiga samtalen, eftersom bara den kan bekräfta rättelsen utan att öppna tunneln som blockeringen skulle stänga igen. Den bekräftelsen hör också hemma i registret, med ett datum.

Ett permanent tillstånd märkt som en tillfällig telefonreparation är oförsvarligt två år senare. Ett tillstånd knutet till en identifierad tjänst har ett utgångsdatum som förnyas med avsikt.

Avgränsa källan ärligt

Att begränsa undantaget till ett hanterat enhetssegment är väsentligt starkare än att öppna protokollet för varje bärbar dator i byggnaden. Om nätverket inte kan identifiera segmentet, skriv det i stället för att antyda att regeln känner enheterna. Det billigaste goda resultatet är att återanvända en gräns som redan finns av en annan anledning, så undantaget ärver en kontroll i stället för att uppfinna en. Filtrering på adress är inte enhetsautentisering, och ändringsregistret bör inte antyda något annat.

En källadress eller en maskinvaruadress är inte bevis på en fysisk apparat. Om någon av dem har betydelse beror helt på de andra kontrollerna i det segmentet. Om argumentet för regeln vilar på en MAC-adress, kontrollera vad som hindrar en användare från att ändra den innan regeln släpps.

Acceptera vad en portregel inte kan säga

Portar identifierar transportändpunkter, inte affärsavsikt. När en godkänd samtaltjänst och en icke godkänd tunnel båda går över UDP 4500 skiljer ingen portbaserad regel dem. En regel som hävdar att den gör det ser exakt ut och är det inte, vilket är värre än en regel som erkänner sin egen form. Det är en begränsning i mekanismen, inte ett fel av personen som skrev den.

Säg det bredvid regeln och koppla undantaget till vilken tillämpning nätverket än har, som enhetshantering eller en lista över tillåtna destinationer. Uttryck sedan undantaget så snävt som verktyget tillåter, till exempel med nftables-regler som namnger segmentet och portparet och lägger det allmänna avslaget efter dem:

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 utvärderar i ordning och stannar vid första träffen, så det avgränsade tillståndet måste stå ovanför det allmänna avslaget. Byt plats på dem och undantaget gör tyst ingenting.

Validera funktionen och avslaget

Kör den godkända valideringen på ett vanligt Wi-Fi-samtal, från den enhetsklass undantaget finns för, och bekräfta att en utesluten klient fortfarande misslyckas. Använd aldrig nödsamtal som testfall under några omständigheter. Inspektera sedan regeln som släpptes, eftersom en räknare som fastnat på noll är det snabbaste beviset på att undantaget aldrig matchade:

nft -a list chain inet edge forward

Ta med en återanslutning eller en nätverksändring i testet, och upprepa det från en kallstart där telefonen ansluter till nätverket i stället för att redan vara ansluten. Om räknaren rör sig medan samtalen fortfarande misslyckas har problemet lämnat brandväggen och hör till operatörens destinationslista.