Blokkere IPsec utan å øydeleggje Wi-Fi Calling på telefonen

Førespurnaden kjem alltid i same form: lukk IPsec ved kanten fordi det ber tunnelar ingen har godkjent, og den første klaga kjem frå nokon sin telefon slutta å ringje over Wi-Fi. Begge fakta er sanne samstundes, og ingen av dei rettferdiggjer å sleppe taket i kontrollen. Det brannmuren treng, er eit tenesteunntak med namngitt funksjon, avgrensa kjelde, dokumenterte destinasjonar og ein eigar. Fem steg gjer det til ei regel ein framand kan revidere neste år.

Namngi tenesta før du namngir protokollen

Ein bordtelefon på ei SIP-teneste og eit handsett som køyrer Wi-Fi Calling til operatøren deler ikkje nettverksprofil, og VoIP som brannmurterm skildrar ingen av dei. Port- og destinasjonsdata må kome frå leverandøren eller operatøren som driv tenesta, ikkje frå ei hugsa portliste som høyrer til eit anna telefonsystem. Det er skilnaden på ei regel som vernar ein funksjon og ei regel som vernar eit ord.

Apple si oversikt over tenesteportar listar UDP 500 og 4500 for Wi-Fi Calling, som tilfeldigvis er nøyaktig paret dei fleste breie IPsec-blokkeringar droppar. Skriv funksjonsnamnet i endringsregisteret ved sida av desse portane. Legg til versjonen eller datoen for oversikta du brukte, fordi leverandørtabellar blir redigerte. Ei regel som namngir tenesta ho finst for, kan reviderast; ei som namngir ein protokollkategori, kan ikkje.

Skriv unntaket som ein kontrakt, ikkje ei teneste

Unntaket angir den tillatne funksjonen, einingklassane som brukar han, transporten han treng og destinasjonane den ansvarlege parten dokumenterer. Det ber òg ein eigar og ein revisjonsdato, fordi endepunkta til operatøren og handsettmodellar endrar seg utan å varsle brannmurteamet. Gi revisjonen til ein person i staden for eit teamnamn som vil overleve teamet. Hald formuleringa så spesifikk at ein framand kan utleie regla berre frå registeret.

Legg unntaket i same syklus som resten av kantpolitikken, slik at ein operatør som flyttar ein destinasjon, eller ein flåte som byter handsettmodell, blir lagt merke til ved revisjonen og ikkje ved neste avbrot. Lukk sirkelen med den som melde dei øydelagde samtalane, fordi berre den kan stadfeste rettinga utan å opne tunnelen blokkeringa skulle lukke att. Den stadfestinga høyrer òg i registeret, med ein dato.

Ei permanent løyve merkt som ein mellombels telefonreparasjon er uforsvarleg to år seinare. Eit løyve knytt til ei identifisert teneste har ein utløpsdato som blir fornya med vilje.

Avgrens kjelda ærleg

Å avgrense unntaket til eit administrert einingsegment er vesentleg sterkare enn å opne protokollen for kvar berebar datamaskin i bygget. Viss nettverket ikkje kan identifisere det segmentet, skriv det ned i staden for å antyde at regla kjenner einingane. Det billegaste gode resultatet er å bruke om att ei grense som alt finst av ein annan grunn, slik at unntaket arvar ein kontroll i staden for å finne opp ein. Filtrering etter adresse er ikkje einingautentisering, og endringsregisteret bør ikkje antyde noko anna.

Ei kjeldeadresse eller ei maskinvareadresse er ikkje prov på eit fysisk handsett. Om nokon av dei har meining, heng heilt på dei andre kontrollane i det segmentet. Viss argumentet for regla kviler på ei MAC-adresse, undersøk kva som hindrar ein brukar i å endre ho før regla blir send ut.

Godta kva ei portregel ikkje kan fortelje deg

Portar identifiserer transportendepunkt, ikkje forretningshensikt. Når ei godkjend samtaleteneste og ein ikkje-godkjend tunnel begge går over UDP 4500, skil ingen portbasert regel dei. Ei regel som hevdar å gjere det, ser presis ut og er det ikkje, noko som er verre enn ei regel som vedgår si eiga form. Det er ei avgrensing i mekanismen, ikkje ein feil av personen som skreiv han.

Sei det ved sida av regla, og kople unntaket til den handhevinga nettverket har, slik som einingstyring eller ei liste over tillatne destinasjonar. Uttrykk deretter unntaket så smalt som verktøyet tillèt, til dømes med nftables-reglar som namngir segmentet og portparet og set den generelle avvisinga etter dei:

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 rekkjefølgje og stoppar ved første treff, så den avgrensa tillatinga må stå over den generelle avvisinga. Snu dei to, og unntaket gjer stille ingenting.

Valider funksjonen og avvisinga

Køyr den godkjende valideringa på ein vanleg Wi-Fi-samtale, frå einingklassen unntaket finst for, og stadfest at ein utelukka klient framleis feilar. Bruk aldri naudsamtalar som testtilfelle under noko omstende. Undersøk så regla som vart send ut, fordi ein teljar som står fast på null er det raskaste provet på at unntaket aldri trefte:

nft -a list chain inet edge forward

Ta med ei ny tilkopling eller ei nettverksendring i testen, og gjer han om att frå ein kald start der telefonen koplar seg til nettverket i staden for alt å vere tilkopla. Viss teljaren flyttar seg medan samtalane framleis feilar, har problemet forlate brannmuren og høyrer til destinasjonslista til operatøren.