Waarom een OpenVPN UDP-antwoord van het verkeerde adres komt

Een OpenVPN-client kiest één adres, de server antwoordt vanaf een ander, en de tunnel komt nooit op. Het serverlog laat het pakket aankomen zien en een opname laat een antwoord weggaan, dus de fout wordt bij de client gelegd. Op een host met meerdere interfaces, of meerdere adressen op één interface, zijn beide kanten het simpelweg oneens over welk adres in gebruik is. Het antwoord is geldig op IP-niveau, toch gooien veel clients een datagram weg waarvan de bron niet het adres is dat ze hebben benaderd.

Wat de client ziet als de bron verandert

Een UDP-socket die niet aan een bepaald lokaal adres is gebonden, heeft geen vaste bron, dus de kernel kiest er een bij het verzenden. Die keuze komt uit een routezoekopdracht naar het adres van de client, en de bron wordt het adres van de interface die de zoekopdracht selecteert. Op een machine met één interface is de keuze onzichtbaar; op een host met een beheeradres, een openbaar adres en een secundair adres op dezelfde netwerkkaart hangt het af van routemetrieken en -beleid. Beleidsgebaseerd routeren maakt de mismatch waarschijnlijker in plaats van minder, omdat een regel een uplink kan kiezen die de client nooit heeft bereikt. Een standaardroute die van de ene provider is geleerd plus een bronregel die naar een andere wijst, is genoeg om het te veroorzaken.

Clients die antwoorden filteren, en verbindingsregistratie die het exacte viertal en de bron verwacht, gooien het antwoord weg zonder bruikbare melding. Dan verloopt de tunnel alsof er niets is aangekomen, en daarom wordt dit ten onrechte voor een firewallprobleem aan de clientkant aangezien. Een opname die alleen op de server is gemaakt, bevestigt de fout in plaats van hem te verklaren, omdat het antwoord echt weggaat. Vergelijk de bron van het antwoord met het adres dat de client koos voordat u iets anders wijzigt.

Wat de optie multihome feitelijk doet

De richtlijn wordt als multihome in een configuratiebestand geschreven en als --multihome op de opdrachtregel, en ze zorgt dat een UDP-server antwoordt vanaf het adres dat het pakket van de client heeft bereikt. De kernel levert het oorspronkelijke bestemmingsadres als aanvullende gegevens bij ontvangst, en OpenVPN gebruikt die waarde als bron van het antwoord. Zo gedraagt een server die op een jokeradres luistert, local 0.0.0.0 voor IPv4 of het IPv6-equivalent, zich alsof elke client een eigen luisteraar heeft bereikt. Clients die via het openbare adres binnenkwamen, krijgen antwoorden van het openbare adres, en clients op een intern adres krijgen ze van dat adres. Niets anders op het pakketpad beweegt: de route, de filterregels en de tunnelconfiguratie blijven precies zoals ze waren.

Juist die laatste eigenschap maakt de optie veilig om aan een verder werkende server toe te voegen, en ze is ook de reden waarom ze een filter dat maar één adres toestaat niet kan repareren. Het pakket moet nog steeds worden aanvaard op het pad dat het neemt, dus de broncorrectie verandert de oorsprong van het antwoord en niets meer. Ze geldt ook alleen voor UDP: een TCP-luisteraar heeft dit probleem niet in dezelfde vorm, omdat de verbinding door het viertal wordt geïdentificeerd en niet door het bronadres van het antwoord.

Wanneer een vast lokaal adres de verkeerde standaard is

Controleer, voordat u naar de optie grijpt, of de server één specifiek lokaal adres bindt, want een gebonden luisteraar antwoordt altijd vanaf dat adres. Dat is juist voor een implementatie met één interface en onjuist zodra clients wettelijk meer dan één adres gebruiken. Als de binding bewust was, beslis dan of de server überhaupt verkeer op extra adressen moet aanvaarden. Het verwijderen van de binding vergroot de blootstelling, dus de toegestane interfaces en bronnetwerken moeten door de dienst en het filter worden afgedwongen, niet alleen door het bindingsadres.

De OpenVPN-referentie beperkt de optie tot UDP-servers, vermeldt de extra verwerking op het pakketpad en legt vast welke platforms haar ondersteunen. Bevestig dat op de geïnstalleerde versie voordat u erop plant. Waar ze niet wordt ondersteund, is het binden van het specifieke adres of het corrigeren van de retourroute het alternatief, en beide zijn smallere wijzigingen dan ze op het eerste gezicht lijken. Luisteren op een jokeradres heeft ook gevolgen buiten antwoorden: een server op alle adressen is bereikbaar vanaf elk netwerk waaraan de host is gekoppeld, en dat is misschien niet de blootstelling die iemand bedoelde.

Bewijs de bron van het antwoord van buitenaf

Test van buiten de server, en noteer het exacte adres en transport dat de client gebruikte voordat u iets vastlegt. De drie controles hieronder beantwoorden drie verschillende vragen, en de volgorde is belangrijk.

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

De opname toont het bronadres in het antwoord, en dat is het feit waarop het hele artikel berust. De socketlijst toont waaraan de server werkelijk gebonden is, omdat een joker- en een specifieke luisteraar er in een configuratiebestand identiek uitzien en zich op het netwerk anders gedragen. De routezoekopdracht toont de bron die de kernel voor die stroom zou kiezen, en dat verklaart de opname voordat u iets wijzigt. Herhaal alle drie apart voor IPv4 en IPv6, want het zijn afzonderlijke luisteraars en afzonderlijke zoekopdrachten, en een jokervermelding voor de ene familie zegt niets over de andere.

Routeren, ontdekking en filteren blijven gescheiden

Het behouden van de bron van het antwoord installeert geen uitgaande route, werkt dynamische DNS niet bij en zorgt er niet voor dat de ene adresfamilie de andere accepteert. Op een server met meerdere uplinks moet de retourroute voor elke bron bewust worden afgesproken, anders verlaten antwoorden een interface die het filter van de client nooit heeft toegestaan. Evenzo moet een nieuw adres na een prefixwijziging de clients bereiken via ontdekking en de ondersteunde herverbindingsstroom, niet via het oude record.

Laat de identiteitscontroles van de server en de certificaatverificatie precies zoals ze zijn, want een gewijzigd adres rechtvaardigt niet dat een niet-geverifieerde tegenpartij wordt geaccepteerd. Als het antwoord nu van de bedoelde bron weggaat en de tunnel nog steeds faalt, beschouw het bronprobleem dan als opgelost en ga verder. De volgende waargenomen fout hoort bij routeren, filteren of authenticatie, en opnieuw de luisteraar wijzigen bereikt die niet. Schrijf de bron van het antwoord in het ticket naast het adres dat de client koos, zodat de volgende persoon hetzelfde feit met één opdracht kan controleren.