Csak belefoglalás vagy csak kizárás: melyik legyen az alapértelmezés?
Válaszd ki az alapértelmezést, mielőtt felépíted a listát: csak azt alagutazd, amit megnevezel, vagy alagutazz mindent, és vágd ki a kivételeket. Utána teszteld azt az alkalmazást, amelyet senki nem vett fel.
Nyisd meg a VPN-kliensed útválasztási szakaszát, és két különböző formájú vezérlőt látsz, amelyek gyakran ugyanazt a címkét viselik. Az egyik arra kér, hogy sorold fel az alagútba tartozó célokat, és minden más továbbra is a helyi hálózatot használja. A másik azt feltételezi, hogy minden az alagúton megy át, és azt kérdezi, mit kell kivágni. Mindkettő működő alagutat ad az első tesztnél, és mindkettőt sorok hozzáadásával tartják karban, ezért a különbség láthatatlan marad, amíg valaki nem telepít valami újat.
A választás alapértelmezés, nem funkció. Döntsd el, mielőtt a listán húsz bejegyzés lesz.
Az alapértelmezést a kliensen olvasd le, ne a brosúrában
A WireGuard szokatlanul láthatóvá teszi a döntést, mert a AllowedIPs befoglaló lista és semmi más. A 0.0.0.0/0, ::/0 értékű peer mindent alagutaz; a 10.20.0.0/16 értékű peer csak azt. Nincs kizárási szintaxis, ezért ha egy alhálózatot ki akarsz hagyni, vagy felsorolod az összes többi előtagot, vagy az interfészen kívül adsz hozzá házirend-alapú útválasztást.
OpenVPN ugyanoda jut a másik irányból: a redirect-gateway def1 teljes alagutat telepít, a kifejezett route-utasítások pedig meghatározott előtagokat adnak hozzá vagy írnak felül. A kereskedelmi kliensek általában mindkettőt egy jelölőnégyzet és egy céltáblázat mögé rejtik, ezért olvasd el, melyiket szerkeszti valójában a táblázat, mielőtt megbízol a címkében.
A kérdés nem az, hogy minek hívják a jelölőnégyzetet. A kérdés az, mi történik egy olyan csomaggal, amelynek célja egyik listán sem szerepel. Válaszold meg írásban, és a konfiguráció többi része ebből következik. Ha kihagyod a kérdést, az első megmagyarázatlan hibáról az fog dönteni, aki aznap épp a legközelebb ül a klienshez.
Kövess egy alkalmazást, amelyet senki nem vett fel
Csak befoglalásos kialakításnál ez az alkalmazás közvetlenül, a helyi hálózaton megy, a helyi DNS-sel. Csak kizárásos kialakításnál az alagúton megy át, amennyiben a szerver engedi, és ez gyakran épp a különbség aközött, hogy egy új SaaS-eszköz működik-e az első napon, és aközött, hogy jegy érkezik arról, hogy a VPN elrontotta.
Egyik alapértelmezés sem biztonságosabb önmagában. A befoglalás szűkíti, mit szállít az alagút, és a helyi hálózatot teszi a legkisebb ellenállás útjává; a kizárás az alagutat tekinti normál útnak, és a kivételeket kivételként kezeli, ami közelebb áll ahhoz, amit a legtöbb vállalati szabályzat valójában jelent.
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
Figyeld meg, milyen típusú objektumokat listáz a platform
Az Android VpnService.Builder engedélyezett és tiltott alkalmazáslistát két külön modellként kínál, és az alkalmazásonkénti szabályok csomag, nem cél szerint választanak. Egy ilyen listára tett böngésző minden megnyitott célt magával visz, ami más részletesség, mint egy útválasztási táblázat, és nem tud megjavítani egyetlen hibás oldalt egy működő alkalmazáson belül.
Az asztali kliensek általában egy felületen keverik a két fajtát, ezért ellenőrizd, hogy a hozzáadott sor csomag, gazdagépnév vagy előtag-e. Másképp hibáznak, és máshol oldódnak meg. A gazdagépnév-sor általában útvonal plusz név lesz, míg a csomagsor szabályzati döntéssé válik a kliensen belül. Írd fel, melyiket adtad hozzá, mert aki később hibakeres, a másikat fogja feltételezni.
Teszteld a hibaállapotot, ne csak a boldog utat
Az alagútból kizárt alkalmazás nem kap automatikusan tiszta közvetlen hozzáférést. Ha a kliens emellett olyan szabályt kényszerít ki, amely VPN nélkül blokkol, a kizárt forgalom teljesen eldobható, ami inkább törött alkalmazásnak látszik, mint útválasztási döntésnek. Teszteld ezt az esetet szándékosan, ahelyett hogy egy felhasználói jelentésből tudnád meg.
Utána ellenőrizd a DNS-t és az IPv6-ot külön pontként. Az csak IPv4-et szállító alagút utat hagy egy v6-képes alkalmazás számára mellette, és az osztott DNS dönti el, feloldódnak-e a belső nevek olyan forgalom számára, amely egyáltalán nem megy át az alagúton. Futtass egy listázott alkalmazást, egy nem listázott alkalmazást, egy névfeloldást és egy újracsatlakozást, és tartsd az eredményeket a konfiguráció mellett.
Írd le az alapértelmezést ott, ahol a következő ember megtalálja
Rögzítsd a választott alapértelmezést, a kivételeket és azt, hogy ki felel értük, ugyanott, ahol a kliensprofilt, mert a következő adminisztrátor ezt az érvelést elolvasás nélkül ad hozzá egy bejegyzést. Jegyezd fel minden kivétel dátumát és okát, hogy egy azóta megjavított oldal elavult kivétele magabiztosan eltávolítható legyen. Az okok nélküli lista örökké növekszik.
Amikor valaki egyetlen hibás célt jelent, a kivételt módosítsd, ne az alapvonalat. Az alapértelmezés megfordítása egyetlen oldal javításáért csendben minden nem listázott alkalmazást az alagút másik oldalára tesz.