Varför ett OpenVPN UDP-svar lämnar fel adress

En OpenVPN-klient ringer en adress, servern svarar från en annan, och tunneln kommer aldrig upp. Serverloggen visar att paketet anländer och en inspelning visar ett svar som lämnar värden, så felet får klienten skulden. På en värd med flera gränssnitt, eller flera adresser på ett gränssnitt, är de två sidorna helt enkelt oense om vilken adress som används. Svaret är giltigt på IP-nivå, men många klienter kastar ett datagram vars källa inte är den adress de kontaktade.

Vad klienten ser när källan ändras

En UDP-uttag som inte är bunden till en viss lokal adress har ingen fast källa, så kärnan väljer en vid sändning. Det valet kommer från en vägsökning mot klientens adress, och källan blir adressen för det gränssnitt som sökningen väljer. På en maskin med ett gränssnitt är valet osynligt; på en värd med en hanteringsadress, en offentlig adress och en sekundär adress på samma nätverkskort beror det på vägmetriker och policy. Policybaserad routning gör avvikelsen mer sannolik snarare än mindre, eftersom en regel kan välja en uppströmslänk som klienten aldrig nådde. En standardväg inlärd från en leverantör plus en källregel som pekar på en annan räcker för att åstadkomma det.

Klienter som filtrerar svar, och anslutningsspårning som förväntar sig den exakta fyrdubbeln och källan, kastar svaret utan ett användbart meddelande. Tunneln löper då ut som om ingenting hade anlänt, och det är därför detta felaktigt tas för ett brandväggsproblem på klientsidan. En inspelning gjord bara på servern bekräftar felet i stället för att förklara det, eftersom svaret verkligen lämnar värden. Jämför svarets källa med den adress klienten ringde innan du ändrar något annat.

Vad alternativet multihome faktiskt gör

Direktivet skrivs som multihome i en konfigurationsfil och som --multihome på kommandoraden, och det får en UDP-server att svara från den adress som klientens paket nådde. Kärnan levererar den ursprungliga destinationsadressen som tilläggsdata vid mottagning, och OpenVPN använder det värdet som källa för svaret. En server som lyssnar på en jokeradress, local 0.0.0.0 för IPv4 eller dess IPv6-motsvarighet, beter sig därmed som om varje klient hade nått en egen lyssnare. Klienter som kom in via den offentliga adressen får svar från den offentliga adressen, och klienter på en intern adress får svar från den. Ingenting annat på paketets väg flyttar sig: vägen, filterreglerna och tunnelkonfigurationen förblir exakt som de var.

Just den sista egenskapen gör alternativet säkert att lägga till på en i övrigt fungerande server, och den är också skälet till att det inte kan reparera ett filter som bara tillåter en adress. Paketet måste fortfarande accepteras på den väg det tar, så källkorrigeringen ändrar svarets ursprung och ingenting mer. Det gäller också bara UDP: en TCP-lyssnare har inte detta problem i samma form, eftersom anslutningen identifieras av fyrdubbeln och inte av svarets källadress.

När en fast lokal adress är fel standard

Innan du griper efter alternativet, kontrollera om servern binder en viss lokal adress, eftersom en bunden lyssnare alltid svarar från den adressen. Det är rätt för en driftsättning med ett gränssnitt och fel så snart klienter lagligt använder mer än en adress. Om bindningen var avsiktlig, avgör om servern alls bör ta emot trafik på ytterligare adresser. Att ta bort bindningen ökar exponeringen, så de tillåtna gränssnitten och källnäten måste upprätthållas av tjänsten och filtret, inte bara av bindningsadressen.

OpenVPN-referensen begränsar alternativet till UDP-servrar, noterar den extra behandlingen på paketets väg och anger vilka plattformar som stöder det. Bekräfta det på den installerade utgåvan innan du planerar utifrån det. Där det inte stöds är alternativet att binda den specifika adressen eller rätta returvägen, och båda är snävare ändringar än de ser ut vid första anblicken. Jokerlyssning har också konsekvenser bortom svar: en server på alla adresser är nåbar från varje nätverk som värden är ansluten till, och det är kanske inte den exponering någon hade tänkt sig.

Bevisa svarets källa utifrån

Testa utifrån i förhållande till servern, och notera den exakta adress och transport som klienten använde innan du fångar något. De tre undersökningarna nedan besvarar tre olika frågor, och ordningen spelar roll.

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

Inspelningen visar källadressen i svaret, och det är det faktum hela artikeln vilar på. Uttagslistan visar vad servern faktiskt band, eftersom en jokerlyssnare och en specifik lyssnare ser identiska ut i en konfigurationsfil och beter sig olika på nätet. Vägsökningen visar den källa som kärnan skulle välja för det flödet, och det förklarar inspelningen innan du ändrar något. Upprepa alla tre för IPv4 och IPv6 var för sig, eftersom de är separata lyssnare och separata sökningar, och en jokerpost för den ena familjen säger ingenting om den andra.

Routning, upptäckt och filtrering förblir åtskilda

Att bevara svarets källa installerar ingen utgående väg, uppdaterar inte dynamisk DNS och får inte den ena adressfamiljen att acceptera den andra. På en server med flera uppströmslänkar måste returvägen för varje källa avtalas medvetet, annars lämnar svar ett gränssnitt som klientens filter aldrig tillät. På samma sätt måste en ny adress efter ett prefixbyte nå klienterna genom upptäckt och det stödda återanslutningsflödet, inte genom den gamla posten.

Låt serveridentitetskontrollerna och certifikatverifieringen vara exakt som de är, eftersom en ändrad adress inte berättigar att acceptera en overifierad motpart. Om svaret nu lämnar den avsedda källan och tunneln fortfarande misslyckas, betrakta källproblemet som löst och gå vidare. Nästa observerade fel hör till routning, filtrering eller autentisering, och ännu en ändring av lyssnaren når det inte. Skriv svarets källa i ärendet bredvid den adress klienten ringde, så att nästa person kan kontrollera samma faktum med ett enda kommando.