VPN pravila na ruteru: uskladite izvor i odredište

Stranice za kupovinu rutera prikazuju VPN rutiranje kao jedan potvrdni okvir, a ta fraza skriva tri različita pitanja. Da li se pravilo poklapa s uređajem koji šalje promet, sa serverom koji ga prima ili s oba? Šta se dešava s prometom koji se ne poklapa ni s jednim? I kada se dva pravila preklapaju, koje pobjeđuje? Ako odgovor zapišete kao par izvora i odredišta, nejasan spisak funkcija postaje dizajn koji se može testirati.

Naziv funkcije skriva dva kraja

Medijski plejer koji treba koristiti tunel je podudaranje izvora. Privatni uredski prefiks koji treba biti dostupan kroz tunel je podudaranje odredišta. Radna stanica koja tunel treba koristiti samo za jednu uslugu je oboje, a taj presjek je slučaj s kojim većina potrošačkog firmvera loše postupa.

Zapišite zahtjev kao par prije nego što uporedite proizvode. Taj par je ono što ćete kasnije testirati.

Proizvod koji nudi spisak uređaja ili globalni spisak odredišta možda ne može izraziti „samo ovaj uređaj, samo ova odredišta“. Razlika nije kozmetička: globalno pravilo odredišta šalje promet svakog uređaja ka tom sajtu kroz tunel, a pravilo uređaja šalje sav promet tog uređaja. Nijedno nije zahtjev. Testirajte taj slučaj s dva uređaja prije nego što povjerujete ekranu.

Izgradite pravilo kao presjek

Tabela čuva dizajn iskrenim. Stavite scenario lijevo, pa odvojeno navedite podudaranje pošiljaoca i podudaranje cilja:

Treći red je zanimljiv jer mu trebaju obje polovine odjednom. Ako firmver može izraziti samo jednu osu, zahtjev se mora podijeliti u dva pravila ili premjestiti na uređaj koji to može.

Održite identitet izvora stabilnim. DHCP rezervacija, namjenski segment ili mehanizam identiteta uređaja svi rade, ali adresa koja se promijeni nakon isteka zakupa ne radi. Uključite IPv6, jer jedna IPv4 adresa ne identifikuje sav promet uređaja.

Prioritet odlučuje preklapanje

Preklapanje pravila je normalno. Široko pravilo uređaja i usko pravilo odredišta mogu oba opisivati jedan tok, a dokumentovani redoslijed prioriteta odlučuje koje pobjeđuje. Atraktivan ekran postavki ne govori vam taj redoslijed.

Pročitajte priručnik za redoslijed i za slučaj bez podudaranja, pa testirajte oboje prometom koji možete posmatrati:

ip rule show
ip route get 203.0.113.10

Ako dokumentacija ne navodi redoslijed, pretpostavite da uže pravilo možda neće pobijediti i projektujte oko toga. Dva pravila koja ne mogu biti u sukobu lakše je podržavati od jednog pametnog pravila s nedokumentovanim prvenstvom.

Imena traže politiku osvježavanja

Odredište zapisano kao domen dodaje problem održavanja. Ruter ga mora razriješiti, osvježiti mapiranje, obraditi više adresa i poddomena i nositi se s DNS-om aplikacija koji zaobilazi očekivani razrješivač.

Kopiranje jednog rezultata pretrage u IP pravilo je snimak, a ne politika domena.

Odlučite koliko odgovor može biti star prije nego pravilo postane pogrešno i šta ruter radi kada razrješavanje ne uspije. Pravilo koje čuva posljednju poznatu adresu može nadživjeti migraciju usluge; pravilo koje odbaci unos može tiho zaustaviti tuneliranje. Oba ponašanja su prihvatljiva ako su zapisana uz pravilo.

Definišite stanje nedostupnosti

Postavka rute ne nameće promet samo kroz VPN. Kada je tunel pao, ruter može blokirati tok, poslati ga direktno ili upotrijebiti drugi tunel, a svaki izbor ima drugačiji potpis kvara.

Odlučite koje od njih zahtjev traži, pa to provjerite zaustavljanjem tunela i posmatranjem toka:

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

Promet koji potiče s rutera je odvojen obim. DNS prosljeđivanje, provjere ažuriranja i nadzor mogu pokrenuti nove tokove sa samog rutera umjesto da naslijede podudaranje izvora uređaja. Uzmite te tokove eksplicitno u obzir, inače će se pojaviti kao neobjašnjena curenja u zapisima.