IPsec blokkolása a telefon Wi-Fi Calling szolgáltatásának tönkretétele nélkül

A kérés mindig ugyanabban a formában érkezik: zárják le az IPsec-et a peremen, mert olyan alagutakat szállít, amelyeket senki sem hagyott jóvá, és az első panasz attól érkezik, akinek a telefonja abbahagyta a Wi-Fi hívásokat. Mindkét tény egyszerre igaz, és egyik sem indokolja a kontroll feladását. A tűzfalnak nevesített funkcióval, korlátozott forrással, dokumentált célokkal és felelőssel rendelkező szolgáltatáskivételre van szüksége. Öt lépés olyan szabállyá alakítja, amelyet egy idegen jövőre felülvizsgálhat.

Nevezze meg a szolgáltatást, mielőtt a protokollt nevezné meg

A SIP szolgáltatáson futó asztali telefon és a szolgáltató Wi-Fi Callingját végző készülék nem osztozik hálózati profilon, és a VoIP tűzfalszakkifejezésként egyiket sem írja le. A port- és céladatokat attól a szállítótól vagy szolgáltatótól kell kapni, amely a szolgáltatást üzemelteti, nem egy másik telefonrendszerhez tartozó, emlékezetből idézett portlistából. Ez a különbség a funkciót védő szabály és a szót védő szabály között.

Az Apple szolgáltatási portokról szóló referenciája UDP 500 és 4500 portot sorol fel a Wi-Fi Callinghez, ami épp az a páros, amelyet a legtöbb átfogó IPsec-tiltás kihagy. Írja be a funkció nevét a változási rekordba e portok mellé. Adja hozzá a használt referencia verzióját vagy dátumát, mert a szállítói táblázatok szerkesztődnek. A szabály, amely megnevezi a szolgáltatást, amelyért létezik, felülvizsgálható; amelyik protokollkategóriát nevez meg, nem.

Írja a kivételt szerződésként, nem szívességként

A kivétel megadja az engedélyezett funkciót, az azt használó eszközosztályokat, a szükséges átvitelt és azokat a célokat, amelyeket a felelős fél dokumentál. Felelőst és felülvizsgálati dátumot is tartalmaz, mert a szolgáltató végpontjai és a készülékmodellek anélkül változnak, hogy értesítenék a tűzfal csapatát. A felülvizsgálatot személynek adja, ne olyan csapatnévnek, amely túl fogja élni a csapatot. Tartsa a megfogalmazást elég konkrétnak ahhoz, hogy egy idegen csak a rekordból levezethesse a szabályt.

Helyezze a kivételt ugyanabba a ciklusba, mint a perem többi szabályzatát, hogy a szolgáltató célpontáthelyezése vagy a flotta készülékmodell-váltása a felülvizsgálatnál tűnjön fel, ne a következő kiesésnél. Zárja a kört azzal, aki a megszakadt hívásokat jelentette, mert csak ő tudja megerősíteni a javítást anélkül, hogy újra megnyitná az alagutat, amelyet a tiltásnak be kellett volna zárnia. Ennek a megerősítésnek is a rekordban a helye, dátummal.

Az ideiglenes telefonjavításként címkézett állandó engedély két év múlva nem védhető. Az azonosított szolgáltatáshoz kötött engedélynek lejárata van, amelyet szándékosan újítanak meg.

Határolja be a forrást őszintén

A kivételt kezelt eszközszegmensre korlátozni lényegesen erősebb, mint a protokollt minden épületbeli laptop előtt megnyitni. Ha a hálózat nem tudja azonosítani ezt a szegmenst, írja le, ahelyett hogy azt sugallná, a szabály ismeri az eszközöket. A legolcsóbb jó eredmény egy más okból már létező határ újrafelhasználása, így a kivétel örököl egy kontrollt ahelyett, hogy kitalálna egyet. A cím szerinti szűrés nem eszközhitelesítés, és a változási rekordnak nem szabad mást sugallnia.

A forráscím vagy a hardvercím nem bizonyíték fizikai készülékre. Hogy bármelyiknek van-e jelentése, teljes mértékben az adott szegmensen belüli többi kontrolltól függ. Ha a szabály érve MAC-címen nyugszik, ellenőrizze, mi akadályozza a felhasználót a módosításában, mielőtt a szabály kimegy.

Fogadja el, amit egy portszabály nem tud megmondani

A portok átviteli végpontokat azonosítanak, nem üzleti szándékot. Ha egy jóváhagyott hívászolgáltatás és egy nem jóváhagyott alagút is UDP 4500-on jár, egyetlen portalapú szabály sem választja szét őket. Az a szabály, amely ezt állítja, pontosnak látszik és nem az, ami rosszabb, mint egy szabály, amely elismeri a saját formáját. Ez a mechanizmus korlátja, nem a leíró hibája.

Mondja ezt a szabály mellé, és párosítsa a kivételt azzal a kényszerítéssel, amellyel a hálózat rendelkezik, például eszközkezeléssel vagy engedélyezett célok listájával. Ezután fejezze ki a kivételt a lehető legszűkebben, például nftables szabályokkal, amelyek megnevezik a szegmenst és a portpárt, és az általános tiltást mögéjük teszik:

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

Az nftables sorrendben értékel és az első egyezésnél megáll, ezért a szűk engedélyezésnek az általános tiltás fölött kell lennie. Cserélje fel a kettőt, és a kivétel csendben semmit nem tesz.

Érvényesítse a funkciót és a tiltást

Futtassa a jóváhagyott ellenőrzést egy hétköznapi Wi-Fi híváson, abból az eszközosztályból, amelyre a kivétel létezik, és erősítse meg, hogy egy kizárt kliens továbbra is meghiúsul. Soha, semmilyen körülmények között ne használjon segélyhívást tesztesetként. Ezután vizsgálja meg a kiment szabályt, mert a nullán ragadt számláló a leggyorsabb bizonyíték arra, hogy a kivétel soha nem egyezett:

nft -a list chain inet edge forward

Vegye be a tesztbe az újracsatlakozást vagy a hálózatváltást, és ismételje meg hideg indításból, amikor a telefon csatlakozik a hálózathoz, nem pedig már csatlakozva van. Ha a számláló mozdul, miközben a hívások továbbra is meghiúsulnak, a probléma elhagyta a tűzfalat, és a szolgáltató célcím-listájához tartozik.