Blokkere IPsec uten å ødelegge telefonens Wi-Fi Calling

Forespørselen kommer alltid i samme form: lukk IPsec ved kanten fordi det bærer tunneler ingen har godkjent, og den første klagen kommer fra noen hvis telefon sluttet å ringe over Wi-Fi. Begge fakta er sanne samtidig, og ingen av dem rettferdiggjør å gi slipp på kontrollen. Det brannmuren trenger, er et tjenesteunntak med navngitt funksjon, avgrenset kilde, dokumenterte destinasjoner og en eier. Fem trinn gjør det til en regel en fremmed kan revidere neste år.

Navngi tjenesten før du navngir protokollen

En bordtelefon på en SIP-tjeneste og et håndsett som kjører operatørens Wi-Fi Calling deler ikke nettverksprofil, og VoIP som brannmurterm beskriver ingen av dem. Port- og destinasjonsdata må komme fra leverandøren eller operatøren som driver tjenesten, ikke fra en husket portliste som tilhører et annet telefonsystem. Det er forskjellen på en regel som beskytter en funksjon og en regel som beskytter et ord.

Apples oversikt over tjenesteportene lister UDP 500 og 4500 for Wi-Fi Calling, som tilfeldigvis er nøyaktig paret de fleste brede IPsec-blokkeringer dropper. Skriv funksjonsnavnet i endringsregistret ved siden av disse portene. Legg til versjonen eller datoen for oversikten du brukte, fordi leverandørtabeller redigeres. En regel som navngir tjenesten den finnes for, kan revideres; en som navngir en protokollkategori, kan ikke.

Skriv unntaket som en kontrakt, ikke en tjeneste

Unntaket angir den tillatte funksjonen, enhetsklassene som bruker den, transporten den trenger og destinasjonene den ansvarlige parten dokumenterer. Det bærer også en eier og en revisjonsdato, fordi operatørens endepunkter og håndsettmodeller endres uten å varsle brannmurteamet. Gi revisjonen til en person i stedet for et teamnavn som vil overleve teamet. Hold formuleringen så spesifikk at en fremmed kan utlede regelen bare fra registret.

Legg unntaket i samme syklus som resten av kantpolitikken, slik at en operatør som flytter en destinasjon, eller en flåte som bytter håndsettmodell, blir lagt merke til ved revisjonen og ikke ved neste avbrudd. Lukk sirkelen med den som meldte de ødelagte samtalene, fordi bare den kan bekrefte rettelsen uten å åpne tunnelen blokkeringen skulle lukke igjen. Den bekreftelsen hører også i registret, med en dato.

En permanent tillatelse merket som en midlertidig telefonreparasjon er uforsvarlig to år senere. En tillatelse knyttet til en identifisert tjeneste har en utløpsdato som fornyes med vilje.

Avgrens kilden ærlig

Å begrense unntaket til et administrert enhetssegment er vesentlig sterkere enn å åpne protokollen for hver bærbar datamaskin i bygget. Hvis nettverket ikke kan identifisere det segmentet, skriv det ned i stedet for å antyde at regelen kjenner enhetene. Det billigste gode resultatet er å gjenbruke en grense som allerede finnes av en annen grunn, slik at unntaket arver en kontroll i stedet for å finne opp en. Filtrering etter adresse er ikke enhetsautentisering, og endringsregistret bør ikke antyde noe annet.

En kildeadresse eller en maskinvareadresse er ikke bevis på et fysisk håndsett. Om noen av dem har betydning, avhenger helt av de andre kontrollene i det segmentet. Hvis argumentet for regelen hviler på en MAC-adresse, undersøk hva som hindrer en bruker i å endre den før regelen sendes ut.

Aksepter hva en portregel ikke kan fortelle deg

Porter identifiserer transportendepunkter, ikke forretningshensikt. Når en godkjent samtaletjeneste og en ikke-godkjent tunnel begge går over UDP 4500, skiller ingen portbasert regel dem. En regel som hevder å gjøre det, ser presis ut og er det ikke, noe som er verre enn en regel som innrømmer sin egen form. Det er en begrensning i mekanismen, ikke en feil av personen som skrev den.

Si det ved siden av regelen, og koble unntaket til den håndhevelsen nettverket har, slik som enhetsstyring eller en liste over tillatte destinasjoner. Uttrykk deretter unntaket så smalt som verktøyet tillater, for eksempel med nftables-regler som navngir segmentet og portparet og setter den generelle avvisningen etter 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 vurderer i rekkefølge og stopper ved første treff, så den avgrensede tillatelsen må stå over den generelle avvisningen. Snu de to, og unntaket gjør stille ingenting.

Valider funksjonen og avvisningen

Kjør den godkjente valideringen på en vanlig Wi-Fi-samtale, fra enhetsklassen unntaket finnes for, og bekreft at en utelukket klient fortsatt feiler. Bruk aldri nødsamtaler som testtilfelle under noen omstendighet. Undersøk så regelen som ble sendt ut, fordi en teller som står fast på null er det raskeste beviset på at unntaket aldri traff:

nft -a list chain inet edge forward

Ta med en ny tilkobling eller en nettverksendring i testen, og gjenta den fra en kald start der telefonen kobler seg til nettverket i stedet for allerede å være tilkoblet. Hvis telleren beveger seg mens samtalene fortsatt feiler, har problemet forlatt brannmuren og hører til operatørens destinasjonsliste.