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

VPN сервер ради, клијент истиче, а прва помисао је додати правило које дозвољава све у безбедносну групу. То понекад проради, и то је најгори исход, јер сада нико не зна која је граница заправо затворена. Четири одвојена филтера стоје између клијента и демона, а само један од њих је безбедносна група.

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

Правило је протокол, распон портова и извор. WireGuard слуша на UDP, обично 51820. OpenVPN је обично UDP или TCP 1194 зависно од конфигурације. IPsec тражи IKE размену на UDP 500 и 4500 плус сам ESP протокол, који је број протокола, а не порт. Погађање TCP-а зато што су друга правила TCP води до правила које изгледа исправно и не одговара ничему.

Читајте слушаоца из покренуте услуге, не из туторијала. Демон везан на једну адресу неће прихватити саобраћај који стигне на другу.

Ограничите извор на распон клијената који дизајн дозвољава, уместо на цео интернет.

Безбедносне групе памте стање; подмрежни ACL-и не

Безбедносне групе памте стање и само дозвољавају: дозвољени долазни ток аутоматски добија одговоре, и нема правила одбијања о коме треба размишљати. Подмрежни ACL-и не памте стање и оцењују се у оба смера, па долазно дозвољавање без одговарајућег одлазног ефемерног распона и даље пада. Та разлика објашњава многа правила која у конзоли изгледају исправно.

Потврдите и која је политика придружена покренутом крајњем скупу, јер инстанца може имати више група, а правило у непридруженој групи не мења ништа.

Ефективна политика је унија онога што је придружено, а не датотека коју сте уредили.

Хост фиревал је одвојена граница

Облачна политика пропушта саобраћај до мрежног интерфејса, а затим оперативни систем одлучује да ли ће га демон видети. Хост фиревал са подразумеваном политиком одбијања ће одбацити пакет који је безбедносна група дозволила, а облачна конзола неће показати одбијање јер никада није имала мишљење. Проверите обоје, редом којим пакет наилази на њих.

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

Снимак на интерфејсу вам каже која је граница одбацила пакет.

Допуштање слушаоца није исто као рутирање клијената

VPN пролаз који прослеђује клијентски саобраћај тражи више од отвореног порта. Тражи IP прослеђивање, политику која дозвољава ток од тунелског интерфејса до одредишне мреже, и често искључену проверу извора и одредишта на интерфејсу да платформа не одбаци саобраћај који није упућен њој. Ништа од тога не ствара правило за слушаоца.

Овде се разилазе радно руковање и покварена податковна путања, и зато статус тунела може изгледати здрав док се ништа не учитава.

Поправите рутирање као одвојену промену са сопственом провером и запазите да пролаз који прослеђује треба и излазну политику која дозвољава одредиште.

Оставите пут за повратак, па сузите правило

Пре промене удаљене фиревал политике, потврдите да постоји независна путања управљања, као што је управник сесија, серијска конзола или ванмрежна мрежа. Ако једина путања управљања иде кроз правило које уређујете, немате опоравак. Затим примените уско правило, тестирајте са стварног клијента и повежите покушај са доказима на страни сервера. Одговор друге услуге на истом строју није доказ да је слушалац достигнут.

Уклоните свако експериментално широко дозвољавање чим уско проради, и забележите зашто правило постоји. AWS документује понашање безбедносних група са памћењем стања, и тај документ треба цитирати када неко предложи широк распон као пречицу.

Документујте и придруживање, иначе ће заменски интерфејс тихо изгубити политику.