Un client WireGuard nu ajunge la un client OpenVPN?

Ambele tuneluri se conectează, fiecare client ajunge la gateway, iar în momentul în care unul încearcă adresa celuilalt pachetele dispar. Nimic nu e greșit în niciuna dintre cele două strângeri de mână, iar reemiterea cheilor nu schimbă asta. Gateway-ul transportă pachete IP obișnuite necifrate între două dintre propriile interfețe, așa că protocoalele nu trebuie niciodată să se înțeleagă între ele; ce le trebuie sunt trei lucruri pe care nicio strângere de mână nu le oferă. Acoperirea destinației pe clientul de origine, proprietatea sursei la gateway și o cale de întoarcere pe partea cealaltă. Simptomul este același pentru toate trei, de aceea sunt diagnosticate împreună.

Simptomului îi lipsește o singură piesă pe rând

Acest design folosește un pool WireGuard 10.71.0.0/24 pe wg1 și un pool OpenVPN 10.72.0.0/24 pe tun1, ambele terminându-se pe un singur gateway. Cererea testată merge de la 10.71.0.5 la HTTPS pe 10.72.0.30. Fiecare pas de mai jos privește acel singur flux. Fiecare verificare are o semnătură de eșec diferită deși utilizatorul le trăiește la fel, și de obicei lipsește doar una din trei pe rând.

Începe prin a confirma că ambele pool-uri sunt într-adevăr pe acest gateway și că forwardingul este activ în spațiul de nume unde trăiesc tunelurile. Un gateway care termină ambele protocoale în spații de nume diferite nu transmite nimic între ele, și merită exclus înainte de a citi orice configurație de peer.

Extinde acoperirea destinației la nodul spiță

Pe clientul WireGuard, intrarea de peer existentă trebuie să selecteze gateway-ul pentru destinația OpenVPN, ceea ce înseamnă că prefixul destinației trebuie să apară în lista permisă a acelui peer. Adăugarea lui nu creează un al doilea tunel; schimbă ce peer alege clientul când caută acea adresă, iar cu wg-quick ruta urmează de obicei lista automat.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Lasă neatinse liniile reale de cheie și punct final și ține minte că un manager care folosește Table = off nu ia nicio rută din această listă. În acest caz același prefix trebuie instalat în tabela de rutare a sistemului de cel care îl deține, iar o rută lipsă acolo arată exact ca un prefix permis lipsă.

Păstrează proprietatea sursei la gateway

Intrarea de peer a acestui client la gateway trebuie să dețină în continuare exact adresa sursă a acelui client. Adresele permise sunt verificate în ambele direcții: aleg un peer pentru traficul de ieșire și validează că sursa unui pachet de intrare aparține peer-ului care l-a trimis. A pune pool-ul OpenVPN în intrarea spiței pentru că spița vrea să ajungă la el este greșeala care trimite traficul către participantul greșit.

AllowedIPs = 10.71.0.5/32

Citește acea intrare ca o declarație de proprietate și nu ca o comoditate de rutare. Orice altceva la ce clientul trebuie să ajungă aparține listei de destinații a clientului, nu ideii gateway-ului despre ce are voie acest peer să trimită.

Dă părții OpenVPN o rută de întoarcere

Destinația are acum nevoie de o rută înapoi la sursa WireGuard, iar pentru clienții dintr-un pool aceasta vine de obicei ca o rută împinsă de la serverul OpenVPN. Împinge-o doar către clienții care ar trebui să o aibă și confirmă pe client că a fost acceptată în loc să presupui că directiva a fost aplicată.

push "route 10.71.0.0 255.255.255.0"

Distribuirea rutelor nu este autorizare. Când destinația stă în spatele altui client OpenVPN în loc să fie în pool, proprietatea LAN-ului propriu al acelui client și cerințele lui de forwarding se alătură designului, iar ruta împinsă este doar prima jumătate. Reformulează cerința ca graf înainte de a adăuga directive: care nod deține care prefix și care nod transmite spre el.

Permite doar serviciul pe care voiai să îl permiți

Cu forwardingul activ și ambele pool-uri rutabile, întrebarea rămasă este de politică. Scrie regula pentru fluxul concret și nu pentru perechea de interfețe în general, previzualizeaz-o înainte de aplicare și păstrează calea de întoarcere cu stare ca răspunsurile să nu fie blocate ca noi conexiuni. O rulare uscată nu costă nimic și arată exact ce s-ar adăuga.

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

Acestea sunt reguli pentru traficul transmis mai departe, distincte de regulile de ascultare ale gateway-ului pentru cele două servicii VPN. Deschiderea porturilor UDP exterioare nu autorizează cererea interioară, iar autorizarea cererii interioare nu cere SSH nerestricționat către gateway sau o permisiune implicită la forwarding. Și firewall-ul destinației și adresa ei de ascultare trebuie să coincidă, fiindcă un serviciu legat de loopback respinge chiar și cel mai bine rutat pachet. O politică ce acoperă doar un sens al conversației eșuează de obicei cu o cerere reușită și un răspuns mut, care este cel mai confuz dintre cele trei rezultate.

Rutele reciproce înseamnă de obicei că nu e nevoie de traducere de sursă, ceea ce păstrează adresa WireGuard la destinație și face jurnalele lizibile. Nu adăuga masquerading general pentru că sunt implicate două protocoale și nu elimina o regulă de traducere existentă fără să știi ce depinde de ea. Apoi verifică singurul flux de la un cap la altul și testează și o sursă sau un port nepermis: o strângere de mână care funcționează pe fiecare parte nu dovedește nici ruta încrucișată, nici izolarea.