Kan een WireGuard-client geen OpenVPN-client bereiken?

Beide tunnels verbinden, elke client bereikt de gateway, en op het moment dat de een het adres van de ander probeert, verdwijnen de pakketten. Aan geen van beide handshakes is iets mis, en het opnieuw uitgeven van sleutels verandert daar niets aan. De gateway draagt gewone onversleutelde IP-pakketten tussen twee van zijn eigen interfaces, dus de protocollen hoeven elkaar nooit te begrijpen; wat ze nodig hebben zijn drie dingen die geen handshake levert. Doeldekkking op de oorspronkelijke client, broneigendom op de gateway en een terugweg aan de andere kant. Het symptoom is voor alle drie hetzelfde, daarom worden ze samen gediagnosticeerd.

Het symptoom mist telkens één stuk

Dit ontwerp gebruikt een WireGuard-pool van 10.71.0.0/24 op wg1 en een OpenVPN-pool van 10.72.0.0/24 op tun1, beide eindigen op één gateway. Het geteste verzoek loopt van 10.71.0.5 naar HTTPS op 10.72.0.30. Elke stap hieronder gaat over precies die ene stroom. Elke controle heeft een andere faalhandtekening ook al ervaart de gebruiker ze hetzelfde, en meestal ontbreekt er telkens maar één van de drie.

Begin met te bevestigen dat beide pools echt op deze gateway staan en dat doorsturen aan staat in de namespace waar de tunnels leven. Een gateway die beide protocollen in verschillende namespaces beëindigt, stuurt niets tussen hen door, en dat is het waard uit te sluiten voordat je enige peer-configuratie leest.

Breid de doeldekkking van de spaak uit

Op de WireGuard-client moet de bestaande peer-regel de gateway kiezen voor de OpenVPN-bestemming, wat betekent dat het doelhoofdnet in de toegestane lijst van die peer moet staan. Het toevoegen ervan maakt geen tweede tunnel; het verandert welke peer de client kiest wanneer hij dat adres opzoekt, en met wg-quick volgt de route normaal automatisch de lijst.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Laat de echte sleutel- en eindpuntregels ongemoeid, en onthoud dat een beheerder die Table = off gebruikt helemaal geen route uit deze lijst neemt. In dat geval moet hetzelfde voorvoegsel door wie het bezit in de routetabel van het systeem worden gezet, en een ontbrekende route daar ziet er precies zo uit als een ontbrekend toegestaan voorvoegsel.

Houd broneigendom op de gateway

De peer-regel van deze client op de gateway moet precies het bronadres van die client blijven bezitten. Toegestane adressen worden in beide richtingen gecontroleerd: ze kiezen een peer voor uitgaand verkeer en ze valideren dat de bron van een inkomend pakket bij de peer hoort die het stuurde. De OpenVPN-pool in de regel van de spaak zetten omdat de spaak hem wil bereiken, is de fout die verkeer naar de verkeerde deelnemer stuurt.

AllowedIPs = 10.71.0.5/32

Lees die regel als een eigendomsverklaring en niet als een routinggemak. Al het andere dat de client moet bereiken hoort in de doellijst van de client, niet in het beeld dat de gateway heeft van wat deze peer mag versturen.

Geef de OpenVPN-kant een terugroute

Het doel heeft nu een route terug naar de WireGuard-bron nodig, en voor clients uit een pool komt die meestal als een doorgeduwde route van de OpenVPN-server. Duw hem alleen naar clients die hem horen te hebben, en bevestig op de client dat hij is geaccepteerd in plaats van aan te nemen dat de richtlijn is toegepast.

push "route 10.71.0.0 255.255.255.0"

Routedistributie is geen autorisatie. Wanneer het doel achter een andere OpenVPN-client zit in plaats van in de pool, komen het eigen LAN-eigendom van die client en zijn doorstuurvereisten bij het ontwerp, en de doorgeduwde route is slechts de eerste helft. Herformuleer de eis als een graaf voordat je richtlijnen toevoegt: welk knooppunt bezit welk voorvoegsel, en welk knooppunt stuurt ernaartoe door.

Sta alleen de ene dienst toe die je wilde toestaan

Met doorsturen aan en beide pools routeerbaar is de resterende vraag beleid. Schrijf de regel voor de concrete stroom en niet voor het interfacepaar in het algemeen, bekijk hem vooraf voordat je hem toepast, en houd de stateful terugweg zodat antwoorden niet als nieuwe verbindingen worden geblokkeerd. Een droge run kost niets en laat precies zien wat er zou worden toegevoegd.

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

Dit zijn regels voor doorgestuurd verkeer, los van de luisterregels van de gateway voor de twee VPN-diensten. De buitenste UDP-poorten openen autoriseert het binnenste verzoek niet, en het binnenste verzoek autoriseren vereist geen onbeperkte SSH naar de gateway of een standaardtoestemming op doorsturen. Ook de eigen firewall van het doel en het luisteradres moeten overeenkomen, want een dienst die aan loopback is gebonden weigert zelfs het zorgvuldigst gerouteerde pakket. Beleid dat maar één richting van het gesprek dekt, faalt meestal met een geslaagd verzoek en een stil antwoord, wat de meest verwarrende van de drie uitkomsten is.

Wederzijdse routes betekenen meestal dat er geen bronvertaling nodig is, wat het WireGuard-adres bij het doel bewaart en logs leesbaar maakt. Voeg geen algemene masquerading toe omdat er twee protocollen bij betrokken zijn, en verwijder geen bestaande vertaalregel zonder te weten wat ervan afhangt. Verifieer daarna de enkele stroom van begin tot eind, en test ook één niet-toegestane bron of poort: een werkende handshake aan elke kant bewijst noch de kruisroute noch de isolatie.