Pravila VPN na usmerjevalniku: uskladite vir in cilj

Strani za nakup usmerjevalnikov prikazujejo usmerjanje VPN kot eno potrditveno polje, in ta besedna zveza skriva tri različna vprašanja. Ali se pravilo ujema z napravo, ki pošilja promet, s strežnikom, ki ga prejme, ali z obema? Kaj se zgodi s prometom, ki se ne ujema z nobenim? In ko se dve pravili prekrivata, katero zmaga? Če odgovor zapišete kot par vira in cilja, se nejasen seznam funkcij spremeni v preverljivo zasnovo.

Ime funkcije skriva dva konca

Predvajalnik predstavnostnih vsebin, ki naj uporablja tunel, je ujemanje vira. Zasebna pisarniška predpona, ki naj bo dosegljiva skozi tunel, je ujemanje cilja. Delovna postaja, ki naj uporablja tunel le za eno storitev, je oboje, in ta presek je primer, ki ga večina potrošniške vdelane programske opreme obravnava slabo.

Zahtevo zapišite kot par, preden primerjate izdelke. Ta par boste preverili pozneje.

Izdelek, ki ponuja seznam naprav ali globalni seznam ciljev, morda ne more izraziti »samo ta naprava, samo ti cilji«. Razlika ni kozmetična: globalno pravilo cilja pošilja promet vsake naprave na to spletno mesto skozi tunel, pravilo naprave pa pošilja ves promet te naprave. Nobeno ni zahteva. Preizkusite ta primer z dvema napravama, preden zaupate zaslonu.

Pravilo zgradite kot presek

Tabela ohranja zasnovo pošteno. Scenarij postavite levo, nato ločeno poimenujte ujemanje pošiljatelja in ujemanje cilja:

Tretja vrstica je zanimiva, ker potrebuje obe polovici hkrati. Če lahko vdelana programska oprema izrazi le eno os, je treba zahtevo razdeliti na dve pravili ali jo prestaviti na napravo, ki to zmore.

Ohranite identiteto vira stabilno. Rezervacija DHCP, namenski segment ali mehanizem identitete naprave delujejo, naslov, ki se spremeni po izteku najema, pa ne. Vključite IPv6, ker en naslov IPv4 ne identificira vsega prometa naprave.

O prekrivanju odloča prednost

Prekrivanje pravil je običajno. Široko pravilo naprave in ozko pravilo cilja lahko opisujeta isti tok, in dokumentiran vrstni red prednosti odloča, katero zmaga. Privlačen zaslon nastavitev vam tega vrstnega reda ne pove.

Preberite v priročniku o vrstnem redu in o primeru brez ujemanja, nato oboje preizkusite s prometom, ki ga lahko opazujete:

ip rule show
ip route get 203.0.113.10

Če dokumentacija ne navaja vrstnega reda, predpostavite, da ožje pravilo morda ne bo zmagalo, in načrtujte s tem. Dve pravili, ki ne moreta priti v navzkrižje, je lažje podpirati kot eno pametno pravilo z nedokumentirano prednostjo.

Imena potrebujejo politiko osveževanja

Cilj, zapisan kot domena, doda težavo vzdrževanja. Usmerjevalnik jo mora razrešiti, osvežiti preslikavo, obravnavati več naslovov in poddomen ter se spopasti z DNS aplikacij, ki obide pričakovani razreševalnik.

Kopiranje enega rezultata iskanja v pravilo IP je posnetek, ne politika domene.

Odločite, kako star je lahko odgovor, preden je pravilo napačno, in kaj usmerjevalnik naredi, ko razrešitev ne uspe. Pravilo, ki obdrži zadnji znani naslov, lahko preživi selitev storitve; pravilo, ki vnos zavrže, lahko tiho ustavi tuneliranje. Obe vedenji sta sprejemljivi, če sta zapisani ob pravilu.

Določite stanje nedosegljivosti

Nastavitev poti ne vsili prometa samo skozi VPN. Ko je tunel izklopljen, lahko usmerjevalnik tok blokira, ga pošlje neposredno ali uporabi drug tunel, in vsaka izbira ima drugačen podpis napake.

Odločite, katero zahteva potrebuje, nato to preverite z ustavitvijo tunela in opazovanjem toka:

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

Promet, ki izvira iz samega usmerjevalnika, je ločeno območje. Posredovanje DNS, preverjanja posodobitev in spremljanje lahko začnejo nove tokove iz samega usmerjevalnika, namesto da bi podedovali ujemanje vira naprave. Te tokove upoštevajte izrecno, sicer se bodo v dnevnikih pojavili kot nerazložljiva uhajanja.