Wêr’t in Android-firewallregel wenje moat as in VPN oan stiet
Allinnich ien VpnService kin aktyf wêze, dat in firewall-app en in VPN-app steapelje net. Gean ien wurkoanfraach troch en set elk regel dêr’t it ferkear derfan echt lâns giet.
Jo hawwe ien sin fan belied: dizze app mei de wurkstsjinst berikke, en fierder neat. De folgjende fraach liket in produktkar, mar it is in fraach oer plak, want elk mooglik hanthavenjepunt sjocht in oar part fan it ferkear fan de telefoan. De gateway sjocht allinnich wat de tunnel yn giet. It filter oan de telefoankant sjocht allinnich wat it tastien is te besjen. Ien oanfraach troch beide liede makket it antwurd dúdlik.
Begjin by de sin, net by it produkt
Wreidzje de eask út earst foardat jo wat kieze. Dat betsjut it pakket en it profyl wêryn it draait, want in app yn it wurkprofyl is in oare brûker as deselde app yn it persoanlike profyl. Dat betsjut it bestimming: host, poarte en protokol, net in tsjinstnamme. Dat betsjut it DNS-paad dat dy namme oplost, en it betsjut wat der barre moat as de tunnel net beskikber is.
Utskreaun hat it belied fan it foarbyld fjouwer rigels: de wurkapp mei de wurkstsjinst berikke; de wurkapp mei fierder neat berikke; oare apps bliuwe gelyk; sûnder tunnel wurdt de wurkapp wegere ynstee fan werom te fallen op in direkt paad. Elke rigel hat in eigner, en it is net allegear deselde eigner.
Stap 1: wat de telefoan sels hanthavenje kin
In Android-firewall sûnder root is in VpnService dy’t ferkear lokaal opfangt, ek as der gjin fiere tunnel efter sit. Android lit ien aktyf VPN-tsjinst per brûkersprofyl ta, dat in twadde firewall-app riget him net efter de earste. Hy ferfangt him, en de ynterface dy’t de earste app filtere ferdwynt.
Dêrom jout in firewall njonken in VPN-klant selden de kombinaasje dy’t minsken ferwachtsje. As de firewall start en it VPN brekt ôf, is der neat kombinearre; de beide hawwe plak wiksele. It ferfangen fan in ynterface is gjin gearwurking, en it symptoom is in tunnel dy’t hieltyd falt eltse kear as de oare app iepene wurdt.
Stipe opstellings besteane: filtering ynboud yn de VPN-klant dy’t jo al draaie, behearde platfoarmkontrôles fia in apparaatbeliedsbehearder of wurkprofyl, of in arsjitektuer dy’t de leveransier dokumintearret. Al it oare is in eksperimint dat nei elke app-bywurking opnij ferifiearre wurde moat.
Stap 2: wat de gateway hanthavenje kin
As it ferkear oan de fiere kant ûntsifere is, kin de gateway trochstjoerde pakketten beheine ta goedkarde adressen, tsjinsten of ferifisearre VPN-identiteiten. Dat is echte hanthavening foar alles wat derút giet, en it is it goede plak om tagong ta partikuliere subnetten te beheinen.
Wat er net krijt, is de app-identiteit fan de telefoan dy’t oan elk gewoan IP-pakket hinget. Ferskate apps dy’t ien tunneladres diele binne foar de gateway ien subjekt, útsein as it ûntwerp har aparte adressen of aparte ferifisearre identiteiten jout. In regel per brûker by de gateway is dus gjin regel per app op de telefoan, hoe’t de behearderskonsole it ek neamt.
Stap 3: list op wat nea oankomt
In app dy’t fan it VPN útsletten is en kontakt makket mei in apparaat tichtby berikt de gateway nea, dat in útgong-firewall kin in pakket net wegerje dat er nea krijt. Itselde jildt foar in ûnbedoeld direkt paad by in steuring en foar ynkommende bleatstelling op it lokale tagongsnetwurk. Dat binne lokale grinzen neffens de definysje.
It omkearde jildt ek: in lokale regel dy’t in ferbining tastiet jout gjin tagong fia de ACL fan it partikuliere netwurk fan de gateway. Ien oanfraach kin ûnder beide grinzen falle, en ien ferfolje seit neat oer de oare.
Stap 4: ja elk regel in paad ta
Set de beslissing yn in tabel foardat jo wat konfigurearje, want de lege sellen binne it plak dêr’t ûntwerpen mislearje.
| Paad | Wa’t it hanthavenje kin | Bline flek |
|---|---|---|
| Wurkapp nei de wurkstsjinst, tunnel oan | Gateway-ACL op adres en tsjinst, plus in lokale blokkade op oare paden | De gateway sjocht net hokker app it pakket stjoerd hat |
| Wurkapp nei oare bestimmingen, tunnel oan | Lokaal app-bewust filter, of de gateway as dy bestimmingen dêr adressearre binne | It lokale filter moat de aktive VpnService wêze |
| Wurkapp sûnder tunnel | Lokale wegering, sadat de app gjin direkt paad nimme kin | Freget dat it filter it ferdwinen fan de tunnel oerlibbet |
| LAN-apparaat tichtby | Allinnich lokaal belied | De gateway sjocht it nea |
De foarm dy’t wurket is twa grinzen mei twa taken. In lokale app-bewuste grins bestjoert it gedrach fan de telefoan, ynklusyf de direkte weromfal, en in gateway-grins bestjoert fiere boarnen. De gateway-kant kin de wurkstsjinst tastean en elk oar partikulier subnet wegerje, wylst it belied oan de telefoankant sels beslút oer in direkt paad dat de app oars nimme koe.
Stap 5: hâld it ferfier libben, ferifiearje dan
Hokker lokaal belied jo ek kieze, it moat it ferfier tastean dat it VPN opbout en hâldt. It blokkearjen fan dat ferfier lit de telefoan sûnder tunnel en sûnder belied, wat neat gearhingjend hanthavent en dreech te diagnostearjen is, want de app hat gewoan gjin netwurk.
Ferifiearje dan elke rigel fan de oarspronklike sin ynstee fan de algemiene yndruk: de wurkapp berikt de wurkstsjinst, deselde app wurdt wegere by in oare bestimming, in app dy’t gjin wurk is gedraacht him as earder, en mei de tunnel stoppe falt de wurkapp net werom op in direkte ferbining. Kontrolearje it DNS-paad apart, want partikulier DNS of in fersifere oplosser kin in filter foarbygean dat allinnich adressen besjocht.
As ien fan dy stappen op de telefoan net ferfolle wurde kin, is de eask in arsjitektuerfraach en gjin firewall-ynstelling. It belied ferdiele tusken in apparaat dat jo beheare en in gateway dy’t jo beheare is meast it earlike antwurd, en de Android-dokumintaasje oer VPN-ferbiningen is it plak om te befêstigjen wat it platfoarm ien tsjinst tastean sil en net.