กฎ firewall ของ Android ต้องอยู่ตรงไหนเมื่อเปิด VPN
มี VpnService ที่ทำงานได้ทีละตัวเท่านั้น แอป firewall กับแอป VPN จึงไม่ซ้อนกัน เดินตามคำขอทำงานหนึ่งรายการแล้ววางแต่ละกฎไว้ตรงที่ทราฟฟิกผ่านจริง
คุณมีนโยบายอยู่ประโยคเดียว: แอปนี้เข้าถึงบริการงานได้ และอย่างอื่นไม่ได้ คำถามถัดมาดูเหมือนการเลือกผลิตภัณฑ์ แต่เป็นคำถามเรื่องตำแหน่ง เพราะจุดบังคับใช้แต่ละจุดเห็นทราฟฟิกของโทรศัพท์คนละชุด gateway เห็นเพียงสิ่งที่เข้าอุโมงค์ ตัวกรองฝั่งโทรศัพท์เห็นเพียงสิ่งที่ได้รับอนุญาตให้สังเกต การพาคำขอเดียวผ่านทั้งสองจุดทำให้คำตอบชัดเจน
เริ่มจากประโยค ไม่ใช่ผลิตภัณฑ์
ขยายข้อกำหนดก่อนเลือกอะไรทั้งสิ้น นั่นหมายถึงแพ็กเกจและโปรไฟล์ที่มันทำงานอยู่ เพราะแอปในโปรไฟล์งานเป็นผู้ใช้คนละคนกับแอปเดียวกันในโปรไฟล์ส่วนตัว หมายถึงปลายทาง: host, port และ protocol ไม่ใช่ชื่อบริการ หมายถึงเส้นทาง DNS ที่แปลงชื่อนั้น และหมายถึงสิ่งควรเกิดขึ้นเมื่ออุโมงค์ไม่พร้อมใช้งาน
เมื่อเขียนออกมา นโยบายของตัวอย่างมีสี่บรรทัด: แอปงานเข้าถึงบริการงานได้; แอปงานเข้าถึงอย่างอื่นไม่ได้; แอปอื่นไม่เปลี่ยน; หากไม่มีอุโมงค์ แอปงานถูกปฏิเสธแทนที่จะถอยไปใช้เส้นทางตรง แต่ละบรรทัดมีเจ้าของ และไม่ใช่เจ้าของคนเดียวกันทั้งหมด
ขั้นตอนที่ 1: สิ่งที่โทรศัพท์บังคับใช้ได้เอง
firewall ของ Android ที่ไม่ต้อง 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 |
รูปแบบที่ใช้ได้คือสองขอบเขตกับสองหน้าที่ ขอบเขตภายในที่รับรู้แอปควบคุมพฤติกรรมของโทรศัพท์ รวมถึงการถอยไปเส้นทางตรง และขอบเขต gateway ควบคุมทรัพยากรระยะไกล ฝั่ง gateway อนุญาตบริการงานและปฏิเสธซับเน็ตส่วนตัวอื่นทุกตัวได้ ขณะที่นโยบายฝั่งโทรศัพท์ตัดสินใจเองเกี่ยวกับเส้นทางตรงที่แอปอาจเลือกใช้
ขั้นตอนที่ 5: รักษาการขนส่งให้ทำงาน แล้วตรวจสอบ
นโยบายภายในใดที่คุณเลือกต้องอนุญาตการขนส่งที่สร้างและรักษา VPN การปิดกั้นการขนส่งนั้นทำให้โทรศัพท์ไม่มีอุโมงค์และไม่มีนโยบาย ซึ่งไม่บังคับใช้สิ่งใดอย่างสอดคล้องและวินิจฉัยได้ยากเพราะแอปไม่มีเครือข่ายเลย
จากนั้นตรวจสอบทีละบรรทัดของประโยคเดิม ไม่ใช่ความรู้สึกโดยรวม: แอปงานเข้าถึงบริการงานได้ แอปเดียวกันถูกปฏิเสธที่ปลายทางอื่น แอปที่ไม่ใช่งานทำงานเหมือนเดิม และเมื่อหยุดอุโมงค์ แอปงานไม่ถอยไปใช้การเชื่อมต่อตรง ตรวจเส้นทาง DNS แยกต่างหาก เพราะ DNS ส่วนตัวหรือตัวแปลงที่เข้ารหัสสามารถข้ามตัวกรองที่ตรวจเฉพาะที่อยู่ได้
หากขั้นตอนใดทำไม่ได้บนโทรศัพท์ ข้อกำหนดนี้เป็นคำถามด้านสถาปัตยกรรม ไม่ใช่การตั้งค่า firewall การแยกนโยบายระหว่างอุปกรณ์ที่คุณควบคุมกับ gateway ที่คุณควบคุมมักเป็นคำตอบที่ซื่อสัตย์ และเอกสารการเชื่อมต่อ VPN ของ Androidคือที่ที่คุณยืนยันว่าแพลตฟอร์มจะให้และไม่ให้บริการเดียวทำอะไรได้