Kvifor eit OpenVPN-UDP-svar forlèt feil adresse

Ein OpenVPN-klient ringjer éi adresse, tenaren svarar frå ei anna, og tunnelen kjem aldri opp. Tenarloggen viser at pakken kjem inn, og eit opptak viser eit svar som går ut, så feilen får klienten skulda. På ein vert med fleire grensesnitt, eller fleire adresser på eitt grensesnitt, er dei to sidene rett og slett usamde om kva adresse som er i bruk. Svaret er gyldig på IP-nivå, men mange klientar kastar eit datagram der kjelda ikkje er adressa dei kontakta.

Kva klienten ser når kjelda blir endra

Ein UDP-sokkel som ikkje er bunden til ei bestemt lokal adresse, har inga fast kjelde, så kjernen vel ei ved sending. Det valet kjem frå eit ruteoppslag mot adressa til klienten, og kjelda blir adressa til grensesnittet oppslaget vel. På ein maskin med eitt grensesnitt er valet usynleg; på ein vert med ei styringsadresse, ei offentleg adresse og ei sekundæradresse på same nettverkskort kjem det an på rutemetrikkar og -politikk. Politikkbasert ruting gjer avviket meir sannsynleg i staden for mindre, fordi ein regel kan velje ei oppstraumslenkje klienten aldri nådde. Ei standardrute lærd frå éin leverandør pluss ein kjelderegel som peikar på ein annan, er nok til å skape det.

Klientar som filtrerer svar, og tilkoplingssporing som ventar den nøyaktige firedelen og kjelda, vil kaste svaret utan ei nyttig melding. Deretter går tunnelen ut på tid som om ingenting kom, og det er derfor dette feilaktig blir oppfatta som eit brannmurproblem på klientsida. Eit opptak teke berre på tenaren stadfestar feilen i staden for å forklare han, fordi svaret verkeleg går ut. Samanlikn kjelda til svaret med adressa klienten ringde, før du endrar noko anna.

Kva valet multihome faktisk gjer

Direktivet blir skrive som multihome i ei konfigurasjonsfil og som --multihome på kommandolinja, og det får ein UDP-tenar til å svare frå adressa pakken til klienten nådde fram til. Kjernen leverer den opphavlege måladdessa som tilleggsdata ved mottak, og OpenVPN brukar den verdien som kjelde for svaret. Ein tenar som lyttar på ei jokeradresse, local 0.0.0.0 for IPv4 eller det tilsvarande IPv6, oppfører seg dermed som om kvar klient hadde nådd ein eigen lyttar. Klientar som kom inn via den offentlege adressa, får svar frå den offentlege adressa, og klientar på ei intern adresse får svar frå den. Ingenting anna på vegen til pakken flyttar seg: ruta, filterreglane og tunnelkonfigurasjonen blir verande nøyaktig som dei var.

Nettopp denne siste eigenskapen er grunnen til at valet er trygt å leggje til på ein elles fungerande tenar, og òg grunnen til at det ikkje kan reparere eit filter som berre tillèt éi adresse. Pakken må framleis godtakast på vegen han tek, så kjelderettinga endrar opphavet til svaret og ingenting meir. Det er òg berre for UDP: ein TCP-lyttar har ikkje dette problemet i same form, fordi sambandet blir identifisert av firedelen og ikkje av kjeldeadressa til svaret.

Når ei fast lokal adresse er feil standard

Før du grip til valet, sjekk om tenaren bind éi bestemt lokal adresse, fordi ein bunden lyttar alltid svarar frå den adressa. Det er rett for ein utplassering med eitt grensesnitt og gale så snart klientar lovleg brukar meir enn éi adresse. Om bindinga var medviten, avgjer om tenaren i det heile bør godta trafikk på fleire adresser. Å fjerne bindinga aukar eksponeringa, så dei tillatne grensesnitta og kjeldenetta må handhevast av tenesta og filteret, ikkje berre av bindingsadressa.

OpenVPN-referansen avgrensar valet til UDP-tenarar, nemner den ekstra handsaminga på vegen til pakken og registrerer kva plattformer som støttar det. Stadfest dette på den installerte utgåva før du planlegg ut frå det. Der det ikkje er støtta, er alternativet å binde den bestemte adressa eller rette returruta, og begge er smalare endringar enn dei ser ut til ved fyrste augekast. Jokerlytting har òg følgjer utover svar: ein tenar på alle adresser er tilgjengeleg frå kvart nettverk verten er knytt til, og det er kanskje ikkje den eksponeringa nokon hadde tenkt seg.

Prov kjelda til svaret utanfrå

Test utanfrå i høve til tenaren, og noter den nøyaktige adressa og transporten klienten brukte før du tar opp noko. Dei tre undersøkingane nedanfor svarar på tre ulike spørsmål, og rekkjefølgja 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 kjeldeadressa på svaret, og det er det faktumet heile artikkelen kviler på. Sokkelista viser kva tenaren faktisk batt, fordi ein jokerlyttar og ein bestemt lyttar ser like ut i ei konfigurasjonsfil og oppfører seg ulikt på nettet. Ruteoppslaget viser kjelda kjernen ville valt for den straumen, og det forklarer opptaket før du endrar noko. Gjenta alle tre for IPv4 og IPv6 kvar for seg, fordi dei er separate lyttarar og separate oppslag, og ein jokerpost for den eine familien seier ingenting om den andre.

Ruting, oppdaging og filtrering blir verande åtskilde

Å ta vare på kjelda til svaret installerer ikkje ei utgåande rute, oppdaterer ikkje dynamisk DNS og får ikkje den eine adressefamilien til å godta den andre. På ein tenar med fleire oppstraumslenkjer må returvegen for kvar kjelde avtalast medvite, elles går svar ut gjennom eit grensesnitt som filteret til klienten aldri tillét. På same måte må ei ny adresse etter eit prefiksskifte nå klientane gjennom oppdaging og den støtta gjenoppkoplingsflyten, ikkje gjennom den gamle posten.

Lat tenaridentitetskontrollane og sertifikatverifiseringa vere nøyaktig som dei er, fordi ei endra adresse ikkje rettferdiggjer å godta ein uverifisert motpart. Om svaret no går ut frå den tiltenkte kjelda og tunnelen framleis feilar, sjå på kjeldefeilen som løyst og gå vidare. Den neste observerte feilen høyrer til ruting, filtrering eller autentisering, og nok ei endring av lyttaren når han ikkje. Skriv kjelda til svaret i saka ved sida av adressa klienten ringde, slik at neste person kan kontrollere same faktum med éin kommando.