Где правило Android заштитног зида мора да стоји када је VPN укључен
Само један VpnService може бити активан, па се firewall апликација и VPN апликација не слажу у низ. Прођите кроз један радни захтев и сместите свако правило тамо где саобраћај заиста пролази.
Имате једну реченицу политике: ова апликација сме да достигне радни сервис и ништа друго. Следеће питање изгледа као избор производа, али је питање места, јер свака могућа тачка примене види други подскуп саобраћаја телефона. Gateway види само оно што улази у тунел. Филтер на телефону види само оно што му је дозвољено да посматра. Провлачење једног захтева кроз обе тачке чини одговор очигледним.
Почните од реченице, не од производа
Развијте захтев пре него што било шта изаберете. То значи пакет и профил у коме ради, јер је апликација у радном профилу други корисник од исте апликације у личном профилу. То значи одредиште: host, port и протокол, а не назив сервиса. То значи DNS путању која разрешава тај назив и значи шта треба да се догоди када тунел није доступан.
Записана, политика за пример има четири реда: радна апликација сме да достигне радни сервис; радна апликација не сме ништа друго; остале апликације су непромењене; без тунела радној апликацији се одбија приступ уместо да пређе на директну везу. Сваки ред има власника, и нису сви исти власник.
Корак 1: шта сам телефон може да примени
Android firewall без root права је VpnService који хвата саобраћај локално, чак и када иза њега нема удаљеног тунела. Android дозвољава само један активни VPN сервис по корисничком профилу, па се друга firewall апликација не надо везује на прву. Она је замењује, а интерфејс који је прва апликација филтрирала нестаје.
Зато инсталирање firewall-а поред VPN клијента ретко даје комбинацију коју људи очекују. Ако firewall крене а VPN се искључи, ништа није спојено; њих двоје су заменили места. Замена интерфејса није сарадња, а симптом је тунел који стално пада кад год се отвори друга апликација.
Подржани распореди ипак постоје: филтрирање уграђено у VPN клијент који већ користите, управљане платформске контроле кроз контролер политике уређаја или радни профил, или архитектура коју произвођач документује. Све остало је експеримент који мора изнова да се провери после сваког ажурирања апликације.
Корак 2: шта gateway може да примени
Када се саобраћај декриптује на другом крају, gateway може да ограничи прослеђене пакете на одобрене адресе, сервисе или аутентификоване VPN идентитете. То је стварна примена за све што излази кроз њега, и право место за ограничавање приступа приватним подмрежама.
Оно што не добија јесте идентитет апликације телефона везан за сваки обичан IP пакет. Неколико апликација које деле једну адресу тунела су један субјекат за gateway, осим ако им дизајн не да одвојене адресе или одвојене аутентификоване идентитете. Правило по кориснику на gateway-у зато није правило по апликацији на телефону, како год га конзола за управљање називала.
Корак 3: попишите шта никада не стиже
Апликација искључена из VPN-а која контактира оближњи уређај никада не стиже до gateway-а, па излазни firewall не може да одбије пакет који никада не прими. Исто важи за ненамерну директну руту током испада и за улазну изложеност на локалној приступној мрежи. То су локалне границе по дефиницији.
Важи и обрнуто: локално правило које дозвољава везу не даје приступ кроз ACL приватне мреже gateway-а. Један захтев може бити подложан обема границама, а испуњавање једне не говори ништа о другој.
Корак 4: доделите сваком правилу путању
Ставите одлуку у табелу пре него што било шта конфигуришете, јер су празне ћелије места на којима дизајни пропадају.
| Path | Who can enforce it | Blind spot |
|---|---|---|
| Work app to the work service, tunnel up | Gateway ACL on address and service, plus a local block on other paths | The gateway cannot see which app sent the packet |
| Work app to other destinations, tunnel up | Local app-aware filter, or the gateway if those destinations are addressed there | The local filter must be the active VpnService |
| Work app with no tunnel | Local deny, so the app cannot take a direct path | Requires the filter to survive the tunnel going away |
| Nearby LAN device | Local policy only | The gateway never sees it |
Облик који функционише су две границе са два посла. Локална граница свесна апликација управља понашањем телефона, укључујући директни fallback, а gateway граница управља удаљеним ресурсима. Страна gateway-а може да дозволи радни сервис и одбије сваку другу приватну подмрежу, док политика на телефону сама одлучује о директној путањи коју би апликација иначе могла да изабере.
Корак 5: одржите транспорт живим, па проверите
Коју год локалну политику да изаберете, она мора да пропушта транспорт који успоставља и одржава VPN. Блокирање тог транспорта оставља телефон без тунела и без политике, што ништа не примењује доследно и тешко се дијагностикује јер апликација једноставно нема мрежу.
Затим проверите сваки ред оригиналне реченице, а не општи утисак: радна апликација достиже радни сервис, иста апликација је одбијена на другом одредишту, апликација која није радна понаша се као пре, а са заустављеним тунелом радна апликација не прелази на директну везу. Проверите DNS путању одвојено, јер приватни DNS или шифровани resolver могу да заобиђу филтер који проверава само адресе.
Ако неки од тих корака не може да се испуни на телефону, захтев је архитектонско питање, а не подешавање firewall-а. Дељење политике између уређаја који контролишете и gateway-а који контролишете обично је искрен одговор, а Android документација о VPN повезивању је место где се потврђује шта платформа хоће и неће дозволити једном сервису.