VPN-klient på ein LAN-server: kvifor svar forlèt den gale vegen

Symptoma følgjer eitt mønster: ein vert fungerer, deretter koplar han til eit VPN som klient, og no når LAN-klientar han medan svara forsvinn. Eit opptak på verten viser at svara forlèt gjennom tunneleininga i staden for LAN-grensesnittet. Ingenting ved tunnelen er øydelagt, og rettinga er ei rute, ikkje ei ny tilkopling. Gå gjennom dei fire kontrollane nedanfor i rekkjefølgje, og stopp ved den første som feilar.

Eit svar er ein ny pakke, ikkje ei tilbakevending

Det hjelper å sleppe ideen om at eit svar reiser tilbake langs vegen ein førespurnad tok. Ruting blir avgjord per pakke, per retning, på verten som sender. Ein førespurnad som kom frå 10.64.0.23 inne i tunnelen skapar ingen returveg; når verten svarar, blir svaret samanlikna med tabellen som ein ny pakke og forlèt gjennom den ruta som vinn.

Difor gir ein klient med full tunnel på ein maskin som òg tener eit LAN så forvirrande ein feil. Klienten installerer ei standardrute, eller dei to halve standardrutene som enkelte klientar føretrekkjer, og svaret til ein LAN-klient samsvarar no med tunnelen. Det går til leverandøren, som ikkje har grunn til å vidaresende det, og LAN-klienten ser ein tidsavbrot trass i ein vert som er oppe og svarar lokalt. Opptaket gjer det innlysande, og rutetabellen forklarar det.

Hald to subnett i hovudet medan du les resten. Det eine er VPN-adressepoolen fjernklientane kjem frå, i dette dømet 10.64.0.0/24. Det andre er LAN-et som må halde fram med å verke, 172.16.24.0/24 med rutaren på 172.16.24.1. Feilen er at trafikk mellom dei blir avgjord av standardruta.

Prov det med opptaket og oppslaget

Før du endrar noko, stadfest kva eining svaret vil bruke. Eit oppslag er raskare enn eit opptak og svarar på nøyaktig det spørsmålet kjernen vil svare på når pakken blir bygd.

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

Les svaret i to delar. Om det nemner dev tun0, vil verten kapsle inn svaret og gi det til leverandøren, og LAN-klienten vil aldri sjå det. Om det nemner dev eth0, men klienten får framleis tidsavbrot, er ruta allereie riktig og pakken blir kasta seinare, noko som er eit anna problem med ei anna retting.

Opptaket i same trinn avgjer den tvilen ein ping ikkje kan. Eit ekkosvar som når LAN-klienten provar at ein eller annan veg verkar, ikkje kva grensesnitt som bar det, så køyr opptaket på verten sjølv og sjå kvar rammene forlèt. Ein skrivar på same subnett held fram med å svare, fordi den direkte ruta hans er meir spesifikk enn standardruta til tunnelen. Ein vidaresend port feilar akkurat som kvar annan straum, fordi tabellen vel grensesnittet og tilkoplinga ikkje.

Installer den smalaste ruta som overgår tunnelen

Prefikslengda avgjer, ikkje metrikken, så ei rute for klientpoolen gjennom LAN-rutaren vinn over kvar standardrute VPN-klienten installerer. Metrikkirurgi er ikkje naudsynt, og standardruta kan bli nøyaktig der klienten sette henne.

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 staden for add, fordi ein klient som koplar til på nytt vil ha installert si eiga oppføring, og ein andre add feilar med ein feil om at ruta finst, som blir lesen som eit løyveproblem. På ein Windows-vert er ekvivalenten route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, der -p held oppføringa gjennom omstartar, sidan klienten kan byggje tabellen på nytt når tunnelen kjem opp att. På ein moderne Windows-vert er den støtta ekvivalenten New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, medan den eldre route-kommandoen blir halden som ei eldre form.

Ein detalj avgjer om dette er riktig eller berre sannsynleg: neste hopp må vere rutaren som faktisk eig vegen tilbake til klientane. Å peike ruta mot ei adresse som sjølv blir nådd gjennom tunnelen skapar ei løkke som viser seg som periodisk tap i staden for ein rein feil. Stadfest at neste hopp ligg på LAN-subnettet før du stadfester linja.

Hald på svaret etter ei ny tilkopling

Ei rute lagt til for hand overlever i beste fall til neste tilkopling. Om klientpoolen er dynamisk, fest henne i serverkonfigurasjonen slik at prefikset du ruta forblir prefikset klientane får; elles peikar oppføringa på eit tomt område, og symptomet kjem tilbake veker seinare utan openberr årsak. Å skrive ruta i klienten sitt eige up-skript er det andre pålitelege alternativet, fordi det blir køyrt etter at klienten har skrive tabellen på nytt.

Ein tilstandsbasert brannmur kan framleis slå ei riktig rute. Om opptaket no viser at svaret forlèt gjennom eth0, og klienten får framleis tidsavbrot, sjekk om verten kastar pakken før han blir send. Streng revers-stifiltrering og net.ipv4.conf.all.rp_filter sett til 1 kastar pakkar der kjelda ikkje ville bli ruta tilbake gjennom grensesnittet dei kom inn på, og det er nøyaktig det asymmetriske tilfellet du nettopp skapte og deretter retta, og conntrack-tilstanden fortel den same soga for vidaresende portar.

Den siste kontrollen er den folk hoppar over: gjer oppslaget om att etter at tunnelen har vore nede og oppe igjen. Fire verdiar skal stemme med det du skreiv ned: destinasjonen, neste hopp, eininga og den valde kjelda. Om nokon av dei har flytta seg, har klienten skrive tabellen på nytt, og rettinga høyrer i krokane hans og ikkje i ei shell-historie.