VPN-i reeglid ruuteris: sobitage allikas ja sihtkoht

Ruuterite ostulehed esitavad VPN-i marsruutimist ühe märkeruuduna ja see fraas varjab kolme erinevat küsimust. Kas reegel sobib seadmega, mis saadab liiklust, serveriga, mis selle vastu võtab, või mõlemaga? Mis juhtub liiklusega, mis ei sobi kummagagi? Ja kui kaks reeglit kattuvad, milline võidab? Kui kirjutate vastuse allika ja sihtkoha paarina, muutub hägune funktsioonide loend testitavaks disainiks.

Funktsiooni nimi varjab kahte otsa

Meediumimängija, mis peaks tunnelit kasutama, on allika vaste. Privaatne kontori prefiks, mis peaks olema tunneli kaudu kättesaadav, on sihtkoha vaste. Tööjaam, mis peaks tunnelit kasutama ainult ühe teenuse jaoks, on mõlemad, ja see ühisosa on juhtum, mida enamik tarbijate püsivara halvasti käsitleb.

Kirjutage nõue paarina enne toodete võrdlemist. Just seda paari testite hiljem.

Toode, mis pakub seadmete loendit või globaalset sihtkohtade loendit, ei pruugi väljendada «ainult see seade, ainult need sihtkohad». Vahe pole kosmeetiline: globaalne sihtkoha reegel saadab iga seadme liikluse sellesse saiti tunneli kaudu ja seadme reegel saadab kogu selle seadme liikluse. Kumbki pole nõue. Testige seda juhtumit kahe seadmega enne, kui ekraani usaldate.

Ehitage reegel ühisosana

Tabel hoiab disaini ausana. Pange stsenaarium vasakule ja nimetage seejärel saatja vaste ja sihtvasta eraldi:

Kolmas rida on huvitav, sest see vajab mõlemat poolt korraga. Kui püsivara suudab väljendada ainult ühte telge, tuleb nõue jagada kaheks reegliks või viia seadmesse, mis seda suudab.

Hoidke allika identiteet stabiilne. DHCP reserveering, sihtotstarbeline segment või seadme identiteedi mehhanism kõik toimivad, kuid pärast rendilepingu lõppemist muutuv aadress ei toimi. Kaasake IPv6, sest üks IPv4 aadress ei identifitseeri kogu seadme liiklust.

Prioriteet otsustab kattuvuse

Reeglite kattumine on tavaline. Lai seadme reegel ja kitsas sihtkoha reegel võivad kirjeldada sama voogu ning dokumenteeritud prioriteedijärjekord otsustab, milline võidab. Atraktiivne seadete ekraan ei ütle teile seda järjekorda.

Lugege juhendist järjekorra ja sobivuseta juhtumi kohta ning testige seejärel mõlemat liiklusega, mida saate jälgida:

ip rule show
ip route get 203.0.113.10

Kui dokumentatsioon järjekorda ei märgi, eeldage, et kitsam reegel ei pruugi võita, ja projekteerige seda arvestades. Kahte reeglit, mis ei saa vastuollu minna, on lihtsam toetada kui üht nutikat reeglit, mille ülimuslikkus on dokumenteerimata.

Nimed vajavad värskenduspoliitikat

Domeenina kirjutatud sihtkoht lisab hooldusprobleemi. Ruuter peab selle lahendama, vastendust värskendama, käsitlema mitut aadressi ja alamdomeeni ning tulema toime rakenduste DNS-iga, mis möödub oodatud lahendajast.

Ühe päringutulemuse kopeerimine IP-reeglisse on hetktõmmis, mitte domeenipoliitika.

Otsustage, kui vana vastus võib olla, enne kui reegel on vale, ja mida ruuter teeb, kui lahendamine ebaõnnestub. Reegel, mis hoiab viimast teadaolevat aadressi, võib teenuse migratsiooni üle elada; reegel, mis kirje kaotab, võib tunnelid vaikselt peatada. Mõlemad käitumised on vastuvõetavad, kui need on reegli kõrvale kirja pandud.

Määratlege kättesaamatu olek

Marsruudi eelistus ei sunni ainult VPN-i liiklust. Kui tunnel on maas, võib ruuter voo blokeerida, selle otse saata või kasutada teist tunnelit ning igal valikul on erinev tõrkeallkiri.

Otsustage, millist nõue vajab, ja seejärel kontrollige seda tunneli peatamise ja voo jälgimisega:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

Ruuterist endast algav liiklus on eraldi ulatus. DNS-edastamine, värskenduste kontrollid ja jälgimine võivad alustada uusi vooge ruuterist endast, selle asemel et pärida seadme allika vastet. Arvestage neid vooge selgesõnaliselt, muidu ilmuvad need logides seletamatute leketena.