Kan en WireGuard-klient ikke nå en OpenVPN-klient?

Begge tunneler forbinder, hver klient kan nå gatewayen, og i det øjeblik den ene prøver den andens adresse, forsvinder pakkerne. Intet er galt med nogen af håndtrykkene, og ingen mængde genudstedte nøgler ændrer det. Gatewayen bærer almindelige ukrypterede IP-pakker mellem to af sine egne interfaces, så protokollerne behøver aldrig at forstå hinanden; det, de behøver, er tre ting, som intet håndtryk giver. Destinationsdækning på den oprindelige klient, kildemæssigt ejerskab ved gatewayen og en returvej på den fjerne side. Symptomet er det samme for alle tre, og derfor diagnosticeres de sammen.

Symptomet mangler én brik ad gangen

Dette design bruger en WireGuard-pulje 10.71.0.0/24 på wg1 og en OpenVPN-pulje 10.72.0.0/24 på tun1, som begge terminerer på én gateway. Forespørgslen under test går fra 10.71.0.5 til HTTPS på 10.72.0.30. Hvert trin nedenfor handler om netop den ene strøm. Hver kontrol har en anden fejlsignatur, selv om brugeren oplever dem ens, og normalt mangler kun én af de tre ad gangen.

Begynd med at bekræfte, at begge puljer virkelig er på denne gateway, og at videresendelse er slået til i det namespace, hvor tunnelerne bor. En gateway, der terminerer begge protokoller i forskellige namespaces, videresender intet mellem dem, og det er værd at udelukke, før man læser nogen peer-konfiguration.

Udvid egerens destinationsdækning

På WireGuard-klienten skal den eksisterende peer-post vælge gatewayen for OpenVPN-destinationen, hvilket betyder, at destinationspræfikset skal stå på peerens liste over tilladte adresser. At tilføje det opretter ikke en anden tunnel; det ændrer, hvilken peer klienten vælger, når den slår den adresse op, og med wg-quick følger ruten normalt listen automatisk.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Lad de rigtige nøgle- og endpoint-linjer være urørte, og husk at en manager, der bruger Table = off, slet ikke tager nogen rute fra denne liste. I så fald skal det samme præfiks installeres i systemets rutetabel af den, der ejer det, og en manglende rute der ligner præcis et manglende tilladt præfiks.

Behold kildemæssigt ejerskab ved gatewayen

Gatewayens peer-post for denne klient skal fortsat eje præcis den klients kildeadresse. Tilladte adresser kontrolleres i begge retninger: de vælger en peer for udgående trafik, og de validerer, at en indgående pakkes kilde tilhører den peer, der sendte den. At sætte OpenVPN-puljen i egerens post, fordi egeren vil nå den, er den fejl, der sender trafik mod den forkerte deltager.

AllowedIPs = 10.71.0.5/32

Læs den post som en ejerskabserklæring frem for en rutemæssig bekvemmelighed. Alt andet, klienten skal nå, hører til klientens destinationsliste, ikke til gatewayens forestilling om, hvad denne peer må sende.

Giv OpenVPN-siden en returrute

Målet har nu brug for en rute tilbage til WireGuard-kilden, og for klienter i en pulje kommer den normalt som en skubbet rute fra OpenVPN-serveren. Skub den kun til klienter, der bør have den, og bekræft på klienten, at den blev accepteret, i stedet for at antage, at direktivet blev anvendt.

push "route 10.71.0.0 255.255.255.0"

Rutedistribution er ikke autorisation. Når destinationen ligger bag en anden OpenVPN-klient i stedet for i puljen, kommer den klients eget LAN-ejerskab og videresendelseskrav med i designet, og den skubbede rute er kun den første halvdel. Omformuler kravet som en graf, før du tilføjer direktiver: hvilken knude ejer hvilket præfiks, og hvilken knude videresender mod det.

Tillad netop den ene tjeneste, du mente at tillade

Med videresendelse slået til og begge puljer rutbare er det resterende spørgsmål politik. Skriv reglen for den konkrete strøm og ikke for interfaceparret generelt, se den efter før anvendelse, og behold den tilstandsfulde returvej, så svar ikke blokeres som nye forbindelser. En tør kørsel koster intet og viser præcis, hvad der ville blive tilføjet.

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 er videresendte regler, adskilt fra gatewayens lytteregler for de to VPN-tjenester. At åbne de ydre UDP-porte autoriserer ikke den indre forespørgsel, og at autorisere den indre forespørgsel kræver hverken ubegrænset SSH til gatewayen eller en standardtilladelse på videresendelse. Målets egen firewall og lytteadresse skal også passe sammen, da en tjeneste bundet til loopback afviser den mest omhyggeligt rutede pakke. Politik, der kun dækker én retning af samtalen, fejler typisk med en vellykket forespørgsel og et tavst svar, hvilket er det mest forvirrende af de tre udfald.

Gensidige ruter betyder normalt, at der ikke er brug for kildeoversættelse, hvilket bevarer WireGuard-adressen på målet og gør logfiler læsbare. Tilføj ikke blanket masquerading, fordi to protokoller er involveret, og fjern ikke en eksisterende oversættelsesregel uden at vide, hvad der afhænger af den. Verificér derefter den enkelte strøm ende til ende, og test også én forbudt kilde eller port: et fungerende håndtryk på hver side beviser hverken krydsruten eller isoleringen.