Blokér IPsec uden at ødelægge telefonens Wi-Fi Calling

Anmodningen kommer altid i samme form: luk IPsec ved kanten, fordi det bærer tunneller, som ingen har godkendt, og den første klage kommer fra en person, hvis telefon holdt op med at ringe over Wi-Fi. Begge fakta er sande på samme tid, og ingen af dem retfærdiggør at opgive kontrollen. Det, firemuren har brug for, er en tjenesteundtagelse med en navngivet funktion, en afgrænset kilde, dokumenterede destinationer og en ejer. Fem trin gør det til en regel, som en fremmed kan revidere næste år.

Navngiv tjenesten, før du navngiver protokollen

En bordtelefon på en SIP-tjeneste og et håndsæt, der kører operatørens Wi-Fi Calling, deler ikke netværksprofil, og VoIP som firewallbegreb beskriver ingen af dem. Port- og destinationsdata skal komme fra den leverandør eller operatør, der driver tjenesten, ikke fra en husket portliste, der tilhører et andet telefonsystem. Det er forskellen på en regel, der beskytter en funktion, og en regel, der beskytter et ord.

Apples oversigt over tjenesteporte viser UDP 500 og 4500 til Wi-Fi Calling, hvilket tilfældigvis er præcis det par, som de fleste brede IPsec-blokeringer dropper. Skriv funktionens navn i ændringsregistret ved siden af disse porte. Tilføj versionen eller datoen for den oversigt, du brugte, fordi leverandørernes tabeller redigeres. En regel, der navngiver den tjeneste, den findes for, kan revideres; en, der navngiver en protokolktategori, kan ikke.

Skriv undtagelsen som en kontrakt, ikke en tjeneste

Undtagelsen angiver den tilladte funktion, de enhedsklasser, der bruger den, den transport, den har brug for, og de destinationer, som den ansvarlige part dokumenterer. Den bærer også en ejer og en revisionsdato, fordi operatørens endepunkter og håndsætmodeller ændrer sig uden at fortælle firewallteamet det. Giv revisionen til en person i stedet for et teamnavn, der overlever teamet. Hold formuleringen så specifik, at en fremmed kan udlede reglen alene ud fra registret.

Læg undtagelsen i samme cyklus som resten af kantpolitikken, så en operatør, der flytter en destination, eller en flåde, der skifter håndsætmodel, bliver bemærket ved revisionen i stedet for ved næste afbrydelse. Luk kredsen med den, der indberettede de brudte opkald, da vedkommende er den eneste, der kan bekræfte rettelsen uden at genåbne den tunnel, som blokeringen skulle lukke. Den bekræftelse hører også i registret, med en dato.

En permanent tilladelse mærket som en midlertidig telefonrettelse er uforsvarlig to år senere. En tilladelse bundet til en identificeret tjeneste har en udløbsdato, der fornyes med vilje.

Afgræns kilden ærligt

At begrænse undtagelsen til et administreret enhedssegment er væsentligt stærkere end at åbne protokollen for hver bærbar computer i bygningen. Hvis netværket ikke kan identificere det segment, så skriv det i stedet for at antyde, at reglen er enhedsbevidst. Det billigste gode resultat er at genbruge en grænse, der allerede findes af en anden grund, så undtagelsen arver en kontrol i stedet for at opfinde en. Filtrering efter adresse er ikke enhedsautentifikation, og ændringsregistret bør ikke antyde andet.

En kildeadresse eller en hardwareadresse er ikke bevis på et fysisk håndsæt. Om nogen af dem har betydning, afhænger fuldstændigt af de andre kontroller i det segment. Hvis argumentet for reglen hviler på en MAC-adresse, så undersøg, hvad der forhindrer en bruger i at ændre den, før reglen sendes ud.

Accepter, hvad en portregel ikke kan fortælle dig

Porte identificerer transportendepunkter, ikke forretningsmæssig hensigt. Når en godkendt opkaldstjeneste og en ikke-godkendt tunnel begge kører på UDP 4500, skiller ingen portbaseret regel dem. En regel, der hævder at gøre det, ser præcis ud og er det ikke, hvilket er værre end en regel, der indrømmer sin egen form. Det er en begrænsning i mekanismen, ikke en fejl af personen, der skrev den.

Sig det ved siden af reglen, og par undtagelsen med den håndhævelse, netværket har, såsom enhedsstyring eller en liste over tilladte destinationer. Udtryk derefter undtagelsen så snævert, som værktøjet tillader, for eksempel med nftables-regler, der navngiver segmentet og portparet og lægger det generelle afslag 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 evaluerer i rækkefølge og stopper ved det første match, så den afgrænsede accept skal ligge over det generelle afslag. Byt dem om, og undtagelsen gør lydløst ingenting.

Validér funktionen og afslaget

Kør den godkendte validering på et almindeligt Wi-Fi-opkald fra den enhedsklasse, som undtagelsen findes for, og bekræft, at en udelukket klient stadig fejler. Brug aldrig nødopkald som testtilfælde under nogen omstændigheder. Undersøg derefter den regel, der blev sendt, fordi en tæller, der sidder fast på nul, er det hurtigste bevis på, at undtagelsen aldrig matchede:

nft -a list chain inet edge forward

Inkludér en genopkobling eller en netværksændring i testen, og gentag den fra en kold start, hvor telefonen tilslutter sig netværket i stedet for allerede at være tilkoblet. Hvis tælleren bevæger sig, mens opkald stadig fejler, har problemet forladt firemuren og hører til operatørens destinationsliste.