VPN-regler på routeren: match kilden og destinationen

Routershoppingsider viser VPN-routing som én afkrydsningsboks, og den formulering skjuler tre forskellige spørgsmål. Matcher reglen enheden, der sender trafikken, serveren, der modtager den, eller begge? Hvad sker der med trafik, der ikke matcher nogen af dem? Og når to regler overlapper, hvilken vinder så? Hvis du skriver svaret som et par af kilde og destination, bliver en vag funktionsliste til et design, der kan testes.

Funktionsnavnet skjuler to ender

En medieafspiller, der skal bruge tunnelen, er et kildematch. Et privat kontorpræfiks, der skal kunne nås gennem tunnelen, er et destinationsmatch. En arbejdsstation, der kun skal bruge tunnelen til én tjeneste, er begge, og det snit er det tilfælde, som de fleste forbrugerfirmware håndterer dårligt.

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

Et produkt, der tilbyder en enhedsliste eller en global destinationsliste, udtrykker måske ikke «kun denne enhed, kun disse destinationer». Forskellen er ikke kosmetisk: en global destinationsregel sender alle enheders trafik til det websted gennem tunnelen, og en enhedsregel sender al den enheds trafik. Ingen af dem er kravet. Test det tilfælde med to enheder, før du stoler på skærmen.

Byg reglen som et snit

En tabel holder designet ærligt. Sæt scenariet til venstre, og navngiv derefter afsendermatch og mål-match hver for sig:

Den tredje række er den interessante, fordi den kræver begge halvdele på én gang. Hvis firmwaren kun kan udtrykke én akse, må kravet deles i to regler eller flyttes til en enhed, der kan.

Hold kildeidentiteten stabil. En DHCP-reservation, et dedikeret segment eller en enhedsidentitetsmekanisme virker alle, men en adresse, der ændrer sig, når leasingaftalen udløber, gør ikke. Medtag IPv6, fordi én IPv4-adresse ikke identificerer al en enheds trafik.

Prioriteten afgør overlapningen

Overlappende regler er normale. En bred enhedsregel og en smal destinationsregel kan begge beskrive én strøm, og den dokumenterede prioritetsrækkefølge afgør, hvilken der vinder. En indbydende indstillingsskærm fortæller dig ikke den rækkefølge.

Læs manualen om rækkefølgen og om tilfældet uden match, og test derefter begge med trafik, du kan observere:

ip rule show
ip route get 203.0.113.10

Hvis dokumentationen ikke angiver rækkefølgen, må du antage, at den smallere regel måske ikke vinder, og designe uden om det. To regler, der ikke kan komme i konflikt, er lettere at understøtte end én smart regel med en udokumenteret forrang.

Navne kræver en opdateringspolitik

En destination skrevet som et domæne tilføjer et vedligeholdelsesproblem. Routeren skal opløse det, opdatere mappingen, håndtere flere adresser og underdomæner og klare applikations-DNS, der omgår den forventede resolver.

At kopiere ét opslagsresultat ind i en IP-regel er et øjebliksbillede, ikke en domænepolitik.

Beslut, hvor gammelt et svar må være, før reglen er forkert, og hvad routeren gør, når opløsningen fejler. En regel, der beholder den sidst kendte adresse, kan overleve en tjenestemigrering; en regel, der dropper posten, kan lydløst stoppe tunnelleringen. Begge adfærdsformer er acceptable, hvis de er skrevet ned ved reglen.

Definér den utilgængelige tilstand

En rutepræference gennemtvinger ikke VPN-only-trafik. Når tunnelen er nede, kan routeren blokere strømmen, sende den direkte eller bruge en anden tunnel, og hvert valg har en forskellig fejlsignatur.

Beslut, hvilken kravet har brug for, og verificér det ved at 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

Trafik, der udgår fra routeren selv, er et separat område. DNS-videresendelse, opdateringstjek og overvågning kan starte nye strømme fra routeren selv i stedet for at arve enhedens kildematch. Tag højde for disse strømme eksplicit, ellers vises de som uforklarede lækager i loggene.