VPN noteikumi maršrutētājā: saskaņojiet avotu un galamērķi

Maršrutētāju iepirkšanās lapas VPN maršrutēšanu parāda kā vienu atzīmēšanas rūtiņu, un šī frāze slēpj trīs dažādus jautājumus. Vai noteikums atbilst ierīcei, kas sūta datplūsmu, serverim, kas to saņem, vai abiem? Kas notiek ar datplūsmu, kas neatbilst nevienam? Un kad divi noteikumi pārklājas, kurš uzvar? Atbildes pierakstīšana kā avota un galamērķa pāris pārvērš neskaidru funkciju sarakstu pārbaudāmā projektā.

Funkcijas nosaukums slēpj divus galus

Mediju atskaņotājs, kam jāizmanto tunelis, ir avota atbilstība. Privāts biroja prefikss, kam jābūt sasniedzamam caur tuneli, ir galamērķa atbilstība. Darbstacija, kam tunelis jāizmanto tikai vienam pakalpojumam, ir abi, un šis krustojums ir gadījums, ko lielākā daļa patērētāju aparātprogrammatūras apstrādā slikti.

Pierakstiet prasību kā pāri pirms produktu salīdzināšanas. Šo pāri jūs vēlāk pārbaudīsiet.

Produkts, kas piedāvā ierīču sarakstu vai globālu galamērķu sarakstu, var nespēt izteikt „tikai šī ierīce, tikai šie galamērķi“. Atšķirība nav kosmētiska: globāls galamērķa noteikums sūta katras ierīces datplūsmu uz šo vietni caur tuneli, un ierīces noteikums sūta visu šīs ierīces datplūsmu. Neviens no tiem nav prasība. Pārbaudiet šo gadījumu ar divām ierīcēm pirms uzticēšanās ekrānam.

Veidojiet noteikumu kā krustojumu

Tabula uztur projektu godīgu. Novietojiet scenāriju pa kreisi, tad atsevišķi nosauciet sūtītāja atbilstību un mērķa atbilstību:

Trešā rinda ir interesantā, jo tai vajadzīgas abas puses vienlaikus. Ja aparātprogrammatūra spēj izteikt tikai vienu asi, prasība jāsadala divos noteikumos vai jāpārnes uz ierīci, kas to spēj.

Saglabājiet avota identitāti stabilu. DHCP rezervācija, atsevišķs segments vai ierīces identitātes mehānisms darbojas, bet adrese, kas mainās pēc nomas beigām, nedarbojas. Iekļaujiet IPv6, jo viena IPv4 adrese neidentificē visu ierīces datplūsmu.

Pārklāšanos izlemj prioritāte

Noteikumu pārklāšanās ir normāla. Plašs ierīces noteikums un šaurs galamērķa noteikums var aprakstīt vienu plūsmu, un dokumentētā prioritāšu kārtība izlemj, kurš uzvar. Pievilcīgs iestatījumu ekrāns jums šo kārtību nepasaka.

Izlasiet rokasgrāmatā par kārtību un par gadījumu bez atbilstības, pēc tam pārbaudiet abus ar datplūsmu, ko varat novērot:

ip rule show
ip route get 203.0.113.10

Ja dokumentācija nenorāda kārtību, pieņemiet, ka šaurākais noteikums var neuzvarēt, un projektējiet to ņemot vērā. Divus noteikumus, kas nevar nonākt pretrunā, ir vieglāk uzturēt nekā vienu gudru noteikumu ar nedokumentētu prioritāti.

Nosaukumiem vajadzīga atjaunināšanas politika

Galamērķis, kas rakstīts kā domēns, pievieno uzturēšanas problēmu. Maršrutētājam tas jāatrisina, jāatjaunina kartēšana, jāapstrādā vairākas adreses un apakšdomēni, un jātiek galā ar lietotņu DNS, kas apiet paredzēto atrisinātāju.

Viena meklēšanas rezultāta kopēšana IP noteikumā ir momentuzņēmums, nevis domēna politika.

Izlemiet, cik veca atbilde drīkst būt, pirms noteikums ir nepareizs, un ko maršrutētājs dara, kad atrisināšana neizdodas. Noteikums, kas patur pēdējo zināmo adresi, var pārdzīvot pakalpojuma migrāciju; noteikums, kas ierakstu izmet, var klusi pārtraukt tuneļošanu. Abas uzvedības ir pieņemamas, ja tās ir pierakstītas blakus noteikumam.

Definējiet nepieejamības stāvokli

Maršruta izvēle neuzspiež datplūsmu tikai caur VPN. Kad tunelis ir izslēgts, maršrutētājs var bloķēt plūsmu, sūtīt to tieši vai izmantot citu tuneli, un katrai izvēlei ir cits atteices paraksts.

Izlemiet, kura prasībai vajadzīga, pēc tam pārbaudiet to, apturot tuneli un vērojot plūsmu:

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

Datplūsma, kas rodas no paša maršrutētāja, ir atsevišķa joma. DNS pārsūtīšana, atjauninājumu pārbaudes un uzraudzība var sākt jaunas plūsmas no paša maršrutētāja, nevis mantot ierīces avota atbilstību. Ņemiet šīs plūsmas vērā skaidri, citādi tās parādīsies žurnālos kā neizskaidrojamas noplūdes.