Svar fra nettsted-til-nettsted-VPN går ikke gjennom tunnelen

Jeg brukte en formiddag på en tunnel som kom rent opp og flyttet trafikk i nøyaktig én retning: filialen nådde filserveren i hovedkvarteret, og hver forbindelse som ble åpnet fra hovedkvarteret inn til filialen, døde ved første SYN. SA-ene var oppe, tunneltellerne steg, og håndtrykket var aldri problemet. Svaret ble rutet et sted tunnelen ikke dekker, og det valget tilhører den fjerne siden. Et nettsted-til-nettsted-VPN frakter bare pakkene en vert overleverer til gatewayen, og hver vert tar det valget separat, i hver retning, fra sin egen rutetabell.

Begge retningene rutes hver for seg

IP husker ingenting om retningen til en samtale. Hver vert som sender en pakke, gjør sitt eget oppslag på lengste prefiks, velger ett neste hopp og glemmer beslutningen. Forespørselen og svaret er to uavhengige pakker som tilfeldigvis hører til samme forbindelse, og tunnelen er ett hopp som enhver av dem kan bruke eller la være. Ingenting i IKE-utvekslingen lærer den fjerne serveren hvordan den når subnettet ditt; forhandlingen blir bare enige om hvilke prefikser som kan krypteres.

Den enigheten er den andre porten. På strongSwan er trafikkselektorene leftsubnet og rightsubnet, og en pakke der kilden eller målet faller utenfor det forhandlede paret, krypteres ikke, uansett hva rutetabellen sier. Et prefiks som rutes inn i tunnelen men mangler i selektorene, er en stille enveis feil: ruten ser riktig ut, pakken går likevel ut i klartekst eller droppes, og bare charon-loggen klager.

Den fjerne verten vet ingenting om tunnelen din

Inne i det fjerne LAN-et er svaret en vanlig pakke adressert til klienten din. Målverten ser ingen IPsec-header og har ingen grunn til å foretrekke VPN-gatewayen; den slår opp prefikset ditt, finner ingenting mer spesifikt enn standardruten sin og følger den. Hvis standardruten peker på en kjernepersonbrannmur, har brannmuren enten en rute tilbake i tunnelen eller ikke. Når den ikke har det, får du et stille dropp, en ICMP unreachable eller et svar som går ut via det internettvendte grensesnittet og dør.

Et andre grensesnitt er nok til å bryte dette, selv når en rute finnes. En NAS med administrasjonslenke på et annet VLAN, en server med reserve-uplink, en policyregel som sender ett kildeområde inn i en andre tabell: hvilken som helst av disse kan fange svaret. På Linux viser ip rule show og ip route show table all regler og tabeller som standardoppføringen skjuler.

Les beslutningen på maskinen som sender svaret

Spør kjernen før du endrer noe, og gi den kildeadressen, fordi kildavhengige regler endrer 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 )"

Utdataene navngir det utgående grensesnittet og neste hopp. Hvis grensesnittet ikke er det som vender mot VPN-gatewayen, har du funnet feilen, og det som gjenstår er å velge hvor ruten hører hjemme. En ping fra gatewayen beviser lite her: den svarer med en adresse den fjerne verten kan plassere, ikke adressen til laptopen din.

På Windows er ekvivalentene Find-NetRoute -RemoteIPAddress 10.10.5.10 for beslutningen og Get-NetRoute for tabellen. En rute lagt til med New-NetRoute som har høyere metrikk enn standardruten, taper stille, så les metrikkolonnen, ikke oppføringen. Bekreft deretter med pakker: tcpdump -ni any "host 10.10.5.10 and tcp port 445" på det fjerne LAN-grensesnittet viser forespørselen, og det samme filteret på tunnelsiden viser om et svar kom tilbake. Forespørsel synlig uten svar betyr at svaret ble rutet et annet sted eller droppet; et svar på feil grensesnitt gir deg synderen før du rører en rute.

Når serverens gateway ikke er VPN-endepunktet

Mange nettsteder setter en brannmur mellom serverne og konsentratoren. Den brannmuren videresender svaret, så den trenger en rute for klientprefikset ditt mot VPN-gatewayen, og videresendingspolicy i begge retninger. Tilstandsfulle enheter gjør det verre: forespørselen krysset brannmuren fra en LAN-vert den tillot, svaret kommer nå fra en annen retning, og oppføringen for tilkoblingssporing passer ikke lenger, så pakken forkastes som ugyldig i stedet for nektet. Derfor ser policy-loggen tom ut mens trafikken forsvinner.

Gatewayen har sin egen andre filter. Linux’ omvendt sti-filtrering dropper pakker der kilden ikke er nåbar gjennom grensesnittet de kom inn på, og det er nøyaktig formen til en legitim asymmetrisk returvei. strongSwans veiledning for videresending krever net.ipv4.ip_forward og en lempet net.ipv4.conf.all.rp_filter nettopp derfor. En streng verdi på 1 på en av gatewayene bryter stille en korrekt rute, og nstat -az viser droppene hvis du vet hvor du skal se.

Rut eller oversett, og verifiser deretter i begge retninger

De to reparasjonene er ikke likeverdige. Å legge til en rute holder klientadressen intakt, så kildbaserte regler, revisjonslogger og applikasjoner som registrerer den som ringer, fortsetter å virke; prisen er at hvert hopp som tar beslutningen trenger ruten, altså flere steder å ta feil. Maskering på den fjerne gatewayen krymper returveien til ett hopp, fordi svaret nå er adressert til gatewayen selv, og skjuler hvilken klient som gjorde hva.

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

Velg det bevisst: når klientene først fremstår som gatewayens adresse, slutter kildbaserte ACL-er å skille dem, og conntrack må holde på mappingen slik at svaret skrives tilbake i tunnelen. Hvis selektorene fortsatt utelukker klientprefikset, endrer NAT ingenting, fordi forespørselen aldri kom inn i tunnelen.

Før du kaller det reparert, bekreft fire ting i rekkefølge: ruten på verten som sender svaret, ruten på hvert hopp som videresender det, selektorene som dekker begge prefiksene, og en opptak som viser svaret gå inn i tunnelen med kilden du forventer. Gjenta deretter testen fra det andre nettstedet. Én retning som passerer er et halvåpent design, og den andre retningen feiler vanligvis av en annen grunn enn den du nettopp reparerte.