Waarom OpenVPN-kliënte die gateway se IPsec-selektors misloop

Ping ’n gasheer agter die afgeleë IPsec-tonnel vanaf die gateway, en dit antwoord skoon, so die tonnel lyk gesond en die kaartjie beweeg aan. ’n Gekoppelde kliënt probeer dan dieselfde gasheer en kry niks terug nie. Daardie ping was nooit bewyse vir die kliënt se vloei nie, want dit het met die gateway se eie bronadres vertrek en ’n ander IPsec-selektor gepas. Om te verstaan waarom die twee gevalle verskil, is die grootste deel van die oplossing.

Die gateway-ping toets ’n vloei wat jou kliënt nooit gebruik nie

Die bronadres bepaal watter beleid van toepassing is. ’n Pakket wat op die gateway gegenereer word, vertrek met ’n adres van sy plaaslike LAN of sy tonnel-eindpunt, en die beleid wat daarby pas, is presies vir daardie geval geskryf. ’n Kliënt se pakket kom op die OpenVPN-koppelvlak aan met ’n adres uit die kliëntpoel, wat heeltemal ’n ander selektor is.

Daarom lyk die mislukking soos ’n roeteprobleem terwyl dit eintlik ’n beleidsomvang-probleem is. Bereikbaarheid vanaf die gateway bewys dat die eweknie lewendig is en die voorstelle onderhandel is, en dit bewys niks oor of die poel beskerm word nie.

Stuur die afgeleë voorvoegsel wat die toepassing werklik nodig het

Neem die illustratiewe paar van 10.8.0.0/24 vir gekoppelde kliënte en 172.30.239.0/25 vir die beskermde afgeleë netwerk. Wat ’n kliënt nodig het, is ’n roete na daardie tweede voorvoegsel, nie na die gateway se LAN nie en nie na een of ander ander tonneladres nie. ’n Roete wat na die poel gestuur word, is wat die kliënt daardie verkeer hoegenaamd na die gateway laat oorhandig. Sonder dit bereik die pakket nooit die beleidsbeslissing wat jy ontfout nie.

In ’n Community-bediener wat gestuurde roetes aanvaar, neem die richtlijn die werklike masker: push "route 172.30.239.0 255.255.255.128". Access Server konfigureer dieselfde bestemming deur die geïnstalleerde weergawe se private-netwerk- of toegangsreël-instellings, met routeer- of vertaalmode doelbewus gekies. Om gegenereerde firewall-kettings te wysig in plaas van die eienaarskonfigurasie is hoe ’n werkende opstelling onmoontlik word om te reproduseer.

Lees ná die koppeling die kliënt se roetetabel eerder as die bediener se bedoeling. ’n Roete wat net die poel dek, beteken die stuur het nooit aangekom nie, en ’n verstekroete deur die tonnel is wyer as hierdie vereiste en sal jou later verras. Kontroleer die masker sowel as die voorvoegsel, want ’n /25 wat as ’n /24 gestuur word, stuur verkeer vir naburige adresse in ’n pad in wat dit nie kan dra nie. Bevestig dan dat die kliënt die tonnel-koppelvlak vir daardie bestemming gekies het.

Maak dat die selektors die kliëntpoel insluit

Vir gerouteerde toegang wat kliëntadresse bewaar, moet die IPsec-beleid verkeer tussen die poel en die afgeleë voorvoegsel beskerm. Selektors wat vir die gateway se eie LAN geskryf is, laat die ping deur en laat die kliënt se versoek val, en dit is presies die asimmetrie wat hierdie ondersoek begin het.

Ondersoek die onderhandelde beleid sowel as die gekonfigureerde voorstelle, byvoorbeeld met ipsec statusall op strongSwan of die ekwivalente statusopdrag vir jou implementering. Met beleidsgebaseerde IPsec kan die gewone roete na ’n fisiese koppelvlak wys terwyl bypassende verkeer steeds geënkripteer word, so ’n ontbrekende tonneltoestel bewys niks. Vergelyk die selektorpare met die poel en voorvoegsel wat jy neergeskryf het.

Generiese bron-NAT op die gateway kan ook die passing breek. As ’n masquerade-reël die kliënt se bron herskryf voordat die beleidskontrole plaasvind, lyk die pakket nie meer soos die selektor wat jy geskryf het nie. Dit is een rede waarom ’n breë masquerade-reël ’n swak tweede-VPN-oplossing is: dit verander watter beleid van toepassing is en watter adres die ander kant log. Stel die verkeer wat jy van plan is om te routeer vry, of vertaal dit doelbewus en werk die selektors by om te pas.

Kies doelbewus tussen routering of vertaling

Routering hou die kliëntadres sigbaar vir die ander kant, so afgeleë logs en reëls per bron bly betekenisvol, en dit vereis dat die afgeleë gateway die terugpad na die poel ken. Vertaling verberg die poel agter een adres, wat die terugroeteprobleem verwyder en die identiteit per kliënt vernietig.

Kies een ontwerp en skryf dit neer, want die twee het verskillende selektors en verskillende firewall-ordering nodig. ’n Half-toegepaste masquerade beland tussen hulle en bevredig nie een nie. Die neergeskrewe keuse is ook wat die volgende ingenieur laat onderskei tussen ’n fout en ’n doelbewuste besluit.

Sluit die lus op aansturing en die antwoord

Die gateway moet die protokol en bestemming aanstuur wat jy beoog, wat beteken IP-aansturing moet geaktiveer wees en ’n aanstuur-ketting moet die paar toelaat. Die ander kant moet dan antwoorde deur die IPsec-pad terugstuur, en dit is ’n roetebesluit op hulle gateway eerder as op joune. Beide helftes is gewone konfigurasie, en beide is maklik om half klaar te laat. Toets hulle afsonderlik sodat ’n ontbrekende aanstuur-reël nie met ’n stukkende tonnel verwar word nie.

Verifieer met een werklike versoek van kliënt na toepassing en kyk hoe dit die OpenVPN-koppelvlak, die IPsec-besluit en die afgeleë gasheer kruis. Ondersoek die antwoord as ’n aparte waarneming, want ’n versoek wat aankom en ’n antwoord wat nooit terugkeer nie, lyk dieselfde vanaf die kliënt se stoel. Een nagespeurde versoek is meer werd as enige aantal gateway-pings.

Hou die bestemmingsmagtiging smal terwyl jy toets, en bevestig dat ’n kliënt sonder die reël nie die diens kan bereik nie. ’n Geïnstalleerde roete plus ’n gevestigde assosiasie is nie dieselfde ding as toegang wat verleen is nie.