IPsec blokkeren zonder de Wi-Fi Calling van de telefoon te breken

Het verzoek komt altijd in dezelfde vorm: sluit IPsec aan de rand omdat het tunnels vervoert die niemand heeft goedgekeurd, en de eerste klacht komt van iemand wiens telefoon geen gesprekken meer voert via Wi-Fi. Beide feiten zijn tegelijk waar, en geen van beide rechtvaardigt het opgeven van de controle. Wat de firewall nodig heeft, is een dienstuitzondering met een benoemde functie, een begrensde bron, gedocumenteerde bestemmingen en een eigenaar. Vijf stappen maken daar een regel van die een vreemde volgend jaar kan herzien.

Benoem de dienst voordat je het protocol benoemt

Een bureautelefoon op een SIP-dienst en een toestel dat de Wi-Fi Calling van de provider uitvoert, delen geen netwerkprofiel, en VoIP als firewallterm beschrijft geen van beide. Poort- en bestemmingsgegevens moeten van de leverancier of provider komen die de dienst beheert, niet uit een onthouden poortenlijst van een ander telefoonsysteem. Dat is het verschil tussen een regel die een functie beschermt en een regel die een woord beschermt.

Apples referentie voor dienstpoorten noemt UDP 500 en 4500 voor Wi-Fi Calling, precies het paar dat de meeste algehele IPsec-blokkades laten vallen. Schrijf de functienaam in het wijzigingsrecord naast die poorten. Voeg de versie of datum toe van de referentie die je gebruikte, want leverancierstabellen worden bewerkt. Een regel die de dienst benoemt waarvoor hij bestaat, kan worden herzien; een die een protocolcategorie benoemt, niet.

Schrijf de uitzondering als contract, niet als gunst

De uitzondering vermeldt de toegestane functie, de apparaatklassen die ervan gebruikmaken, het benodigde transport en de bestemmingen die de verantwoordelijke partij documenteert. Hij draagt ook een eigenaar en een herzieningsdatum, want provider-eindpunten en toestelmodellen veranderen zonder het firewallsysteem te informeren. Geef de herziening aan een persoon in plaats van aan een teamnaam die het team overleeft. Houd de formulering concreet genoeg dat een vreemde de regel uit het record alleen kan afleiden.

Zet de uitzondering in dezelfde cyclus als de rest van het randbeleid, zodat een provider die een bestemming verplaatst of een vloot die van toestelmodel wisselt bij de herziening opvalt en niet bij de volgende storing. Sluit de cirkel met degene die de kapotte gesprekken meldde, want alleen die kan de oplossing bevestigen zonder de tunnel te heropenen die de blokkade moest sluiten. Die bevestiging hoort ook in het record, met een datum.

Een permanente toestemming die als tijdelijke telefoonreparatie is bestempeld, is twee jaar later niet te verdedigen. Een toestemming die aan een geïdentificeerde dienst is gekoppeld, heeft een vervaldatum die bewust wordt verlengd.

Begrens de bron eerlijk

De uitzondering beperken tot een beheerd apparaatsegment is wezenlijk sterker dan het protocol openstellen voor elke laptop in het gebouw. Als het netwerk dat segment niet kan identificeren, schrijf dat op in plaats van te suggereren dat de regel de apparaten kent. Het goedkoopste goede resultaat is een grens hergebruiken die al om een andere reden bestaat, zodat de uitzondering een controle erft in plaats van er een te verzinnen. Filteren op adres is geen apparaatauthenticatie, en het wijzigingsrecord mag niets anders suggereren.

Een bronadres of een hardwareadres is geen bewijs van een fysiek toestel. Of een van beide betekenis heeft, hangt volledig af van de andere controles binnen dat segment. Als het argument voor de regel op een MAC-adres rust, controleer dan wat een gebruiker ervan weerhoudt het te wijzigen voordat de regel uitgaat.

Accepteer wat een poortregel je niet kan vertellen

Poorten identificeren transporteindpunten, geen zakelijke bedoeling. Wanneer een goedgekeurde beldienst en een niet-goedgekeurde tunnel beide over UDP 4500 gaan, scheidt geen enkele op poorten gebaseerde regel ze. Een regel die beweert dat te doen lijkt precies en is dat niet, wat erger is dan een regel die zijn eigen vorm toegeeft. Dat is een grens van het mechanisme, geen fout van de persoon die het schreef.

Zeg dat naast de regel, en koppel de uitzondering aan welke handhaving het netwerk ook heeft, zoals apparaatbeheer of een lijst met toegestane bestemmingen. Formuleer de uitzondering dan zo nauw als het gereedschap toestaat, bijvoorbeeld met nftables-regels die het segment en het poortpaar noemen en de algemene weigering daarna plaatsen:

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 evalueert op volgorde en stopt bij de eerste overeenkomst, dus de begrensde toestemming moet boven de algemene weigering staan. Draai ze om en de uitzondering doet stilzwijgend niets.

Valideer de functie en de weigering

Voer de goedgekeurde validatie uit op een gewoon Wi-Fi-gesprek, vanuit de apparaatklasse waarvoor de uitzondering bestaat, en bevestig dat een uitgesloten client nog steeds faalt. Gebruik onder geen enkele omstandigheid noodoproepen als testcase. Inspecteer daarna de regel die is uitgerold, want een teller die op nul blijft staan is het snelste bewijs dat de uitzondering nooit heeft gematcht:

nft -a list chain inet edge forward

Neem een herverbinding of een netwerkwijziging op in de test, en herhaal die vanuit een koude start waarbij de telefoon lid wordt van het netwerk in plaats van al verbonden te zijn. Beweegt de teller terwijl gesprekken nog steeds falen, dan heeft het probleem de firewall verlaten en hoort het bij de bestemmingslijst van de provider.