Når en WireGuard-klient ikke frem til en OpenVPN-klient?

Begge tunnelene kobler til, hver klient når gatewayen, og i det øyeblikket den ene prøver adressen til den andre, forsvinner pakkene. Ingenting er galt med noen av håndtrykkene, og ingen mengde nye nøkler endrer det. Gatewayen bærer vanlige ukrypterte IP-pakker mellom to av sine egne grensesnitt, så protokollene trenger aldri å forstå hverandre; det de trenger, er tre ting som ingen håndtrykk gir. Destinasjonsdekning på opprinnelsesklienten, kildeeierskap ved gatewayen og en returvei på den andre siden. Symptomet er det samme for alle tre, og derfor diagnostiseres de sammen.

Symptomet mangler én brikke om gangen

Denne konstruksjonen bruker et WireGuard-pool 10.71.0.0/24 på wg1 og et OpenVPN-pool 10.72.0.0/24 på tun1, og begge terminerer på én gateway. Forespørselen som testes går fra 10.71.0.5 til HTTPS på 10.72.0.30. Hvert trinn nedenfor handler om nettopp denne ene strømmen. Hver kontroll har en annen feilsignatur selv om brukeren opplever dem likt, og vanligvis mangler bare én av de tre om gangen.

Begynn med å bekrefte at begge poolene virkelig er på denne gatewayen, og at videresending er slått på i navnerommet der tunnelene bor. En gateway som terminerer begge protokollene i ulike navnerom, videresender ingenting mellom dem, og det er verdt å utelukke før du leser noen peer-konfigurasjon.

Utvid eikens destinasjonsdekning

På WireGuard-klienten må den eksisterende peer-oppføringen velge gatewayen for OpenVPN-destinasjonen, noe som betyr at destinasjonsprefikset må stå i den peerens tillatte liste. Å legge det til lager ikke en andre tunnel; det endrer hvilken peer klienten velger når den slår opp adressen, og med wg-quick følger ruten normalt listen automatisk.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

La de ekte nøkkel- og endepunktlinjene være urørt, og husk at en behandler som bruker Table = off ikke tar noen rute fra denne listen i det hele tatt. I så fall må det samme prefikset installeres i systemets rutetabell av den som eier det, og en manglende rute der ser nøyaktig ut som et manglende tillatt prefiks.

Behold kildeeierskapet ved gatewayen

Gatewayens peer-oppføring for denne klienten skal fortsatt eie nøyaktig kildeadressen til den klienten. Tillatte adresser kontrolleres i begge retninger: de velger en peer for utgående trafikk, og de bekrefter at kilden til en innkommende pakke tilhører peer-en som sendte den. Å sette OpenVPN-poolen i eikens oppføring fordi eiken vil nå den, er feilen som sender trafikk mot feil deltaker.

AllowedIPs = 10.71.0.5/32

Les den oppføringen som en eierskapserklæring og ikke som en rutemessig bekvemmelighet. Alt annet klienten må nå, hører til klientens destinasjonsliste, ikke til gatewayens forestilling om hva denne peeren får sende.

Gi OpenVPN-siden en returrute

Destinasjonen trenger nå en rute tilbake til WireGuard-kilden, og for klienter fra et pool kommer den vanligvis som en dyttet rute fra OpenVPN-serveren. Dytt den bare til klienter som skal ha den, og bekreft på klienten at den ble godtatt i stedet for å anta at direktivet ble brukt.

push "route 10.71.0.0 255.255.255.0"

Rutedistribusjon er ikke autorisasjon. Når destinasjonen ligger bak en annen OpenVPN-klient i stedet for i poolen, kommer den klientens eget LAN-eierskap og videresendingskrav med i konstruksjonen, og den dyttede ruten er bare første halvdel. Omformuler kravet som en graf før du legger til direktiver: hvilken node eier hvilket prefiks, og hvilken node videresender mot det.

Tillat bare den ene tjenesten du mente å tillate

Med videresending slått på og begge poolene rutbare, er spørsmålet som gjenstår policy. Skriv regelen for den konkrete strømmen og ikke for grensesnittparet generelt, forhåndsvis den før du bruker den, og behold den tilstandsfulle returveien slik at svar ikke blokkeres som nye tilkoblinger. En tørrkjøring koster ingenting og viser nøyaktig hva som ville blitt lagt til.

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

Dette er regler for videresendt trafikk, atskilt fra gatewayens lyttregler for de to VPN-tjenestene. Å åpne de ytre UDP-portene autoriserer ikke den indre forespørselen, og å autorisere den indre forespørselen krever verken ubegrenset SSH til gatewayen eller standard tillatelse på videresending. Målets egen brannmur og lyttadresse må også stemme, siden en tjeneste bundet til loopback avviser selv den mest omhyggelig rutede pakken. Policy som bare dekker én retning av samtalen, feiler vanligvis med en vellykket forespørsel og et stille svar, som er det mest forvirrende av de tre utfallene.

Gjensidige ruter betyr vanligvis at det ikke trengs kildeoversettelse, noe som bevarer WireGuard-adressen på målet og gjør logger lesbare. Ikke legg til blanket masquerading fordi to protokoller er involvert, og ikke fjern en eksisterende oversettelsesregel uten å vite hva som avhenger av den. Verifiser deretter den ene strømmen ende til ende, og test også én forbudt kilde eller port: et fungerende håndtrykk på hver side beviser verken kryssruten eller isolasjonen.