Waarom OpenVPN-clients de IPsec-selectors van de gateway missen

Ping vanaf de gateway naar een host achter de externe IPsec-tunnel en hij antwoordt netjes, dus de tunnel lijkt gezond en het ticket gaat verder. Daarna probeert een verbonden client dezelfde host en krijgt niets terug. Die ping was nooit bewijs voor de flow van de client, want hij vertrok met het eigen bronadres van de gateway en kwam overeen met een andere IPsec-selector. Begrijpen waarom de twee gevallen uiteenlopen is het grootste deel van de oplossing.

De ping van de gateway test een flow die je client nooit gebruikt

Het bronadres bepaalt welk beleid geldt. Een pakket dat op de gateway ontstaat, vertrekt met een adres uit zijn lokale LAN of van zijn tunneleindpunt, en het beleid dat daarbij past is precies voor dat geval geschreven. Het pakket van een client komt op de OpenVPN-interface aan met een adres uit de clientpool, wat een heel andere selector is.

Daarom lijkt de storing op een routeringsprobleem terwijl het eigenlijk een probleem van beleidsbereik is. Bereikbaarheid vanaf de gateway bewijst dat de peer draait en dat de voorstellen zijn onderhandeld, en het bewijst niets over de vraag of de pool beschermd is.

Push het externe prefix dat de toepassing echt nodig heeft

Neem het voorbeeldpaar 10.8.0.0/24 voor verbonden clients en 172.30.239.0/25 voor het beschermde externe netwerk. Wat een client nodig heeft is een route naar dat tweede prefix, niet naar de LAN van de gateway en niet naar een ander tunneladres. Een route die naar de pool wordt gepusht is wat de client dat verkeer überhaupt aan de gateway laat geven. Zonder die route bereikt het pakket nooit de beleidsbeslissing die je debugt.

Op een Community-server die gepushte routes accepteert, neemt de richtlijn het echte masker: push "route 172.30.239.0 255.255.255.128". Access Server configureert dezelfde bestemming via de privénetwerk- of toegangsregelinstellingen van de geïnstalleerde versie, waarbij gerouteerde of vertaalde modus bewust wordt gekozen. Gegenereerde firewallketens aanpassen in plaats van de eigen configuratie is de manier waarop een werkende opstelling onmogelijk te reproduceren wordt.

Lees na het verbinden de routeringstabel van de client in plaats van de bedoeling van de server. Een route die alleen de pool dekt betekent dat de push nooit aankwam, en een standaardroute door de tunnel is breder dan deze eis en zal je later verrassen. Controleer het masker en ook het prefix, want een /25 die als /24 wordt gepusht stuurt verkeer voor naburige adressen een pad in dat het niet kan dragen. Bevestig daarna dat de client de tunnelinterface voor die bestemming heeft gekozen.

Zorg dat de selectors de clientpool omvatten

Voor gerouteerde toegang die clientadressen behoudt, moet het IPsec-beleid verkeer tussen de pool en het externe prefix beschermen. Selectors die voor het eigen LAN van de gateway zijn geschreven, laten de ping door en laten het verzoek van de client vallen, en dat is precies de asymmetrie die dit onderzoek begon.

Onderzoek het onderhandelde beleid en ook de geconfigureerde voorstellen, bijvoorbeeld met ipsec statusall op strongSwan of het equivalente statuscommando voor jouw implementatie. Bij beleidsgebaseerde IPsec kan de gewone route naar een fysieke interface wijzen terwijl passend verkeer nog steeds versleuteld wordt, dus een ontbrekend tunnelapparaat bewijst niets. Vergelijk de selectorparen met de pool en het prefix die je hebt opgeschreven.

Generieke bron-NAT op de gateway kan de overeenkomst ook breken. Als een masquerade-regel de bron van de client herschrijft voordat de beleidscontrole plaatsvindt, ziet het pakket er niet meer uit als de selector die je hebt geschreven. Dat is een reden waarom een brede masquerade-regel een slechte oplossing is voor een tweede VPN: hij verandert welk beleid geldt en welk adres de externe kant logt. Ontsla het verkeer dat je wilt routeren, of vertaal het bewust en werk de selectors bij.

Kies bewust voor routeren of vertalen

Routeren houdt het clientadres zichtbaar voor de externe kant, zodat externe logs en regels per bron betekenisvol blijven, en het vereist dat de externe gateway het terugpad naar de pool kent. Vertalen verbergt de pool achter één adres, wat het terugrouteprobleem wegneemt en de identiteit per client vernietigt.

Kies één ontwerp en schrijf het op, want de twee hebben verschillende selectors en een andere firewallvolgorde nodig. Een half toegepaste masquerade landt ertussenin en voldoet aan geen van beide. De opgeschreven keuze is ook wat de volgende engineer een bug van een bewuste beslissing laat onderscheiden.

Sluit de lus op doorgifte en het antwoord

De gateway moet het protocol en de bestemming doorgeven die je bedoelt, wat betekent dat IP-doorgifte aan staat en dat een doorgifteketen het paar toestaat. Daarna moet de externe kant antwoorden via het IPsec-pad terugsturen, en dat is een routeringsbeslissing op hun gateway en niet op die van jou. Beide helften zijn gewone configuratie, en beide blijven gemakkelijk half af. Test ze apart, zodat een ontbrekende doorgifteregel niet voor een kapotte tunnel wordt aangezien.

Verifieer met één echt verzoek van client naar toepassing, en kijk hoe het de OpenVPN-interface, de IPsec-beslissing en de externe host passeert. Bekijk het antwoord als een aparte observatie, want een verzoek dat aankomt en een antwoord dat nooit terugkomt zien er vanaf de plek van de client hetzelfde uit. Eén getraceerd verzoek is meer waard dan welk aantal pings vanaf de gateway dan ook.

Houd de autorisatie van de bestemming smal terwijl je test, en bevestig dat een client zonder de regel de dienst niet kan bereiken. Een geïnstalleerde route plus een opgebouwde associatie is niet hetzelfde als verleende toegang.