Hvorfor OpenVPN-klienter ikke rammer gatewayens IPsec-selektorer

Ping en vært bag den fjerne IPsec-tunnel fra gatewayen, og den svarer rent, så tunnelen ser sund ud, og sagen går videre. Derefter prøver en tilsluttet klient den samme vært og får intet igen. Det ping var aldrig bevis for klientens flow, fordi det forlod med gatewayens egen kildeadresse og matchede en anden IPsec-selektor. At forstå, hvorfor de to tilfælde divergerer, er det meste af rettelsen.

Gatewayens ping tester et flow, din klient aldrig bruger

Kildeadressen bestemmer, hvilken politik der gælder. En pakke, der genereres på gatewayen, forlader med en adresse fra dens lokale LAN eller dens tunnelendepunkt, og den politik, der matcher den, blev skrevet netop til det tilfælde. En klients pakke ankommer på OpenVPN-interfacet med en adresse fra klientpuljen, hvilket er en helt anden selektor.

Derfor ligner fejlen et routingproblem, når den i virkeligheden er et politikomfang-problem. Rækkevidde fra gatewayen beviser, at peer’en er oppe, og at forslagene blev forhandlet, og det beviser intet om, hvorvidt puljen er beskyttet.

Push det fjernpræfiks, applikationen faktisk har brug for

Tag det illustrative par 10.8.0.0/24 til tilsluttede klienter og 172.30.239.0/25 til det beskyttede fjernnetværk. Det, en klient har brug for, er en rute til det andet præfiks, ikke til gatewayens LAN og ikke til en eller anden anden tunneladresse. En rute, der pushes til puljen, er det, der får klienten til at aflevere den trafik til gatewayen. Uden den når pakken aldrig den politikbeslutning, du fejlfinder.

På en Community-server, der accepterer pushyede ruter, tager direktivet den rigtige maske: push "route 172.30.239.0 255.255.255.128". Access Server konfigurerer samme destination gennem den installerede versions private-netværk- eller adgangsregelindstillinger, med routed eller translated tilstand valgt bevidst. At redigere genererede firewallkæder i stedet for den ejende konfiguration er, hvordan en fungerende opsætning bliver umulig at genskabe.

Efter forbindelsen skal du læse klientens routingtabel frem for serverens hensigt. En rute, der kun dækker puljen, betyder, at pushet aldrig nåede frem, og en standardrute gennem tunnelen er bredere end dette krav og vil overraske dig senere. Kontrollér masken såvel som præfikset, fordi en /25 pushet som en /24 sender trafik for naboadresser ind i en vej, der ikke kan bære den. Bekræft derefter, at klienten valgte tunnelinterfacet til den destination.

Få selektorerne til at omfatte klientpuljen

Til routed adgang, der bevarer klientadresser, skal IPsec-politikken beskytte trafik mellem puljen og fjernpræfikset. Selektorer skrevet til gatewayens eget LAN tillader pinget og dropper klientens anmodning, og det er præcis den asymmetri, der startede denne undersøgelse.

Undersøg den forhandlede politik såvel som de konfigurerede forslag, for eksempel med ipsec statusall på strongSwan eller den tilsvarende statuskommando til din implementering. Med politikbaseret IPsec kan den almindelige rute pege på et fysisk interface, mens matchende trafik stadig krypteres, så en manglende tunneleenhed beviser intet. Sammenlign selektorparrene med den pulje og det præfiks, du skrev ned.

Generisk kilde-NAT på gatewayen kan også bryde matchningen. Hvis en masquerade-regel omskriver klientens kilde før politikontrollen, ligner pakken ikke længere den selektor, du skrev. Det er en grund til, at en bred masquerade-regel er en dårlig anden-VPN-løsning: den ændrer, hvilken politik der gælder, og hvilken adresse den fjerne side logger. Undtag den trafik, du vil route, eller oversæt den bevidst og opdater selektorerne.

Vælg routing eller oversættelse med vilje

Routing holder klientadressen synlig for den fjerne side, så fjernlogfiler og regler per kilde forbliver meningsfulde, og det kræver, at den fjerne gateway kender returvejen til puljen. Oversættelse skjuler puljen bag én adresse, hvilket fjerner returrute-problemet og ødelægger identiteten per klient.

Vælg ét design og skriv det ned, fordi de to har brug for forskellige selektorer og forskellig firewallrækkefølge. En halvt anvendt masquerade lander mellem dem og tilfredsstiller ingen af dem. Det nedskrevne valg er også det, der lader den næste ingeniør skelne en fejl fra en bevidst beslutning.

Luk kredsløbet på forwarding og svaret

Gatewayen skal forwarde den protokol og destination, du har til hensigt, hvilket betyder IP-forwarding aktiveret og en forward-kæde, der tillader parret. Den fjerne side skal derefter sende svar tilbage ad IPsec-vejen, og det er en routingbeslutning på deres gateway snarere end på din. Begge halvdele er almindelig konfiguration, og begge er nemme at efterlade halvfærdige. Test dem hver for sig, så en manglende forward-regel ikke forveksles med en brudt tunnel.

Verificér med én rigtig klient-til-applikation-anmodning og se den krydse OpenVPN-interfacet, IPsec-beslutningen og den fjerne vært. Undersøg svaret som en separat observation, fordi en anmodning, der ankommer, og et svar, der aldrig vender tilbage, ser identiske ud fra klientens plads. Én sporet anmodning er mere værd end nogen mængde gateway-pings.

Hold destinationens autorisation snæver, mens du tester, og bekræft, at en klient uden reglen ikke kan nå tjenesten. En installeret rute plus en etableret association er ikke det samme som tildelt adgang.