WireGuard klijent ne može dosegnuti OpenVPN klijent?

Oba tunela se povezuju, svaki klijent može dosegnuti gateway, i u trenutku kada jedan pokuša adresu drugoga, paketi nestaju. Ništa na nijednom rukovanju nije pogrešno, i nikakvo ponovno izdavanje ključeva to ne mijenja. Gateway prenosi obične nešifrovane IP pakete između dva svoja interfejsa, pa protokoli nikada ne moraju razumjeti jedan drugoga; potrebne su im tri stvari koje nijedno rukovanje ne pruža. Pokrivenost odredišta na izvornom klijentu, vlasništvo izvora na gatewayu i povratna putanja na suprotnoj strani. Simptom je isti za sve tri, zato se i dijagnostikuju zajedno.

Simptomu nedostaje jedan dio po jedan

Ovaj dizajn koristi WireGuard pool 10.71.0.0/24 na wg1 i OpenVPN pool 10.72.0.0/24 na tun1, a oba završavaju na jednom gatewayu. Zahtjev u testu ide od 10.71.0.5 do HTTPS na 10.72.0.30. Svaki korak ispod tiče se tog jednog toka. Svaka provjera ima drugačiji potpis kvara iako ih korisnik doživljava jednako, a obično nedostaje samo jedna od tri stvari istovremeno.

Počnite potvrdom da su oba poola zaista na ovom gatewayu i da je prosljeđivanje omogućeno u namespaceu u kojem žive tuneli. Gateway koji završava oba protokola u različitim namespaceovima ne prosljeđuje ništa između njih, i to vrijedi isključiti prije čitanja bilo koje peer konfiguracije.

Proširite pokrivenost odredišta na kraku

Na WireGuard klijentu postojeći peer unos mora odabrati gateway za OpenVPN odredište, što znači da prefiks odredišta mora stajati na listi dozvoljenih tog peera. Njegovo dodavanje ne stvara drugi tunel; mijenja to koji peer klijent bira kada traži tu adresu, a uz wg-quick ruta obično automatski slijedi listu.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Ostavite stvarne linije ključa i endpointa netaknutima i zapamtite da menadžer koji koristi Table = off ne uzima nikakvu rutu s ove liste. U tom slučaju isti prefiks mora biti instaliran u sistemsku tablicu ruta od strane onoga koji ga posjeduje, a ruta koja tamo nedostaje izgleda točno kao dozvoljeni prefiks koji nedostaje.

Zadržite vlasništvo izvora na gatewayu

Peer unos ovog klijenta na gatewayu treba i dalje posjedovati točno izvornu adresu tog klijenta. Dozvoljene adrese provjeravaju se u oba smjera: biraju peer za odlazni promet i provjeravaju da izvor dolaznog paketa pripada peeru koji ga je poslao. Stavljanje OpenVPN poola u unos kraka zato što krak želi do njega doći jest greška koja promet usmjerava prema pogrešnom sudioniku.

AllowedIPs = 10.71.0.5/32

Čitajte taj unos kao izjavu o vlasništvu, a ne kao rutnu pogodnost. Sve ostalo do čega klijent treba doći pripada na listu odredišta klijenta, a ne u gatewayovu predodžbu o tome što ovaj peer smije slati.

Dajte OpenVPN strani povratnu rutu

Odredište sada treba rutu natrag prema WireGuard izvoru, a za klijente iz poola to obično stiže kao gurnuta ruta s OpenVPN servera. Gurnite je samo klijentima koji je trebaju imati i potvrdite na klijentu da je prihvaćena, umjesto da pretpostavite da je direktiva primijenjena.

push "route 10.71.0.0 255.255.255.0"

Distribucija ruta nije autorizacija. Kada odredište stoji iza drugog OpenVPN klijenta umjesto u poolu, vlasništvo tog klijenta nad vlastitim LAN-om i zahtjevi za prosljeđivanje pridružuju se dizajnu, a gurnuta ruta je samo prva polovica. Preformulirajte zahtjev kao graf prije dodavanja direktiva: koji čvor posjeduje koji prefiks i koji čvor prosljeđuje prema njemu.

Dozvolite samo onu uslugu koju ste namjeravali dozvoliti

Uz omogućeno prosljeđivanje i oba poola rutabilna, ostaje pitanje politike. Napišite pravilo za konkretni tok, a ne za par interfejsa općenito, pregledajte ga prije primjene i zadržite stateful povratni put da se odgovori ne blokiraju kao nove veze. Probno pokretanje ne košta ništa i pokazuje točno što bi bilo dodano.

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

Ovo su pravila za proslijeđeni promet, različita od gatewayovih pravila za slušanje dviju VPN usluga. Otvaranje vanjskih UDP portova ne autorizira unutrašnji zahtjev, a autorizacija unutrašnjeg zahtjeva ne traži neograničen SSH prema gatewayu ni zadano dopuštenje na prosljeđivanju. Ciljni firewall i adresa slušanja također se moraju slagati, jer usluga vezana na loopback odbija i najpažljivije rutiran paket. Politika koja pokriva samo jedan smjer razgovora obično propada sa uspješnim zahtjevom i tihim odgovorom, što je najzbunjujući od tri ishoda.

Uzajamne rute obično znače da izvorno prevođenje nije potrebno, što čuva WireGuard adresu na odredištu i čini logove čitljivima. Ne dodajte sveobuhvatni masquerading zato što su uključena dva protokola i ne uklanjajte postojeće pravilo prevođenja bez znanja što o njemu ovisi. Zatim provjerite jedini tok od početka do kraja i testirajte i jedan zabranjeni izvor ili port: rukovanje koje radi na svakoj strani ne dokazuje ni ukrštenu rutu ni izolaciju.