VPN клиенти и локалната мрежа: кога да използвате отделна зона

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

Името на зоната не шифрова нищо и не удостоверява потребител. То само групира интерфейси за модела на правилата на защитната стена.

Какво всъщност контролира членството в зона

Зоната групира интерфейси или трафик в модела на защитната стена. След това нейните настройки за вход, изход и препращане управляват различни роли. Входът е трафик към самия рутер; препращането е трафик през него към друг хост. Документацията на OpenWrt за зоните разглежда входа, изхода и препращането като отделни настройки точно поради тази причина.

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

Това разграничение е причината отделната зона да е полезна: можете да посочите всяка посока и всяка роля изрично. Записвайте посоката до всяко правило.

Решение първо: вход, препращане или и двете

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

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

Решение второ: какви ресурси са нужни на отдалечените клиенти

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

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

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

Решение трето: как ще докажете границата

Тествайте разрешен поток и умишлено отказан такъв след всяка промяна. Доказването, че един сайт се зарежда, не разкрива неволно широко разрешение. Тествайте от адресния диапазон на VPN клиента, не от локалната мрежа, и включете посоката, в която очаквате отказ. Запишете двата резултата до правилото.

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

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