Облачна група за сигурност за VPN: отворете слушателя, не всичко

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

Назовете протокола преди правилото

Правилото е протокол, диапазон от портове и източник. WireGuard слуша на UDP, обикновено 51820. OpenVPN обикновено е UDP или TCP 1194 в зависимост от конфигурацията. IPsec се нуждае от IKE обмен на UDP 500 и 4500 плюс самия ESP протокол, който е номер на протокол, а не порт. Да се предполага TCP, защото другите правила са TCP, е начинът да се получи правило, което изглежда правилно и не съвпада с нищо.

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

Ограничете източника до клиентския диапазон, който дизайнът позволява, вместо целия интернет.

Групите за сигурност пазят състояние; ACL на подмрежата — не

Групите за сигурност пазят състояние и само разрешават: разрешеният входящ поток получава отговорите си автоматично и няма правило за отказ, за което да се мисли. ACL на подмрежата не пазят състояние и се оценяват в двете посоки, така че входящо разрешение без съответния изходящ ефимерен диапазон пак се проваля. Тази разлика обяснява много правила, които изглеждат верни в конзолата.

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

Ефективната политика е обединението на прикаченото, а не файлът, който редактирахте.

Хост-файъруолът е отделна граница

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

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

Заснемане на интерфейса ви казва коя граница е изпуснала пакета.

Да допуснете слушателя не значи да рутирате клиентите

VPN шлюз, който препраща клиентски трафик, се нуждае от повече от отворен порт. Нужно е IP препращане, политика, разрешаваща потока от тунелния интерфейс към целевата мрежа, и често изключена проверка на източник и дестинация на интерфейса, за да не изхвърля платформата трафик, който не е адресиран до нея. Нищо от това не се създава от правилото за слушателя.

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

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

Запазете път за връщане, после стеснете правилото

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

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

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