VPN-klient på en LAN-server: hvorfor svar forlater den gale veien

Symptomene følger ett mønster: en vert fungerer, deretter kobler den til en VPN som klient, og nå når LAN-klienter den mens svarene forsvinner. Et opptak på verten viser at svarene forlater gjennom tunneleenheten i stedet for LAN-grensesnittet. Ingenting ved tunnelen er ødelagt, og rettelsen er en rute, ikke en gjentilkobling. Gå gjennom de fire kontrollene nedenfor i rekkefølge, og stopp ved den første som feiler.

Et svar er en ny pakke, ikke en tilbakevending

Det hjelper å slippe ideen om at et svar reiser tilbake langs veien en forespørsel tok. Ruting avgjøres per pakke, per retning, på verten som sender. En forespørsel som kom fra 10.64.0.23 inne i tunnelen skaper ingen returvei; når verten svarer, blir svaret sammenlignet med tabellen som en ny pakke og forlater gjennom den ruten som vinner.

Derfor gir en klient med full tunnel på en maskin som også betjener et LAN så forvirrende en feil. Klienten installerer en standardrute, eller de to halve standardrutene som enkelte klienter foretrekker, og svaret til en LAN-klient samsvarer nå med tunnelen. Det går til leverandøren, som ikke har grunn til å videresende det, og LAN-klienten ser en tidsavbrudd til tross for en vert som er oppe og svarer lokalt. Opptaket gjør det innlysende, og rutetabellen forklarer det.

Hold to subnett i hodet mens du leser resten. Det ene er VPN-adressepoolen fjernklientene kommer fra, i dette eksempelet 10.64.0.0/24. Det andre er LAN-et som må fortsette å virke, 172.16.24.0/24 med ruteren på 172.16.24.1. Feilen er at trafikk mellom dem avgjøres av standardruten.

Bevis det med opptaket og oppslaget

Før du endrer noe, bekreft hvilken enhet svaret vil bruke. Et oppslag er raskere enn et opptak og svarer på nøyaktig det spørsmålet kjernen vil svare på når pakken bygges.

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

Les svaret i to deler. Hvis det nevner dev tun0, vil verten innkapsle svaret og gi det til leverandøren, og LAN-klienten vil aldri se det. Hvis det nevner dev eth0, men klienten fortsatt får tidsavbrudd, er ruten allerede riktig og pakken forkastes senere, noe som er et annet problem med en annen rettelse.

Opptaket i samme trinn avgjør den tvilen en ping ikke kan. Et ekkosvar som når LAN-klienten beviser at en eller annen vei virker, ikke hvilket grensesnitt som bar det, så kjør opptaket på verten selv og se hvor rammene forlater. En skriver på samme subnett fortsetter å svare, fordi dens direkte rute er mer spesifikk enn tunnelens standardrute. En videresendt port feiler akkurat som enhver annen strøm, fordi tabellen velger grensesnittet og tilkoblingen ikke.

Installer den smaleste ruten som overgår tunnelen

Prefikslengden avgjør, ikke metrikken, så en rute for klientpoolen gjennom LAN-ruteren vinner over enhver standardrute VPN-klienten installerer. Metrikkirurgi er ikke nødvendig, og standardruten kan bli nøyaktig der 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

Bruk replace i stedet for add, fordi en klient som kobler til på nytt vil ha installert sin egen oppføring, og en andre add feiler med en feil om at ruten finnes, som leses som et tillatelsesproblem. På en Windows-vert er ekvivalenten route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, der -p beholder oppføringen gjennom omstarter, siden klienten kan bygge tabellen på nytt når tunnelen kommer opp igjen. På en moderne Windows-vert er den støttede ekvivalenten New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, mens den eldre route-kommandoen beholdes som en eldre form.

En detalj avgjør om dette er riktig eller bare sannsynlig: neste hopp må være ruteren som faktisk eier veien tilbake til klientene. Å peke ruten mot en adresse som selv nås gjennom tunnelen skaper en løkke som viser seg som periodisk tap i stedet for en ren feil. Bekreft at neste hopp ligger på LAN-subnettet før du bekrefter linjen.

Behold svaret etter en gjentilkobling

En rute lagt til for hånd overlever i beste fall til neste gjentilkobling. Hvis klientpoolen er dynamisk, fest den i serverkonfigurasjonen slik at prefikset du rutet forblir prefikset klientene mottar; ellers peker oppføringen på et tomt område, og symptomet kommer tilbake uker senere uten åpenbar årsak. Å skrive ruten i klientens eget up-skript er det andre pålitelige alternativet, fordi det kjøres etter at klienten har skrevet tabellen på nytt.

En tilstandsbasert brannmur kan fortsatt beseire en riktig rute. Hvis opptaket nå viser at svaret forlater gjennom eth0, og klienten fortsatt får tidsavbrudd, sjekk om verten forkaster pakken før den sendes. Streng revers-stifiltrering og net.ipv4.conf.all.rp_filter satt til 1 forkaster pakker hvis kilde ikke ville bli rutet tilbake gjennom grensesnittet de kom inn på, og det er nøyaktig det asymmetriske tilfellet du nettopp skapte og deretter rettet, og conntrack-tilstanden forteller samme historie for videresendte porter.

Den siste kontrollen er den folk hopper over: gjenta oppslaget etter at tunnelen har vært nede og oppe igjen. Fire verdier skal stemme med det du skrev ned: destinasjonen, neste hopp, enheten og den valgte kilden. Hvis noen av dem har flyttet seg, har klienten skrevet tabellen på nytt, og rettelsen hører i krokene dens og ikke i en shell-historikk.