Kvifor OpenVPN-klientar ikkje treff IPsec-veljarane til gatewayen

Ping ein vert bak den eksterne IPsec-tunnelen frå gatewayen, og han svarar reint, så tunnelen ser sunn ut og saka går vidare. Deretter prøver ein tilkopla klient same verten og får ingenting attende. Den ping-en var aldri prov for flyten til klienten, fordi han gjekk ut med gatewayen si eiga kjeldeadresse og matcha ein annan IPsec-veljar. Å forstå kvifor dei to tilfella sprikjer er det meste av rettinga.

Pingen frå gatewayen testar ein flyt klienten din aldri brukar

Kjeldeadressa avgjer kva policy som gjeld. Ein pakke som blir generert på gatewayen, går ut med ei adresse frå det lokale LANet eller frå tunnelendepunktet, og policyen som matchar han, vart skriven nettopp for det tilfellet. Pakken til ein klient kjem inn på OpenVPN-grensesnittet med ei adresse frå klientpoolen, som er ein heilt annan veljar.

Difor ser feilen ut som eit ruteproblem når han eigentleg er eit policyomfang-problem. Rekkevidd frå gatewayen provar at peeren er oppe og at framlegga vart forhandla, og det provar ingenting om poolen er verna.

Push det eksterne prefikset applikasjonen faktisk treng

Ta det illustrerande paret 10.8.0.0/24 for tilkopla klientar og 172.30.239.0/25 for det verna eksterne nettet. Det ein klient treng, er ei rute til det andre prefikset, ikkje til LANet til gatewayen og ikkje til ei anna tunneladresse. Ei rute som blir pusha til poolen, er det som får klienten til å overlevere trafikken til gatewayen i det heile. Utan henne når pakken aldri den policyavgjerda du feilsøkjer.

På ein Community-server som godtek pusha ruter, tek direktivet den verkelege maska: push "route 172.30.239.0 255.255.255.128". Access Server konfigurerer same mål gjennom innstillingane for privat nett eller tilgangsreglar i den installerte versjonen, med ruta eller omsett modus vald med vilje. Å redigere genererte brannmur-kjeder i staden for eigarkonfigurasjonen er korleis ein fungerande installasjon blir umogleg å gjenskape.

Etter tilkopling, les rutetabellen til klienten framfor intensjonen til serveren. Ei rute som berre dekkjer poolen betyr at pushen aldri kom fram, og ei standardrute gjennom tunnelen er breiare enn dette kravet og vil overraske deg seinare. Kontroller maska så vel som prefikset, fordi ein /25 som blir pusha som /24 sender trafikk for naboadresser inn i ein veg som ikkje kan bera han. Stadfest deretter at klienten valde tunnelgrensesnittet for det målet.

La veljarane omfatte klientpoolen

For ruta tilgang som bevarer klientadresser, må IPsec-policyen verne trafikk mellom poolen og det eksterne prefikset. Veljarar skrivne for det eigne LANet til gatewayen slepp pingen gjennom og slepp førespurnaden til klienten, og det er nøyaktig den asymmetrien som starta denne undersøkinga.

Undersøk den forhandla policyen så vel som dei konfigurerte framlegga, til dømes med ipsec statusall på strongSwan eller den tilsvarande statuskommandoen for implementasjonen din. Med policybasert IPsec kan den vanlege ruta peike på eit fysisk grensesnitt medan matchande trafikk framleis blir kryptert, så ein manglande tunneleining provar ingenting. Samanlikn veljarpara med poolen og prefikset du skreiv ned.

Generisk kjelde-NAT på gatewayen kan også bryte matchinga. Viss ein masquerade-regel skriv om kjelda til klienten før policykontrollen, ser pakken ikkje lenger ut som veljaren du skreiv. Det er éin grunn til at ein brei masquerade-regel er ei dårleg andre-VPN-løysing: han endrar kva policy som gjeld og kva adresse den eksterne sida loggar. Unnta trafikken du vil rute, eller set han om med vilje og oppdater veljarane.

Vel ruting eller omsetjing med vilje

Ruting held klientadressa synleg for den eksterne sida, slik at eksterne loggar og reglar per kjelde blir meiningsfulle, og det krev at den eksterne gatewayen kjenner returvegen til poolen. Omsetjing gøymer poolen bak éi adresse, noko som fjernar returruteproblemet og øydelegg identiteten per klient.

Vel eitt design og skriv det ned, fordi dei to treng ulike veljarar og ulik rekkjefølgje i brannmuren. Ein halvt brukt masquerade landar mellom dei og tilfredsstiller ingen av dei. Det nedskrivne valet er også det som lèt den neste ingeniøren skilje ein feil frå ei medviten avgjerd.

Lukk sløyfa på videresending og svar

Gatewayen må videresende protokollen og målet du meiner, noko som betyr at IP-videresending er slått på og ei videresendingskjede som tillèt paret. Den eksterne sida må deretter sende svar attende via IPsec-vegen, og det er ei ruteavgjerd på gatewayen deira og ikkje din. Begge halvdelane er vanleg konfigurasjon, og begge er lette å la stå halvferdige. Test dei kvar for seg, slik at ein manglande videresendingsregel ikkje blir forveksla med ein øydelagd tunnel.

Stadfest med éin ekte førespurnad frå klient til applikasjon, og sjå han krysse OpenVPN-grensesnittet, IPsec-avgjerda og den eksterne verten. Undersøk svaret som ein separat observasjon, fordi ein førespurnad som kjem inn og eit svar som aldri kjem attende ser like ut frå plassen til klienten. Éin spora førespurnad er meir verdt enn noka mengd ping frå gatewayen.

Hald målautorisasjonen smal medan du testar, og stadfest at ein klient utan regelen ikkje når tenesta. Ei installert rute pluss ein etablert assosiasjon er ikkje det same som gjeven tilgang.