Hvorfor et OpenVPN-UDP-svar forlater feil adresse

En OpenVPN-klient ringer én adresse, serveren svarer fra en annen, og tunnelen kommer aldri opp. Serverloggen viser at pakken ankommer, og en opptak viser et svar som forlater verten, så feilen får klienten skylden. På en vert med flere grensesnitt, eller flere adresser på ett grensesnitt, er de to partene rett og slett uenige om hvilken adresse som er i bruk. Svaret er gyldig på IP-nivå, men mange klienter forkaster et datagram der kilden ikke er adressen de kontaktet.

Hva klienten ser når kilden endres

En UDP-socket som ikke er bundet til en bestemt lokal adresse har ingen fast kilde, så kjernen velger en ved sending. Det valget kommer fra et ruteoppslag mot klientens adresse, og kilden blir adressen til grensesnittet oppslaget velger. På en maskin med ett grensesnitt er valget usynlig; på en vert med en administrasjonsadresse, en offentlig adresse og en sekundæradresse på samme nettverkskort avhenger det av rutemetrikker og -policy. Policybasert ruting gjør avviket mer sannsynlig snarere enn mindre, fordi en regel kan velge en oppstrømslenke klienten aldri nådde. En standardrute lært fra én leverandør pluss en kilderegel som peker på en annen er nok til å frembringe det.

Klienter som filtrerer svar, og tilkoblingssporing som forventer den nøyaktige firedoblingen og kilden, vil forkaste svaret uten en nyttig melding. Deretter utløper tunnelen som om ingenting var kommet, og det er derfor dette feilaktig oppfattes som et brannmurproblem på klientsiden. Et opptak tatt bare på serveren bekrefter feilen i stedet for å forklare den, fordi svaret virkelig forlater verten. Sammenlign svarets kilde med adressen klienten ringte, før du endrer noe annet.

Hva multihome-valget faktisk gjør

Direktivet skrives som multihome i en konfigurasjonsfil og som --multihome på kommandolinjen, og det får en UDP-server til å svare fra adressen klientens pakke nådde frem til. Kjernen leverer den opprinnelige måladdessen som tilleggsdata ved mottak, og OpenVPN bruker den verdien som kilde for svaret. En server som lytter på en jokeradresse, local 0.0.0.0 for IPv4 eller dens IPv6-motstykke, oppfører seg dermed som om hver klient hadde nådd en dedikert lytter. Klienter som kom inn via den offentlige adressen, får svar fra den offentlige adressen, og klienter på en intern adresse får svar fra den. Ingenting annet på pakkens vei flytter seg: ruten, filterreglene og tunnelkonfigurasjonen forblir nøyaktig som de var.

Nettopp denne siste egenskapen er grunnen til at valget er trygt å legge til på en ellers fungerende server, og også grunnen til at det ikke kan reparere et filter som bare tillater én adresse. Pakken må fortsatt godtas på veien den tar, så kildekorreksjonen endrer svarets opphav og ingenting mer. Det er også bare for UDP: en TCP-lytter har ikke dette problemet i samme form, fordi forbindelsen identifiseres av firedoblingen og ikke av svarets kildeadresse.

Når en fast lokal adresse er feil standard

Før du griper til valget, sjekk om serveren binder én bestemt lokal adresse, fordi en bundet lytter alltid svarer fra den adressen. Det er riktig for en utplassering med ett grensesnitt og galt så snart klienter lovlig bruker mer enn én adresse. Hvis bindingen var bevisst, avgjør om serveren i det hele tatt bør godta trafikk på flere adresser. Å fjerne bindingen øker eksponeringen, så de tillatte grensesnittene og kildenettverkene må håndheves av tjenesten og filteret, ikke bare av bindingsadressen.

OpenVPN-referansen begrenser valget til UDP-servere, noterer den ekstra behandlingen på pakkens vei og registrerer hvilke plattformer som støtter det. Bekreft det på den installerte utgivelsen før du planlegger ut fra det. Der det ikke støttes, er alternativet å binde den bestemte adressen eller rette returruten, og begge er smalere endringer enn de ser ut ved første øyekast. Jokerlytting har også konsekvenser utover svar: en server på alle adresser er tilgjengelig fra alle nettverk verten er knyttet til, og det er kanskje ikke den eksponeringen noen hadde tenkt seg.

Bevis svarets kilde utenfra

Test utenfra i forhold til serveren, og noter den nøyaktige adressen og transporten klienten brukte før du tar opp noe. De tre undersøkelsene nedenfor svarer på tre forskjellige spørsmål, og rekkefølgen er viktig.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Opptaket viser kildeadressen på svaret, og det er det faktum hele artikkelen dreier seg om. Socketlisten viser hva serveren faktisk bandt, fordi en jokerlytter og en bestemt lytter ser identiske ut i en konfigurasjonsfil og oppfører seg forskjellig på nettet. Ruteoppslaget viser kilden kjernen ville valgt for den strømmen, og det forklarer opptaket før du endrer noe. Gjenta alle tre for IPv4 og IPv6 hver for seg, fordi de er separate lyttere og separate oppslag, og en jokerpost for den ene familien sier ingenting om den andre.

Ruting, oppdagelse og filtrering forblir atskilt

Å bevare svarets kilde installerer ikke en utgående rute, oppdaterer ikke dynamisk DNS og får ikke den ene adressefamilien til å godta den andre. På en server med flere oppstrømslenker må returveien for hver kilde avtales bevisst, ellers forlater svar et grensesnitt som klientens filter aldri tillot. På samme måte må en ny adresse etter et prefiksskifte nå klientene gjennom oppdagelse og den støttede gjenoppkoblingsflyten, ikke gjennom den gamle posten.

La serveridentitetskontroller og sertifikatverifisering være nøyaktig som de er, fordi en endret adresse ikke rettferdiggjør å godta en uverifisert motpart. Hvis svaret nå forlater den tiltenkte kilden og tunnelen fortsatt feiler, betrakt kildefeilen som løst og gå videre. Den neste observerte feilen hører til ruting, filtrering eller autentisering, og nok en endring av lytteren når den ikke. Skriv svarets kilde i saken ved siden av adressen klienten ringte, slik at neste person kan kontrollere samme faktum med én kommando.