Hvorfor OpenVPN-klienter ikke treffer gatewayens IPsec-velgere

Ping en vert bak den eksterne IPsec-tunnelen fra gatewayen, og den svarer rent, så tunnelen ser sunn ut og saken går videre. Deretter prøver en tilkoblet klient samme vert og får ingenting tilbake. Den ping-en var aldri bevis for klientens flyt, fordi den gikk ut med gatewayens egen kildeadresse og matchet en annen IPsec-velger. Å forstå hvorfor de to tilfellene spriker er det meste av rettelsen.

Ping fra gatewayen tester en flyt klienten din aldri bruker

Kildeadressen avgjør hvilken policy som gjelder. En pakke som genereres på gatewayen, går ut med en adresse fra dens lokale LAN eller fra tunnelendepunktet, og policyen som matcher den, ble skrevet nettopp for det tilfellet. En klients pakke ankommer på OpenVPN-grensesnittet med en adresse fra klientpoolen, som er en helt annen velger.

Derfor ser feilen ut som et ruteproblem når den egentlig er et policyomfang-problem. Rekkevidde fra gatewayen beviser at peeren er oppe og at forslagene ble forhandlet, og det beviser ingenting om hvorvidt poolen er beskyttet.

Push det eksterne prefikset applikasjonen faktisk trenger

Ta det illustrerende paret 10.8.0.0/24 for tilkoblede klienter og 172.30.239.0/25 for det beskyttede eksterne nettet. Det en klient trenger, er en rute til det andre prefikset, ikke til gatewayens LAN og ikke til en annen tunneladresse. En rute som pushes til poolen, er det som får klienten til å overlevere trafikken til gatewayen i det hele tatt. Uten den når pakken aldri den policybeslutningen du feilsøker.

På en Community-server som godtar pusha ruter, tar direktivet den virkelige masken: push "route 172.30.239.0 255.255.255.128". Access Server konfigurerer samme mål gjennom den installerte versjonens private nettverk- eller tilgangsregelinnstillinger, med rutet eller oversatt modus valgt bevisst. Å redigere genererte brannmur-kjeder i stedet for eierkonfigurasjonen er hvordan en fungerende installasjon blir umulig å gjenskape.

Etter tilkobling, les klientens rutetabell framfor serverens intensjon. En rute som bare dekker poolen betyr at pushen aldri kom fram, og en standardrute gjennom tunnelen er bredere enn dette kravet og vil overraske deg senere. Kontroller masken såvel som prefikset, fordi en /25 som pushes som /24 sender trafikk for naboadresser inn i en vei som ikke kan bære den. Deretter bekreft at klienten valgte tunnelgrensesnittet for det målet.

La velgerne omfatte klientpoolen

For rutet tilgang som bevarer klientadresser, må IPsec-policyen beskytte trafikk mellom poolen og det eksterne prefikset. Velgere skrevet for gatewayens eget LAN slipper pinget gjennom og slipper klientens forespørsel, og det er nøyaktig den asymmetrien som startet denne undersøkelsen.

Undersøk den forhandlede policyen såvel som de konfigurerte forslagene, for eksempel med ipsec statusall på strongSwan eller den tilsvarende statuskommandoen for din implementasjon. Med policybasert IPsec kan den vanlige ruten peke på et fysisk grensesnitt mens matchende trafikk fortsatt krypteres, så en manglende tunnelenhet beviser ingenting. Sammenlign velgerparene med poolen og prefikset du skrev ned.

Generisk kilde-NAT på gatewayen kan også bryte matchingen. Hvis en masquerade-regel skriver om klientens kilde før policykontrollen, ser pakken ikke lenger ut som velgeren du skrev. Det er én grunn til at en bred masquerade-regel er en dårlig andrevpn-løsning: den endrer hvilken policy som gjelder og hvilken adresse den eksterne siden logger. Unnta trafikken du vil rute, eller oversett den bevisst og oppdater velgerne.

Velg ruting eller oversettelse med vilje

Ruting holder klientadressen synlig for den eksterne siden, slik at eksterne logger og regler per kilde forblir meningsfulle, og det krever at den eksterne gatewayen kjenner returveien til poolen. Oversettelse skjuler poolen bak én adresse, noe som fjerner returruteproblemet og ødelegger identiteten per klient.

Velg ett design og skriv det ned, fordi de to trenger ulike velgere og ulik rekkefølge i brannmuren. En halvt anvendt masquerade lander mellom dem og tilfredsstiller ingen av dem. Det nedskrevne valget er også det som lar den neste ingeniøren skille en feil fra en bevisst beslutning.

Lukk sløyfen på videresending og svar

Gatewayen må videresende protokollen og målet du har til hensikt, noe som betyr at IP-videresending er slått på og en videresendingskjede som tillater paret. Den eksterne siden må deretter sende svar tilbake via IPsec-veien, og det er en rutebeslutning på deres gateway og ikke din. Begge halvdeler er vanlig konfigurasjon, og begge er lette å la stå halvferdige. Test dem hver for seg, slik at en manglende videresendingsregel ikke forveksles med en ødelagt tunnel.

Verifiser med én ekte forespørsel fra klient til applikasjon, og se den krysse OpenVPN-grensesnittet, IPsec-beslutningen og den eksterne verten. Undersøk svaret som en separat observasjon, fordi en forespørsel som ankommer og et svar som aldri kommer tilbake ser like ut fra klientens plass. Én sporet forespørsel er mer verdt enn noen mengde ping fra gatewayen.

Hold målautorisasjonen smal mens du tester, og bekreft at en klient uten regelen ikke når tjenesten. En installert rute pluss en etablert assosiasjon er ikke det samme som gitt tilgang.