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

VPN серверот работи, клиентот истекува, а првиот импулс е да се додаде правило што дозволува сè во безбедносната група. Тоа понекогаш го прави да работи, и тоа е најлошиот исход, бидејќи сега никој не знае која граница всушност е затворена. Четири одделни филтри стојат меѓу клиентот и демонот, и само еден од нив е безбедносната група.

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

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

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

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

Безбедносните групи чуваат состојба; подмрежните ACL не

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

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

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

Хост-огнениот ѕид е одделна граница

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

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

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

Дозволувањето на слушачот не е рутирање на клиентите

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

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

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

Задржете пат за враќање, потоа стеснете го правилото

Пред да ја смените политиката на оддалечениот огнен ѕид, потврдете дека постои независен пат за управување, како менаџер на сесии, сериска конзола или вонпојасен мрежен пат. Ако единствениот пат за управување оди низ правилото што го уредувате, немате враќање. Потоа примените го тесното правило, тестирајте од вистински клиент и поврзете го обидот со докази од страната на серверот. Одговор од друга услуга на истата машина не е доказ дека слушачот е достигнат.

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

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