VPN-regler på ruteren: koble kilden og destinasjonen sammen

Rutershopping-sider viser VPN-ruting som én avkrysningsboks, og den formuleringen skjuler tre forskjellige spørsmål. Passer regelen enheten som sender trafikken, serveren som mottar den, eller begge? Hva skjer med trafikk som ikke passer noen av dem? Og når to regler overlapper, hvilken vinner? Å skrive svaret som et par av kilde og destinasjon gjør en vag funksjonsliste om til et design som kan testes.

Funksjonsnavnet skjuler to ender

En mediespiller som skal bruke tunnelen, er en kildematch. Et privat kontorprefiks som skal være tilgjengelig gjennom tunnelen, er en destinasjonsmatch. En arbeidsstasjon som bare skal bruke tunnelen til én tjeneste, er begge, og det snittet er tilfellet som de fleste forbrukerfastvare håndterer dårlig.

Skriv kravet som et par før du sammenligner produkter. Det paret er det du skal teste senere.

Et produkt som tilbyr en enhetsliste eller en global destinasjonsliste, uttrykker kanskje ikke «bare denne enheten, bare disse destinasjonene». Forskjellen er ikke kosmetisk: en global destinasjonsregel sender trafikken fra alle enheter til det nettstedet gjennom tunnelen, og en enhetsregel sender all trafikk fra den enheten. Ingen av dem er kravet. Test det tilfellet med to enheter før du stoler på skjermen.

Bygg regelen som et snitt

En tabell holder designet ærlig. Sett scenariet til venstre, og navngi deretter avsendermatch og mål-match hver for seg:

Den tredje raden er den interessante, fordi den trenger begge halvdelene samtidig. Hvis fastvaren bare kan uttrykke én akse, må kravet deles i to regler eller flyttes til en enhet som kan det.

Hold kildeidentiteten stabil. En DHCP-reservasjon, et dedikert segment eller en enhetsidentitetsmekanisme fungerer alle, men en adresse som endres når leieavtalen utløper, gjør det ikke. Ta med IPv6, fordi én IPv4-adresse ikke identifiserer all trafikk fra en enhet.

Prioriteten avgjør overlappen

Overlappende regler er normalt. En bred enhetsregel og en smal destinasjonsregel kan begge beskrive én strøm, og den dokumenterte prioritetsrekkefølgen avgjør hvilken som vinner. En innbydende innstillingsskjerm forteller deg ikke den rekkefølgen.

Les håndboken for rekkefølgen og for tilfellet uten match, og test deretter begge med trafikk du kan observere:

ip rule show
ip route get 203.0.113.10

Hvis dokumentasjonen ikke oppgir rekkefølgen, antar du at den smalere regelen kanskje ikke vinner, og designer rundt det. To regler som ikke kan komme i konflikt, er lettere å støtte enn én smart regel med udokumentert forrang.

Navn trenger en oppdateringspolicy

En destinasjon skrevet som et domene legger til et vedlikeholdsproblem. Ruteren må slå den opp, oppdatere kartleggingen, håndtere flere adresser og underdomener og takle applikasjons-DNS som omgår den forventede resolveren.

Å kopiere ett oppslagresultat inn i en IP-regel er et øyeblikksbilde, ikke en domenepolicy.

Bestem hvor gammelt et svar kan være før regelen er feil, og hva ruteren gjør når oppslaget mislykkes. En regel som beholder den sist kjente adressen, kan overleve en tjenestemigrering; en regel som forkaster oppføringen, kan stille stoppe tunnelleringen. Begge atferdene er akseptable hvis de er skrevet ned ved regelen.

Definer den utilgjengelige tilstanden

En rutepreferanse håndhever ikke VPN-only-trafikk. Når tunnelen er nede, kan ruteren blokkere strømmen, sende den direkte eller bruke en annen tunnel, og hvert valg har en forskjellig feilsignatur.

Bestem hvilken kravet trenger, og verifiser det ved å stoppe tunnelen og følge strømmen:

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 fra ruteren selv, er et eget område. DNS-videreformidling, oppdateringssjekker og overvåking kan starte nye strømmer fra ruteren selv i stedet for å arve enhetens kildematch. Ta eksplisitt høyde for disse strømmene, ellers vil de vises som uforklarte lekkasjer i loggene.