VPN-säännöt reitittimessä: sovita lähde ja kohde yhteen
Reitittimen VPN-säännöllä on kaksi päätä: laite, joka lähettää liikennettä, ja kohde, jonka pitäisi käyttää tunnelia. Päätä ensin leikkaus ja varakäyttäytyminen.
Reitittimien ostosivut esittävät VPN-reitityksen yhtenä valintaruutuna, ja lause kätkee kolme eri kysymystä. Sopiiko sääntö laitteeseen, joka lähettää liikennettä, palvelimeen, joka vastaanottaa sen, vai molempiin? Mitä tapahtuu liikenteelle, joka ei sovi kumpaankaan? Ja kun kaksi sääntöä menee päällekkäin, kumpi voittaa? Kun vastauksen kirjoittaa lähteen ja kohteen parina, epämääräinen ominaisuusluettelo muuttuu testattavaksi suunnitteluksi.
Ominaisuuden nimi kätkee kaksi päätä
Mediasoitin, jonka pitäisi käyttää tunnelia, on lähdeosuma. Yksityinen toimistoprefiksi, jonka pitäisi olla tavoitettavissa tunnelin kautta, on kohdeosuma. Työasema, jonka pitäisi käyttää tunnelia vain yhteen palveluun, on molemmat, ja juuri tämä leikkaus on tapaus, jota useimmat kuluttajalaiteohjelmistot käsittelevät huonosti.
Kirjoita vaatimus parina ennen tuotteiden vertailua. Juuri tätä paria testaat myöhemmin.
Tuote, joka tarjoaa laiteluettelon tai globaalin kohdeluettelon, ei ehkä pysty ilmaisemaan «vain tämä laite, vain nämä kohteet». Ero ei ole kosmeettinen: globaali kohdesääntö lähettää jokaisen laitteen liikenteen kyseiseen sivustoon tunnelin kautta, ja laitesääntö lähettää kaiken kyseisen laitteen liikenteen. Kumpikaan ei ole vaatimus. Testaa tätä tapausta kahdella laitteella ennen kuin luotat näyttöön.
Rakenna sääntö leikkauksena
Taulukko pitää suunnittelun rehellisenä. Laita skenaario vasemmalle ja nimeä sitten lähettäjäosuma ja kohdeosuma erikseen:
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, evaluated first |
Kolmas rivi on kiinnostava, koska se tarvitsee molemmat puolet kerralla. Jos laiteohjelmisto pystyy ilmaisemaan vain yhden akselin, vaatimus on jaettava kahdeksi säännöksi tai siirrettävä laitteeseen, joka pystyy siihen.
Pidä lähteen identiteetti vakaana. DHCP-varaus, oma segmentti tai laitteen identiteettimekanismi toimivat, mutta osoite, joka muuttuu vuokrauksen päätyttyä, ei toimi. Sisällytä IPv6, koska yksi IPv4-osoite ei tunnista laitteen kaikkea liikennettä.
Prioriteetti ratkaisee päällekkäisyyden
Sääntöjen päällekkäisyys on normaalia. Laaja laitesääntö ja kapea kohdesääntö voivat molemmat kuvata samaa virtaa, ja dokumentoitu prioriteettijärjestys ratkaisee, kumpi voittaa. Houkutteleva asetusnäyttö ei kerro sinulle sitä järjestystä.
Lue käsikirjasta järjestys ja tapaus, jossa osumaa ei ole, ja testaa sitten molemmat liikenteellä, jota voit havainnoida:
ip rule show
ip route get 203.0.113.10Jos dokumentaatio ei ilmoita järjestystä, oleta, että kapeampi sääntö ei välttämättä voita, ja suunnittele sen mukaisesti. Kahta sääntöä, jotka eivät voi olla ristiriidassa, on helpompi tukea kuin yhtä älykästä sääntöä, jonka ensisijaisuus on dokumentoimaton.
Nimet tarvitsevat päivityskäytännön
Verkkotunnukseksi kirjoitettu kohde lisää ylläpitoprobleeman. Reitittimen on ratkaistava se, päivitettävä kartoitus, käsiteltävä useita osoitteita ja aliverkkotunnuksia ja selvittävä sovellusten DNS:stä, joka ohittaa odotetun ratkaisijan.
Yhden hakutyön tuloksen kopioiminen IP-sääntöön on tilannekuva, ei verkkotunnuskäytäntö.
Päätä, kuinka vanha vastaus saa olla ennen kuin sääntö on väärä, ja mitä reititin tekee, kun ratkaisu epäonnistuu. Sääntö, joka säilyttää viimeisimmän tunnetun osoitteen, voi kestää palvelun siirron; sääntö, joka pudottaa merkinnän, voi hiljaa lopettaa tunnelioinnin. Kumpikin käyttäytyminen on hyväksyttävää, jos se on kirjattu säännön viereen.
Määritä ei-käytettävissä oleva tila
Reittimieltymys ei pakota vain VPN:n kautta kulkevaa liikennettä. Kun tunneli on alas, reititin voi estää virran, lähettää sen suoraan tai käyttää toista tunnelia, ja jokaisella valinnalla on erilainen vikakuvio.
Päätä, mitä vaatimus tarvitsee, ja varmista se sitten pysäyttämällä tunneli ja seuraamalla virtaa:
curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10Reitittimestä itsestään lähtevä liikenne on erillinen alue. DNS-edelleenlähetys, päivitystarkistukset ja valvonta voivat aloittaa uusia virtoja reitittimestä itsestään sen sijaan, että ne perisivät laitteen lähdeosuman. Ota nämä virrat eksplisiittisesti huomioon, muuten ne näkyvät lokissa selittämättöminä vuotoina.