VPN-reglur í beini: stemmið upprunann og áfangastaðinn

Innkaupasíður beina sýna VPN-beiningu sem einn gátreit, og þessi setning felur þrjár ólíkar spurningar. Passar reglan við tækið sem sendir umferðina, netþjóninn sem tekur við henni, eða bæði? Hvað verður um umferð sem passar við hvorki? Og þegar tvær reglur skarast, hvor vinnur þá? Að skrifa svarið sem par af uppruna og áfangastað breytir óljósum eiginleikalista í prófanlega hönnun.

Nafn eiginleikans felur tvo enda

Margmiðlunarspilari sem á að nota göngin er upprunasamsvörun. Einkaskrifstofuforskeyti sem á að vera aðgengilegt gegnum göngin er áfangastaðarsamsvörun. Vinnustöð sem á að nota göngin aðeins fyrir eina þjónustu er bæði, og sá skurður er tilfellið sem mestur hluti neytendafastbúnaðar höndlar illa.

Skrifið kröfuna sem par áður en þið berið saman vörur. Það par er það sem þið prófið síðar.

Vara sem býður lista yfir tæki eða alheimslista yfir áfangastaði getur ef til vill ekki lýst „aðeins þetta tæki, aðeins þessir áfangastaðir“. Bilið er ekki snyrting: alheimsregla um áfangastað sendir umferð hvers tækis á þá síðu gegnum göngin, og tækjaregla sendir alla umferð þess tækis. Hvorki er krafan. Prófið þetta tilfelli með tveimur tækjum áður en þið treystið skjánum.

Byggið regluna sem skurð

Tafla heldur hönnuninni heiðarlegri. Setjið atburðarásina til vinstri og nefnið svo sendingarsamsvörun og marksamsvörun aðskildar:

Þriðja röðin er áhugaverð, því hún þarf báða helmingana í einu. Ef fastbúnaðurinn getur aðeins lýst einum ás verður að kljúfa kröfuna í tvær reglur eða flytja hana á tæki sem getur það.

Haldið auðkenni upprunans stöðugu. DHCP-frátekt, sérstakur hluti eða auðkennismeðferð tækis virka öll, en vistfang sem breytist þegar leigan rennur út virkar ekki. Látið IPv6 fylgja, því eitt IPv4-vistfang auðkennir ekki alla umferð tækis.

Forgangur ræður sköruninni

Skörun reglna er eðlileg. Breið tækjaregla og þröng áfangastaðarregla geta báðar lýst einu flæði, og skjalfest forgangsröð ræður hvor vinnur. Aðlaðandi stillingaskjár segir þér ekki þá röð.

Lesið handbókina um röðina og um tilfellið án samsvörunar, og prófið svo bæði með umferð sem þið getið fylgst með:

ip rule show
ip route get 203.0.113.10

Ef skjölin greina ekki röðina skuluð þið gera ráð fyrir að þrengri reglan vinni ef til vill ekki og hannið í kringum það. Tvær reglur sem geta ekki stangast á eru auðveldari í stuðningi en ein snjöll regla með óskjalfesta forgangsröð.

Nöfn þurfa endurnýjunarstefnu

Áfangastaður skrifaður sem lén bætir við viðhaldsvandamáli. Beinirinn verður að leysa það, endurnýja vörpunina, höndla mörg vistföng og undirlén og takast á við DNS forrita sem fara fram hjá væntanlegum leysi.

Að afrita eina leitarniðurstöðu inn í IP-reglu er skyndimynd, ekki lénstefna.

Ákveðið hversu gömul svar mega vera áður en reglan er röng, og hvað beinirinn gerir þegar leysing mistekst. Regla sem heldur síðasta þekkta vistfangi getur lifað þjónustuflutning af; regla sem hendir færslunni getur stöðvað göngin hljóðlaust. Hvort tveggja er ásættanlegt ef það er skrifað við hlið reglunnar.

Skilgreinið óaðgengilega stöðu

Leiðarval krefst ekki umferðar eingöngu um VPN. Þegar göngin eru niðri getur beinirinn lokað flæðinu, sent það beint eða notað önnur göng, og hvert val hefur ólíka bilanatáknmynd.

Ákveðið hverju krafan þarf og sannreynið svo með því að stöðva göngin og fylgjast með flæðinu:

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

Umferð sem á uppruna sinn í beininum sjálfum er sérstakt svið. DNS-endursending, uppfærsluprófanir og eftirlit geta hafið ný flæði frá beininum sjálfum í stað þess að erfa upprunasamsvörun tækisins. Takið þessi flæði með skýrum hætti, annars birtast þau sem óútskýrð leki í annálunum.