Når ein WireGuard-klient ikkje fram til ein OpenVPN-klient?

Begge tunnelane koplar til, kvar klient når gatewayen, og i det augneblinken den eine prøver adressa til den andre, forsvinn pakkane. Ingenting er gale med nokon av handtrykka, og ingen mengd nye nøklar endrar det. Gatewayen ber vanlege ukrypterte IP-pakkar mellom to av sine eigne grensesnitt, så protokollane treng aldri å forstå kvarandre; det dei treng, er tre ting som ingen handtrykk gjev. Måldekning på opphavsklienten, kjeldeeigarskap ved gatewayen og ein returveg på den andre sida. Symptomet er det same for alle tre, og difor vert dei diagnostiserte saman.

Symptomet manglar éin bit om gongen

Denne konstruksjonen brukar ein WireGuard-pool 10.71.0.0/24 på wg1 og ein OpenVPN-pool 10.72.0.0/24 på tun1, og begge terminerer på éin gateway. Førespurnaden som vert testa går frå 10.71.0.5 til HTTPS på 10.72.0.30. Kvart steg nedanfor handlar om nettopp denne eine straumen. Kvar kontroll har ein annan feilsignatur sjølv om brukaren opplever dei likt, og vanlegvis manglar berre éin av dei tre om gongen.

Byrja med å stadfeste at begge poolane verkeleg er på denne gatewayen, og at vidaresending er slått på i namnerommet der tunnelane bur. Ein gateway som terminerer begge protokollane i ulike namnerom, vidaresender ingenting mellom dei, og det er verd å utelukke før du les nokon peer-konfigurasjon.

Utvid måldekninga til eika

På WireGuard-klienten må den eksisterande peer-oppføringa velje gatewayen for OpenVPN-målet, noko som tyder på at målprefikset må stå i den tillatne lista til den peeren. Å leggje det til lagar ikkje ein andre tunnel; det endrar kva peer klienten vel når han slår opp adressa, og med wg-quick følgjer ruta normalt lista automatisk.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Lat dei ekte nøkkel- og endepunktlinjene vere urørte, og hugs at ein behandlar som brukar Table = off ikkje tek noka rute frå denne lista i det heile. I så fall må det same prefikset installerast i rutetabellen til systemet av den som eig det, og ei manglande rute der ser nøyaktig ut som eit manglande tillate prefiks.

Hald kjeldeeigarskapet ved gatewayen

Peer-oppføringa til denne klienten på gatewayen skal framleis eige nøyaktig kjeldeadressa til den klienten. Tillatne adresser vert kontrollerte i båe retningar: dei vel ein peer for utgåande trafikk, og dei stadfester at kjelda til ein innkommande pakke høyrer til peeren som sende han. Å setje OpenVPN-poolen i oppføringa til eika fordi eika vil nå han, er feilen som sender trafikk mot feil deltakar.

AllowedIPs = 10.71.0.5/32

Les den oppføringa som ei eigarskapserklæring og ikkje som ei rutemessig lettvintheit. Alt anna klienten må nå, høyrer til mållista til klienten, ikkje til førestillinga til gatewayen om kva denne peeren får sende.

Gje OpenVPN-sida ein returveg

Målet treng no ei rute tilbake til WireGuard-kjelda, og for klientar frå ein pool kjem ho vanlegvis som ei dytta rute frå OpenVPN-serveren. Dytt henne berre til klientar som skal ha henne, og stadfest på klienten at ho vart godteken i staden for å gå ut frå at direktivet vart brukt.

push "route 10.71.0.0 255.255.255.0"

Rutedistribusjon er ikkje autorisasjon. Når målet ligg bak ein annan OpenVPN-klient i staden for i poolen, kjem LAN-eigarskapet til den klienten og krava hans til vidaresending med i konstruksjonen, og den dytta ruta er berre fyrste halvdel. Omformuler kravet som ein graf før du legg til direktiv: kva knutepunkt eig kva prefiks, og kva knutepunkt sender vidaresending mot det.

Tillat berre den eine tenesta du meinte å tillate

Med vidaresending slått på og begge poolane rutbare, er spørsmålet som står att policy. Skriv regelen for den konkrete straumen og ikkje for grensesnittparet generelt, førehandsvis han før du brukar han, og hald den tilstandsfulle returvegen slik at svar ikkje vert blokkerte som nye tilkoplingar. Ein tørrkøyring kostar ingenting og viser nøyaktig kva som ville vorte 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 reglar for vidaresend trafikk, åtskilde frå lyttarreglane til gatewayen for dei to VPN-tenestene. Å opne dei ytre UDP-portane autoriserer ikkje den indre førespurnaden, og å autorisere den indre førespurnaden krev korkje ubegrensa SSH til gatewayen eller standard løyve på vidaresending. Også eigen brannmur og lyttaradresse til målet må stemme, sidan ei teneste bunden til loopback avviser sjølv den mest omhyggeleg ruta pakken. Policy som berre dekkjer éi retning av samtalen, feilar vanlegvis med ein vellukka førespurnad og eit stille svar, som er det mest forvirrande av dei tre utfalla.

Gjensidige ruter tyder vanlegvis at det ikkje trengst kjeldeomsetjing, noko som bevarer WireGuard-adressa på målet og gjer loggar lesbare. Ikkje legg til blanket masquerading fordi to protokollar er involverte, og ikkje fjern ein eksisterande omsetjingsregel utan å vite kva som heng på han. Stadfest deretter den eine straumen ende til ende, og test også éi forbode kjelde eller port: eit fungerande handtrykk på kvar side beviser korkje krossruta eller isolasjonen.