Svar frå nettstad-til-nettstad-VPN går ikkje gjennom tunnelen

Eg brukte ein formiddag på ein tunnel som kom reint opp og flytta trafikk i nøyaktig éi retning: filialen nådde filserveren i hovudkvarteret, og kvar sambinding som vart opna frå hovudkvarteret inn til filialen, døydde ved første SYN. SA-ane var oppe, tunnelteljarane steig, og handtrykket var aldri problemet. Svaret vart ruta ein stad tunnelen ikkje dekkjer, og det valet høyrer til den fjerne sida. Eit nettstad-til-nettstad-VPN fraktar berre pakkane ein vert overleverer til gatewayen, og kvar vert tek det valet separat, i kvar retning, frå sin eigen rutetabell.

Begge retningane blir ruta kvar for seg

IP hugsar ingenting om retninga til ein samtale. Kvar vert som sender ein pakke, gjer sitt eige oppslag på lengste prefiks, vel ein neste hopp og gløymer avgjerda. Førespurnaden og svaret er to uavhengige pakkar som tilfeldigvis høyrer til same sambinding, og tunnelen er ein hopp som kvar av dei kan bruke eller la vere. Ingenting i IKE-utvekslinga lærer den fjerne serveren korleis han når subnettet ditt; forhandlinga blir berre samde om kva prefiks som kan krypterast.

Den semja er den andre porten. På strongSwan er trafikkselektorane leftsubnet og rightsubnet, og ein pakke der kjelda eller målet fell utanfor det forhandla paret, blir ikkje kryptert, uansett kva rutetabellen seier. Eit prefiks som blir ruta inn i tunnelen men manglar i selektorane, er ein stille einvegsfeil: ruta ser rett ut, pakken går likevel ut i klartekst eller blir droppa, og berre charon-loggen klagar.

Den fjerne verten veit ingenting om tunnelen din

Inne i det fjerne LAN-et er svaret ein vanleg pakke adressert til klienten din. Målverten ser ingen IPsec-header og har ingen grunn til å føretrekkje VPN-gatewayen; han slår opp prefikset ditt, finn ingenting meir spesifikt enn standardruta si og følgjer den. Viss standardruta peikar på ein kjernepersonbrannmur, har brannmuren anten ei rute tilbake i tunnelen eller ikkje. Når han ikkje har det, får du eit stille dropp, ein ICMP unreachable eller eit svar som går ut via det internettvendte grensesnittet og døyr.

Eit andre grensesnitt er nok til å bryte dette, sjølv når ei rute finst. Ein NAS med administrasjonslenke på eit anna VLAN, ein server med reserve-uplink, ein policyregel som sender eitt kjeldeområde inn i ein andre tabell: kven som helst av desse kan fange svaret. På Linux viser ip rule show og ip route show table all reglar og tabellar som standardoppføringa skjuler.

Les avgjerda på maskinen som sender svaret

Spør kjernen før du endrar noko, og gi han kjeldadressa, fordi kjeldavhengige reglar endrar svaret.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Utdataa namngir det utgåande grensesnittet og neste hopp. Viss grensesnittet ikkje er det som vender mot VPN-gatewayen, har du funne feilen, og det som står att er å velje kvar ruta høyrer heime. Ein ping frå gatewayen beviser lite her: han svarar med ei adresse den fjerne verten kan plassere, ikkje adressa til laptoppen din.

På Windows er ekvivalentane Find-NetRoute -RemoteIPAddress 10.10.5.10 for avgjerda og Get-NetRoute for tabellen. Ei rute lagt til med New-NetRoute som har høgare metrikk enn standardruta, taper stille, så les metrikkolonnen, ikkje oppføringa. Stadfest deretter med pakkar: tcpdump -ni any "host 10.10.5.10 and tcp port 445" på det fjerne LAN-grensesnittet viser førespurnaden, og det same filteret på tunnelsida viser om eit svar kom tilbake. Førespurnad synleg utan svar betyr at svaret vart ruta ein annan stad eller droppa; eit svar på feil grensesnitt gir deg syndaren før du rører ei rute.

Når gatewayen til serveren ikkje er VPN-endepunktet

Mange nettstader set ein brannmur mellom serverane og konsentratoren. Den brannmuren vidaresender svaret, så han treng ei rute for klientprefikset ditt mot VPN-gatewayen, og vidaresendingspolicy i begge retningar. Tilstandsfulle einingar gjer det verre: førespurnaden kryssa brannmuren frå ein LAN-vert han tillét, svaret kjem no frå ei anna retning, og oppføringa for tilkoplingssporing passar ikkje lenger, så pakken blir forkasta som ugyldig i staden for nekta. Derfor ser policy-loggen tom ut medan trafikken forsvinn.

Gatewayen har sin eigen andre filter. Linux’ omvendt sti-filtrering droppar pakkar der kjelda ikkje er nåbar gjennom grensesnittet dei kom inn på, og det er nøyaktig forma til ein legitim asymmetrisk returveg. rettleiinga til strongSwan for vidaresending krev net.ipv4.ip_forward og ein lempeleg net.ipv4.conf.all.rp_filter nettopp derfor. Ein streng verdi på 1 på ein av gatewayane bryt stille ei korrekt rute, og nstat -az viser droppa viss du veit kvar du skal sjå.

Rut eller omset, og verifiser deretter i begge retningar

Dei to reparasjonane er ikkje likeverdige. Å leggje til ei rute held klientadressa intakt, så kjeldebaserte reglar, revisjonsloggar og applikasjonar som registrerer den som ringer, held fram med å verke; prisen er at kvar hopp som tek avgjerda treng ruta, altså fleire stader å ta feil. Maskering på den fjerne gatewayen krympar returvegen til ein hopp, fordi svaret no er adressert til gatewayen sjølv, og skjuler kva klient som gjorde kva.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Vel det medvite: når klientane først framstår som adressa til gatewayen, sluttar kjeldebaserte ACL-ar å skilje dei, og conntrack må halde på mappinga slik at svaret blir skrive tilbake i tunnelen. Viss selektorane framleis utelukkar klientprefikset, endrar NAT ingenting, fordi førespurnaden aldri kom inn i tunnelen.

Før du kallar det reparert, stadfest fire ting i rekkjefølgje: ruta på verten som sender svaret, ruta på kvar hopp som vidaresender det, selektorane som dekkjer begge prefiksa, og eit opptak som viser svaret gå inn i tunnelen med kjelda du ventar. Gjenta deretter testen frå den andre nettstaden. Éi retning som passerer er eit halvope design, og den andre retninga feilar vanlegvis av ein annan grunn enn den du nettopp reparerte.