Трафик от VPN клиента и състояние на защитната стена: външен и вътрешен поток

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

Докато не разделите тези две неща, всяка промяна на правило е догадка.

Защитната стена вижда два различни пакета

Преди декапсулирането защитната стена вижда трафик, адресиран до крайната точка на VPN: външен поток UDP към слушателя. След декапсулирането препратеният пакет носи вътрешния адрес на клиента и дестинацията на услугата.

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

Сравнете прихващания от еквивалентни позиции от двете страни. Прихващане на ръба на тунела и прихващане на сървъра показват различни кортежи за една и съща сесия.

Решение първо: разрешаване на тунела или на услугата

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

Дръжте обхвата на клиента и обхвата на услугата тесни. Разрешение от подмрежата на тунела към цялата локална мрежа е решение да се доверявате на всеки хост, а не пряк път за едно приложение.

Запишете двете правила поотделно. Правилото за тунела и правилото за услугата се провалят по различни начини и се отстраняват с различни доказателства. Когато едното се провали, знаете кой слой да проверите първо.

Решение второ: със или без следене на състояние на всяка граница

Правило за установен поток може да допуска отговори за разрешен обмен, но поведението му зависи от продукта. Облачна група за сигурност обикновено следи състояние; списък за контрол на достъпа за подмрежа често не следи състояние и изисква явна обработка в двете посоки. Не приемайте, че всяка граница по пътя третира състоянието по един и същ начин. Изброeте всяка граница и я отбележете със или без следене на състояние, преди да проектирате правилата.

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

Тествайте с нова контролирана заявка и проверете съответните броячи. Чистият тест е по-добър от смущаващо нулиране. Запишете името на брояча в записа за промяната, така че следващият тест да използва същите доказателства.

Проверете обратния път при същата политика

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

Дръжте предвидения обхват на клиента и обхвата на услугата тесни и проверете обратния път при същия набор правила, който разреши заявката. Правило, което работи само защото стар поток е още отворен, не е работещо правило.