Hvorfor en /32-værtsrute holder VPN-endepunktet tilgængeligt

Du åbner routingtabellen efter forbindelsen og finder én adresse, der routes gennem tunnelen, mens undernettet omkring den stadig går til den lokale gateway. Den post er en værtsrute: én adresse, matchet af et præfiks med kun ettaller. Det betyder noget, fordi routingbeslutninger bruger det længste matchende præfiks, så en /32 kan tilsidesætte en /24 eller en standardrute uden at ændre nogen af dem. Om det er en omhyggelig undtagelse eller et fremtidigt udfald, afhænger af, hvilken adresse den navngiver, og hvem der vedligeholder den.

Én adresse, én post i tabellen

En IPv4-værtsrute har et /32-præfiks, og en IPv6-værtsrute har /128, hvilket betyder, at posten kan matche præcis én destinationsadresse. Intet andet i tabellen flytter sig: det dækkende undernet og standardruten bliver, hvor de var. Den smalle post vinder for den adresse, fordi dens præfiks er længere, ikke fordi den blev tilføjet senere.

Den egenskab gør en værtsrute til en god undtagelse og en dårlig vane. To /32-poster, der navngiver en tjenestes hoveddør, dækker ikke dens anden adresse, dens IPv6-adresse eller den adresse, den flytter til næste måned. En tabel fuld af uforklarede enkeltadresseposter betyder normalt, at nogen blev ved med at lappe omkring en undernetsbeslutning i stedet for at træffe den. Læs først præfiksets længde, og spørg derefter, hvad posten skal beskytte.

Læs posten fra klienten og ud

Begynd ved maskinen med problemet, for den samme adresse kan routes forskelligt på en bærbar og på gatewayen foran den. Spørg kernen, hvilken vej den ville vælge for den præcise adresse, programmet bruger, i stedet for at læse tabellen fra toppen. Svaret omfatter grænsefladen og det næste hop, som sammen er beslutningen.

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

Gentag forespørgslen for den adressefamilie, programmet faktisk vælger, da en klient kan foretrække IPv6 og stille omgå en IPv4-undtagelse. Sammenlign resultatet før og efter tunnelen kommer op, og gem begge output. Den sammenligning viser, om klienten tilføjede posten ved forbindelsen, eller om den allerede var der.

En permanent post og en runtime-post fejler forskelligt. Runtime-posten forsvinder med sessionen, mens den permanente overlever en genstart og bliver ved med at sende trafik til en gateway, der ikke findes længere.

Endepunktsundtagelsen og rekursionsfælden

VPN-klienter installerer normalt en værtsrute til serverens ydre adresse gennem den oprindelige gateway, før de omdirigerer standardruten. Uden den post ville de krypterede pakker blive sendt ind i den tunnel, de prøver at bygge, og forbindelsen ville køre i ring, indtil den timede ud.

Fælden opstår, når tunnelens accepterede undernet tilfældigvis omfatter den endepunktsadresse, eller når en anden profil senere tilføjer en bredere rute. Så taber endepunktsposten til et længere præfiks, og sessionen bryder sammen, så snart den begynder at føre trafik. At skrive endepunktsadressen ved siden af de accepterede undernet er den billigste måde at opdage kollisionen før brugerne. Det forklarer også, hvorfor den samme profil virker fra ét netværk og fejler fra et andet.

Kontroller den vej, programmet virkelig bruger

Et vellykket ping til værtsnavnet er svagt bevis, når programmet forbinder til en anden adresse eller en anden familie. Kontroller den præcise kombination af adresse, familie, port og grænseflade fra maskinen, der kører klienten.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

Er vejen forkert, så afgør, om kravet er et netværk eller én adresse, før du redigerer noget. Et krav om én adresse berettiger en værtsrute med en kommentar og en ejer; en tjeneste med roterende adresser har brug for domænebaseret routing eller en ærlig undernetsbeslutning.

Fjern poster, der ikke længere svarer til en reel destination, og noter dem, du beholder. En uforklaret /32 kan tre måneder senere ikke skelnes fra en fejl, og den næste person sletter den uden at vide, hvad der afhang af den.