Hvorfor et OpenVPN-UDP-svar forlader den forkerte adresse

En OpenVPN-klient ringer til én adresse, serveren svarer fra en anden, og tunnelen kommer aldrig op. Serverloggen viser, at pakken ankommer, og en optagelse viser et svar, der forlader værten, så fejlen får klienten skylden. På en vært med flere netværksgrænseflader, eller flere adresser på én grænseflade, er de to parter simpelthen uenige om, hvilken adresse der er i brug. Svaret er gyldigt på IP-laget, men mange klienter kasserer et datagram, hvis kilde ikke er den adresse, de kontaktede.

Hvad klienten ser, når kilden skifter

En UDP-socket, der ikke er bundet til en bestemt lokal adresse, har ingen fast kilde, så kernen vælger en ved afsendelse. Det valg kommer fra et ruteopslag mod klientens adresse, og kilden bliver adressen på den grænseflade, opslaget vælger. På en maskine med én grænseflade er valget usynligt; på en vært med en administrationsadresse, en offentlig adresse og en sekundær adresse på samme netværkskort afhænger det af rutevalgsmetrikker og politik. Politikbaseret routing gør uoverensstemmelsen mere sandsynlig snarere end mindre, fordi en regel kan vælge et uplink, som klienten aldrig nåede. En standardrute lært fra én udbyder plus en kilderegel, der peger på en anden, er nok til at frembringe det.

Klienter, der filtrerer svar, og forbindelsessporing, der forventer den præcise firdublet og kilden, vil kassere svaret uden en brugbar meddelelse. Derefter udløber tunnelen, som om intet var ankommet, og det er derfor, dette fejlagtigt opfattes som et firewallproblem på klientsiden. En optagelse taget kun på serveren bekræfter fejlen i stedet for at forklare den, fordi svaret virkelig forlader værten. Sammenlign svarets kilde med den adresse, klienten ringede til, før du ændrer noget andet.

Hvad multihome-indstillingen egentlig gør

Direktivet skrives som multihome i en konfigurationsfil og som --multihome på kommandolinjen, og det får en UDP-server til at svare fra den adresse, som klientens pakke nåede frem til. Kernen leverer den oprindelige destinationsadresse som supplerende data ved modtagelse, og OpenVPN bruger den værdi som kilde for svaret. En server, der lytter på en jokeradresse, local 0.0.0.0 for IPv4 eller dens IPv6-modstykke, opfører sig derfor, som om hver klient havde nået en dedikeret lytter. Klienter, der kom ind via den offentlige adresse, får svar fra den offentlige adresse, og klienter på en intern adresse får svar fra den. Intet andet på pakkens vej flytter sig: ruten, filterreglerne og tunnelkonfigurationen forbliver præcis, som de var.

Netop denne sidste egenskab er grunden til, at indstillingen er sikker at tilføje til en ellers fungerende server, og også grunden til, at den ikke kan reparere et filter, der kun tillader én adresse. Pakken skal stadig accepteres på den vej, den tager, så kildekorrektionen ændrer svarets oprindelse og intet mere. Den er også kun til UDP: en TCP-lytter har ikke dette problem i samme form, fordi forbindelsen identificeres ved firdubletten og ikke ved svarets kildeadresse.

Hvornår en fast lokal adresse er den forkerte standard

Før du griber efter indstillingen, skal du kontrollere, om serveren binder én bestemt lokal adresse, fordi en bundet lytter altid svarer fra den adresse. Det er korrekt for en udrulning med én grænseflade og forkert, så snart klienter legitimt bruger mere end én adresse. Hvis bindingen var bevidst, skal du beslutte, om serveren overhovedet bør acceptere trafik på yderligere adresser. At fjerne bindingen øger eksponeringen, så de tilladte grænseflader og kildenettværk skal håndhæves af tjenesten og filteret, ikke kun af bindingsadressen.

OpenVPN-referenceen begrænser indstillingen til UDP-servere, noterer den ekstra behandling på pakkens vej og angiver, hvilke platforme der understøtter den. Bekræft det på den installerede udgivelse, før du planlægger ud fra det. Hvor den ikke understøttes, er alternativet at binde den specifikke adresse eller rette returruten, og begge er snævrere ændringer, end de ser ud til ved første øjekast. Jokerlytning har også konsekvenser ud over svar: en server på alle adresser kan nås fra alle netværk, som værten er tilsluttet, og det er måske ikke den eksponering, nogen havde tænkt sig.

Bevis svarets kilde udefra

Test udefra i forhold til serveren, og notér den præcise adresse og transport, som klienten brugte, før du optager noget. De tre undersøgelser nedenfor besvarer tre forskellige spørgsmål, og rækkefølgen er vigtig.

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

Optagelsen viser kildeadressen på svaret, og det er den kendsgerning, hele artiklen drejer sig om. Socketlisten viser, hvad serveren faktisk bandt, fordi en jokerlytter og en specifik lytter ser identiske ud i en konfigurationsfil og opfører sig forskelligt på nettet. Ruteopslaget viser den kilde, kernen ville vælge for den strøm, hvilket forklarer optagelsen, før du ændrer noget. Gentag alle tre for IPv4 og IPv6 hver for sig, fordi de er separate lyttere og separate opslag, og en jokerpost for den ene familie siger intet om den anden.

Routing, opdagelse og filtrering forbliver adskilt

At bevare svarets kilde installerer ikke en udgående rute, opdaterer ikke dynamisk DNS og får ikke den ene adressefamilie til at acceptere den anden. På en server med flere uplinks skal returvejen for hver kilde aftales bevidst, ellers forlader svar en grænseflade, som klientens filter aldrig tillod. Ligeledes skal en ny adresse efter et præfiksskift nå klienterne gennem opdagelse og det understøttede genopkoblingsflow, ikke gennem den gamle post.

Lad serveridentitetskontroller og certifikatverifikation være præcis, som de er, fordi en ændret adresse ikke retfærdiggør accept af en uverificeret modpart. Hvis svaret nu forlader den tilsigtede kilde, og tunnelen stadig fejler, så betragt kildefejlen som løst og gå videre. Den næste observerede fejl hører til routing, filtrering eller godkendelse, og endnu en ændring af lytteren når den ikke. Skriv svarets kilde i sagen ved siden af den adresse, klienten ringede til, så den næste person kan kontrollere samme kendsgerning med én kommando.