Når en WireGuard-klient inte fram till en OpenVPN-klient?

Båda tunnlarna ansluter, varje klient når gatewayen, och i samma ögonblick som den ena prövar den andras adress försvinner paketen. Ingenting är fel på någon av handskakningarna, och inget antal nya nycklar ändrar det. Gatewayen bär vanliga okrypterade IP-paket mellan två av sina egna gränssnitt, så protokollen behöver aldrig förstå varandra; det de behöver är tre saker som ingen handskakning ger. Målräckvidd på ursprungsklienten, källägarskap vid gatewayen och en returväg på andra sidan. Symtomet är detsamma för alla tre, och därför diagnostiseras de tillsammans.

Symtomet saknar en bit i taget

Den här konstruktionen använder en WireGuard-pool 10.71.0.0/24 på wg1 och en OpenVPN-pool 10.72.0.0/24 på tun1, båda slutar på en enda gateway. Förfrågan som testas går från 10.71.0.5 till HTTPS på 10.72.0.30. Varje steg nedan handlar om just den enda strömmen. Varje kontroll har en annan felsignatur även om användaren upplever dem likadant, och oftast saknas bara en av de tre åt gången.

Börja med att bekräfta att båda poolerna verkligen ligger på den här gatewayen och att vidarebefordran är påslagen i det namnutrymme där tunnlarna lever. En gateway som avslutar båda protokollen i olika namnutrymmen vidarebefordrar ingenting mellan dem, och det är värt att utesluta innan du läser någon peer-konfiguration.

Utöka ekerns målräckvidd

På WireGuard-klienten måste den befintliga peer-posten välja gatewayen för OpenVPN-målet, vilket betyder att målprefixet måste stå i den peerns tillåtna lista. Att lägga till det skapar inte en andra tunnel; det ändrar vilken peer klienten väljer när den slår upp adressen, och med wg-quick följer rutten normalt listan automatiskt.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Låt de riktiga nyckel- och slutpunktsraderna vara orörda och kom ihåg att en hanterare som använder Table = off inte tar någon rutt från listan alls. I så fall måste samma prefix installeras i systemets rutttabell av den som äger det, och en saknad rutt där ser exakt ut som ett saknat tillåtet prefix.

Behåll källägarskapet vid gatewayen

Gatewayens peer-post för den här klienten ska fortsätta att äga exakt den klientens källadress. Tillåtna adresser kontrolleras i båda riktningarna: de väljer en peer för utgående trafik och de bekräftar att källan i ett inkommande paket tillhör den peer som skickade det. Att sätta OpenVPN-poolen i ekerns post eftersom eken vill nå den är felet som skickar trafiken mot fel deltagare.

AllowedIPs = 10.71.0.5/32

Läs den posten som en äganderättsförklaring och inte som en ruttbekvämlighet. Allt annat klienten måste nå hör till klientens mållista, inte till gatewayens föreställning om vad den här peern får skicka.

Ge OpenVPN-sidan en returrutt

Målet behöver nu en rutt tillbaka till WireGuard-källan, och för klienter från en pool kommer den vanligtvis som en påskjuten rutt från OpenVPN-servern. Skjut den bara till klienter som ska ha den, och bekräfta på klienten att den togs emot i stället för att anta att direktivet tillämpades.

push "route 10.71.0.0 255.255.255.0"

Ruttdistribution är inte auktorisation. När målet ligger bakom en annan OpenVPN-klient i stället för i poolen, kommer den klientens eget LAN-ägarskap och dess vidarebefordringskrav med i konstruktionen, och den påskjutna rutten är bara första halvan. Formulera om kravet som en graf innan du lägger till direktiv: vilken nod äger vilket prefix, och vilken nod vidarebefordrar mot det.

Tillåt bara den enda tjänst du menade att tillåta

Med vidarebefordran påslagen och båda poolerna rutbara återstår frågan om policy. Skriv regeln för den konkreta strömmen och inte för gränssnittsparet i allmänhet, förhandsgranska den innan du använder den, och behåll den tillståndskänsliga returvägen så att svar inte blockeras som nya anslutningar. En torrkörning kostar ingenting och visar exakt vad som skulle läggas till.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Det här är regler för vidarebefordrad trafik, åtskilda från gatewayens lyssnarregler för de två VPN-tjänsterna. Att öppna de yttre UDP-portarna auktoriserar inte den inre förfrågan, och att auktorisera den inre förfrågan kräver varken obegränsad SSH till gatewayen eller ett standardtillstånd på vidarebefordran. Även målets egen brandvägg och lyssnaradress måste stämma, eftersom en tjänst bunden till loopback avvisar även det mest omsorgsfullt routade paketet. Policy som bara täcker en riktning av samtalet misslyckas oftast med en lyckad förfrågan och ett tyst svar, vilket är det mest förvirrande av de tre utfallen.

Ömsesidiga rutter innebär oftast att ingen källöversättning behövs, vilket bevarar WireGuard-adressen på målet och gör loggar läsbara. Lägg inte till blanket masquerading för att två protokoll är inblandade, och ta inte bort en befintlig översättningsregel utan att veta vad som hänger på den. Verifiera sedan den enda strömmen från början till slut, och testa också en förbjuden källa eller port: en fungerande handskakning på varje sida bevisar varken korsrutten eller isoleringen.