VPN-klient på en LAN-server: hvorfor svar forlader den forkerte vej

Symptomerne følger ét mønster: en vært virker, derefter opretter den forbindelse til en VPN som klient, og nu når LAN-klienter den, mens dens svar forsvinder. En optagelse på værten viser, at svarene forlader gennem tunneleenheden i stedet for LAN-interfacet. Intet ved tunnelen er i stykker, og rettelsen er en rute, ikke en genopkobling. Gå gennem de fire kontroller nedenfor i rækkefølge, og stop ved den første, der fejler.

Et svar er en ny pakke, ikke en tilbagevenden

Det hjælper at slippe ideen om, at et svar rejser tilbage ad den vej, en anmodning tog. Routingen besluttes pr. pakke, pr. retning, på den sendende vært. En anmodning, der ankom fra 10.64.0.23 inde i tunnelen, skaber ingen returvej; når værten svarer, matches svaret mod tabellen som en ny pakke og forlader gennem den rute, der vinder.

Derfor giver en klient med fuld tunnel på en maskine, der også betjener et LAN, så forvirrende en fejl. Klienten installerer en standardrute, eller de to halve standardruter som nogle klienter foretrækker, og svaret til en LAN-klient matcher nu tunnelen. Det går til udbyderen, som ingen grund har til at videresende det, og LAN-klienten ser en timeout trods en vært, der er oppe og svarer lokalt. Optagelsen gør det indlysende, og rutetabellen forklarer det.

Hold to undernet i hovedet, mens du læser resten. Det ene er den VPN-adressepulje, fjernklienterne kommer fra, i dette eksempel 10.64.0.0/24. Det andet er det LAN, der skal blive ved med at virke, 172.16.24.0/24 med sin router på 172.16.24.1. Fejlen er, at trafik mellem dem bliver afgjort af standardruten.

Bevis det med optagelsen og opslaget

Før du ændrer noget, skal du bekræfte, hvilken enhed svaret vil bruge. Et opslag er hurtigere end en optagelse og svarer på præcis det spørgsmål, som kernen vil besvare, når pakken bygges.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Læs svaret i to dele. Hvis det nævner dev tun0, vil værten indkapsle svaret og give det til udbyderen, og LAN-klienten vil aldrig se det. Hvis det nævner dev eth0, men klienten stadig får en timeout, er ruten allerede rigtig, og pakken bliver kasseret senere, hvilket er et andet problem med en anden rettelse.

Optagelsen i samme trin afgør den tvivl, et ping ikke kan. Et ekkosvar, der når LAN-klienten, beviser, at en eller anden vej virker, ikke hvilket interface der bar det, så kør optagelsen på værten selv og se, hvor rammerne forlader. En printer på samme undernet bliver ved med at svare, fordi dens direkte rute er mere specifik end tunnelens standardrute. En videresendt port fejler præcis som enhver anden strøm, fordi tabellen vælger interfacet, og forbindelsen gør ikke.

Installer den smalleste rute, der overgår tunnelen

Præfikslængden afgør, ikke metrikken, så en rute til klientpuljen gennem LAN-routeren vinder over enhver standardrute, VPN-klienten installerer. Der er ikke brug for metrikkirurgi, og standardruten kan blive præcis, hvor klienten satte den.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Brug replace i stedet for add, fordi en klient, der genopkobler, vil have installeret sin egen post, og en anden add fejler med en fejl om, at ruten findes, som lyder som et tilladelsesproblem. På en Windows-vært er ækvivalenten route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, hvor -p holder posten gennem genstart, da klienten kan genopbygge tabellen, når tunnelen kommer op igen. På en moderne Windows-vært er den understøttede ækvivalent New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, mens den ældre route-kommando bevares som en ældre form.

Én detalje afgør, om dette er korrekt eller blot plausibelt: næste hop skal være den router, der faktisk ejer vejen tilbage til klienterne. At pege ruten mod en adresse, der selv nås gennem tunnelen, skaber en løkke, som viser sig som periodisk tab i stedet for en ren fejl. Bekræft, at næste hop ligger på LAN-undernettet, før du bekræfter linjen.

Behold svaret efter en genopkobling

En rute tilføjet i hånden overlever i bedste fald til næste genopkobling. Hvis klientpuljen er dynamisk, fastgør den i serverkonfigurationen, så det præfiks, du ruttede, forbliver det præfiks, klienterne får; ellers peger posten på et tomt område, og symptomet vender tilbage uger senere uden åbenlys årsag. At skrive ruten i klientens eget up-script er den anden pålidelige mulighed, fordi det kører, efter klienten har skrevet tabellen om.

En stateful firewall kan stadig besejre en korrekt rute. Hvis optagelsen nu viser, at svaret forlader gennem eth0, og klienten stadig får en timeout, skal du kontrollere, om værten kasserer pakken, før den sendes. Streng reverse-path-filtrering og net.ipv4.conf.all.rp_filter sat til 1 kasserer pakker, hvis kilde ikke ville blive rutet tilbage ud gennem det interface, de ankom på, hvilket er præcis det asymmetriske tilfælde, du netop har skabt og derefter rettet, og conntrack-tilstand fortæller den samme historie for videresendte porte.

Den sidste kontrol er den, folk springer over: gentag opslaget, efter at tunnelen har været nede og oppe igen. Fire værdier skal matche det, du skrev ned: destinationen, næste hop, enheden og den valgte kilde. Hvis nogen af dem har flyttet sig, har klienten skrevet tabellen om, og rettelsen hører i dens hooks, ikke i en shell-historik.