VPN-reglar på rutaren: knytt kjelda og destinasjonen saman

Ruteshopping-sider viser VPN-ruting som éin avkrysningsboks, og den formuleringa skjuler tre ulike spørsmål. Passar regelen eininga som sender trafikken, tenaren som tek imot han, eller begge? Kva skjer med trafikk som ikkje passar nokon av dei? Og når to reglar overlappar, kven vinn? Å skrive svaret som eit par av kjelde og destinasjon gjer ei vag funksjonsliste om til eit design som kan testast.

Funksjonsnamnet skjuler to endar

Ein mediespelar som skal bruke tunnelen, er ein kjeldematch. Eit privat kontorprefiks som skal vere tilgjengeleg gjennom tunnelen, er ein destinasjonsmatch. Ein arbeidsstasjon som berre skal bruke tunnelen til éin teneste, er begge, og det snittet er tilfellet som dei fleste forbrukarfastvarene handterer dårleg.

Skriv kravet som eit par før du samanliknar produkt. Det paret er det du skal teste seinare.

Eit produkt som tilbyr ei einingliste eller ei global destinasjonsliste, uttrykkjer kanskje ikkje «berre denne eininga, berre desse destinasjonane». Skilnaden er ikkje kosmetisk: ein global destinasjonsregel sender trafikken frå alle einingar til den nettstaden gjennom tunnelen, og ein einingsregel sender all trafikk frå den eininga. Ingen av dei er kravet. Test det tilfellet med to einingar før du stolar på skjermen.

Bygg regelen som eit snitt

Ein tabell held designet ærleg. Set scenariet til venstre, og namn deretter avsendarmatch og mål-match kvar for seg:

Den tredje rada er den interessante, fordi ho treng begge halvdelane samstundes. Viss fastvaren berre kan uttrykke éin akse, må kravet delast i to reglar eller flyttast til ei eining som kan det.

Hald kjeldeidentiteten stabil. Ein DHCP-reservasjon, eit dedikert segment eller ein einingsidentitetsmekanisme fungerer alle, men ei adresse som endrar seg når leigeavtalen går ut, gjer det ikkje. Ta med IPv6, fordi éi IPv4-adresse identifiserer ikkje all trafikk frå ei eining.

Prioriteten avgjer overlappinga

Overlappande reglar er normalt. Ein brei einingsregel og ein smal destinasjonsregel kan begge skildre éin straum, og den dokumenterte prioritetsrekkjefølgja avgjer kven som vinn. Ein innbydande innstillingsskjerm fortel deg ikkje den rekkjefølgja.

Les handboka for rekkjefølgja og for tilfellet utan match, og test deretter begge med trafikk du kan observere:

ip rule show
ip route get 203.0.113.10

Viss dokumentasjonen ikkje oppgir rekkjefølgja, føreset du at den smalare regelen kanskje ikkje vinn, og designar rundt det. To reglar som ikkje kan kome i konflikt, er lettare å støtte enn éin smart regel med udokumentert forrang.

Namn treng ein oppdateringspolicy

Ein destinasjon skriven som eit domene legg til eit vedlikehaldsproblem. Rutaren må slå han opp, oppdatere kartlegginga, handtere fleire adresser og underdomene og takle applikasjons-DNS som går utanom den forventa resolveren.

Å kopiere eitt oppslagsresultat inn i ein IP-regel er eit augeblinksbilete, ikkje ein domenepolicy.

Avgjer kor gammalt eit svar kan vere før regelen er feil, og kva rutaren gjer når oppslaget mislukkast. Ein regel som held på den sist kjende adressa, kan overleve ein tenestemigrasjon; ein regel som forkastar oppføringa, kan stille stoppe tunnelleringa. Begge åtferdene er akseptable viss dei er skrivne ned ved regelen.

Definer den utilgjengelege tilstanden

Ein rutepreferanse handhevar ikkje VPN-berre-trafikk. Når tunnelen er nede, kan rutaren blokkere straumen, sende han direkte eller bruke ein annan tunnel, og kvart val har ein annan feilsignatur.

Avgjer kva kravet treng, og verifiser det ved å stoppe tunnelen og følgje straumen:

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

Trafikk som oppstår frå rutaren sjølv, er eit eige område. DNS-vidareformidling, oppdateringssjekkar og overvaking kan starte nye straumar frå rutaren sjølv i staden for å arve kjeldematcha til eininga. Ta omsyn til desse straumane eksplisitt, elles vil dei visast som uforklarte lekkasjar i loggane.