Заявката винаги идва в една и съща форма: затворете IPsec на ръба, защото пренася тунели, които никой не е одобрил, а първата жалба идва от човек, чийто телефон е спрял да провежда разговори през Wi-Fi. И двата факта са верни едновременно и нито един от тях не оправдава отказ от контрола. Това, което е нужно на защитната стена, е изключение за услуга с наименувана функция, ограничен източник, документирани дестинации и отговорник. Пет стъпки превръщат това в правило, което непознат може да прегледа след година.

Наименувайте услугата, преди да наименувате протокола

Настолен телефон на SIP услуга и апарат, който извършва Wi-Fi Calling на оператора, не споделят мрежов профил и VoIP като термин на защитната стена не описва нито един от тях. Данните за портове и дестинации трябва да идват от доставчика или оператора, който поддържа услугата, а не от запомнен списък с портове на друга телефонна система. Това е разликата между правило, което защитава функция, и правило, което защитава дума.

Справочникът на Apple за портове на услуги изброява UDP 500 и 4500 за Wi-Fi Calling, което се оказва точно двойката, която повечето цялостни блокировки на IPsec изхвърлят. Запишете името на функцията в записа за промяната до тези портове. Добавете версията или датата на справочника, който сте използвали, защото таблиците на доставчиците се редактират. Правило, което назовава услугата, за която съществува, може да бъде прегледано; такова, което назовава категория протокол, не може.

Напишете изключението като договор, не като услуга

Изключението посочва разрешената функция, класовете устройства, които я използват, транспорта, който ѝ е нужен, и дестинациите, които отговорната страна документира. То носи също отговорник и дата за преглед, защото крайните точки на оператора и моделите апарати се променят, без да уведомят екипа на защитната стена. Дайте прегледа на човек, а не на име на екип, което ще го надживее. Дръжте формулировката достатъчно конкретна, за да може непознат да изведе правилото само от записа.

Поставете изключението в същия цикъл като останалата политика на ръба, така че преместване на дестинация от оператора или смяна на модел в парка да бъде забелязано при прегледа, а не при следващия отказ. Затворете цикъла с този, който е съобщил за счупените разговори, защото той е единственият, който може да потвърди поправката, без да отваря отново тунела, който блокировката трябваше да затвори. Това потвърждение също принадлежи в записа, с дата.

Постоянно разрешение, обозначено като временна поправка на телефон, е незащитимо две години по-късно. Разрешение, свързано с конкретна услуга, има срок, който се подновява умишлено.

Ограничете източника честно

Ограничаването на изключението до управляван сегмент от устройства е съществено по-силно от отваряне на протокола за всеки лаптоп в сградата. Ако мрежата не може да идентифицира този сегмент, запишете го, вместо да внушавате, че правилото е съобразено с устройствата. Най-евтиният добър резултат е да използвате повторно граница, която вече съществува по друга причина, така че изключението наследява контрол, вместо да измисля такъв. Филтрирането по адрес не е удостоверяване на устройство и записът за промяната не бива да подсказва друго.

Адрес на източник или хардуерен адрес не е доказателство за физически апарат. Дали някой от тях има значение, зависи изцяло от другите контроли в този сегмент. Ако аргументът за правилото почива на MAC адрес, проверете какво пречи на потребителя да го смени, преди правилото да бъде пуснато.

Приемете какво не може да ви каже правило по порт

Портовете идентифицират крайни точки на транспорта, не бизнес намерение. Когато одобрена услуга за разговори и неодобрен тунел минават през един и същ UDP 4500, никое правило по порт не ги разделя. Правило, което твърди, че го прави, изглежда точно и не е, което е по-лошо от правило, което признава собствената си форма. Това е ограничение на механизма, а не грешка на човека, който го е написал.

Кажете го до правилото и съчетайте изключението с каквото прилагане мрежата има, например управление на устройства или списък с разрешени дестинации. След това изразете изключението възможно най-тясно, например с правила на nftables, които назовават сегмента и двойката портове и поставят общата забрана след тях:

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 оценява по ред и спира при първото съвпадение, така че ограниченото разрешение трябва да стои над общата забрана. Разменете двете и изключението тихо не прави нищо.

Валидирайте функцията и забраната

Извършете одобрената проверка на обикновен разговор през Wi-Fi, от класа устройства, за който съществува изключението, и потвърдете, че изключен клиент все още се проваля. Никога и при никакви обстоятелства не използвайте спешни разговори като тестов случай. След това прегледайте пуснатото правило, защото брояч, замръзнал на нула, е най-бързото доказателство, че изключението никога не е съвпадало:

nft -a list chain inet edge forward

Включете в теста повторно свързване или промяна на мрежата и го повторете от студен старт, когато телефонът се присъединява към мрежата, а не е вече свързан. Ако броячът се движи, а разговорите все още се провалят, проблемът е напуснал защитната стена и принадлежи на списъка с дестинации на оператора.

Подобни статии