Pse klientët e OpenVPN nuk i kapin selektorët IPsec të portës

Bëni ping nga porta drejt një hosti pas tunelit IPsec të largët dhe ai përgjigjet pastër, kështu që tuneli duket i shëndoshë dhe tiketa vazhdon. Më pas një klient i lidhur provon të njëjtin host dhe nuk merr asgjë mbrapsht. Ai ping nuk ishte kurrë provë për rrjedhën e klientit, sepse doli me adresën e vetë burimit të portës dhe përputhej me një selektor tjetër IPsec. Kuptimi i arsyes pse dy rastet ndryshojnë është pjesa më e madhe e rregullimit.

Ping-u i portës provon një rrjedhë që klienti juaj nuk e përdor kurrë

Adresa e burimit vendos se cila politikë zbatohet. Një paketë e krijuar në portë del me një adresë nga LAN-i vendas ose nga pika fundore e tunelit, dhe politika që përputhet me të është shkruar pikërisht për atë rast. Paketa e klientit arrin në ndërfaqen OpenVPN me një adresë nga grupi i klientëve, që është një selektor krejt tjetër.

Prandaj dështimi duket si problem rrugëtimi ndërsa në të vërtetë është problem i shtrirjes së politikës. Arritshmëria nga porta provon që pala është aktive dhe propozimet u negociuan, dhe nuk provon asgjë nëse grupi është i mbrojtur.

Shtyni parashtesën e largët që aplikacioni ka vërtet nevojë

Merrni çiftin ilustrues 10.8.0.0/24 për klientët e lidhur dhe 172.30.239.0/25 për rrjetin e largët të mbrojtur. Ajo që i duhet klientit është një rrugë drejt parashtesës së dytë, jo drejt LAN-it të portës dhe jo drejt ndonjë adrese tjetër tuneli. Rruga e shtyrë në grup është ajo që e bën klientin ta dorëzojë fare atë trafik te porta. Pa të, paketa nuk arrin kurrë te vendimi i politikës që po korrigjoni.

Në një server Community që pranon rrugë të shtyra, direktiva merr maskën e vërtetë: push "route 172.30.239.0 255.255.255.128". Access Server konfiguron të njëjtin destinacion përmes cilësimeve të rrjetit privat ose rregullave të aksesit të versionit të instaluar, me modalitetin e rrugëzuar ose të përkthyer të zgjedhur me qëllim. Redaktimi i zinxhirëve të firewall-it të gjeneruar në vend të konfigurimit pronar është mënyra se si një instalim funksional bëhet i pamundur për t’u riprodhuar.

Pas lidhjes lexoni tabelën e rrugëtimit të klientit dhe jo qëllimin e serverit. Një rrugë që mbulon vetëm grupin do të thotë që shtytja nuk mbërriti kurrë, dhe një rrugë e paracaktuar përmes tunelit është më e gjerë se kjo kërkesë dhe do t’ju habisë më vonë. Kontrolloni maskën dhe parashtesën, sepse një /25 i shtyrë si /24 dërgon trafikun e adresave fqinje në një rrugë që nuk mund ta mbajë. Pastaj konfirmoni që klienti zgjodhi ndërfaqen e tunelit për atë destinacion.

Bëni që selektorët të përfshijnë grupin e klientëve

Për akses të rrugëzuar që ruan adresat e klientëve, politika IPsec duhet të mbrojë trafikun midis grupit dhe parashtesës së largët. Selektorët e shkruar për LAN-in e vetë portës lejojnë ping-un dhe hedhin poshtë kërkesën e klientit, dhe kjo është pikërisht asimetria që nisi këtë hetim.

Shqyrtoni politikën e negociuar dhe propozimet e konfiguruara, për shembull me ipsec statusall në strongSwan ose komandën ekuivalente të statusit për implementimin tuaj. Në IPsec të bazuar në politika rruga e zakonshme mund të tregojë një ndërfaqe fizike ndërsa trafiku përputhës ende kriptohet, prandaj mungesa e një pajisjeje tuneli nuk provon asgjë. Krahasoni çiftet e selektorëve me grupin dhe parashtesën që shënuat.

NAT-i i burimit të përgjithshëm në portë mund të prishë gjithashtu përputhjen. Nëse një rregull masquerade rishkruan burimin e klientit përpara kontrollit të politikës, paketa nuk duket më si selektori që shkruat. Kjo është një arsye pse një rregull i gjerë masquerade është rregullim i dobët për një VPN të dytë: ndryshon se cila politikë zbatohet dhe cilën adresë regjistron pala e largët. Përjashtoni trafikun që keni ndër mend të rrugëzoni, ose përktheni me qëllim dhe përditësoni selektorët.

Zgjidhni me qëllim rrugëzimin ose përkthimin

Rrugëtimi e mban adresën e klientit të dukshme për palën e largët, kështu që regjistrat e largët dhe rregullat sipas burimit mbeten kuptimplota, dhe kërkon që porta e largët të njohë rrugën e kthimit drejt grupit. Përkthimi e fsheh grupin pas një adrese të vetme, gjë që heq problemin e rrugës së kthimit dhe shkatërron identitetin sipas klientit.

Zgjidhni një dizajn dhe shkruajeni, sepse të dy kërkojnë selektorë të ndryshëm dhe një renditje tjetër të firewall-it. Një masquerade i aplikuar gjysmë bie në mes dhe nuk kënaq asnjërin. Zgjedhja e shkruar është gjithashtu ajo që i lejon inxhinierit të ardhshëm të dallojë një gabim nga një vendim i qëllimshëm.

Mbyllni ciklin te përcjellja dhe përgjigjja

Porta duhet të përcjellë protokollin dhe destinacionin që keni ndër mend, që do të thotë përcjellje IP e aktivizuar dhe një zinxhir përcjelljeje që lejon çiftin. Pastaj pala e largët duhet t’i dërgojë përgjigjet mbrapsht nëpër rrugën IPsec, dhe ky është një vendim rrugëtimi në portën e tyre dhe jo në tuajën. Të dyja gjysmat janë konfigurim i zakonshëm, dhe të dyja mbeten lehtë gjysmë. Provoni ato veçmas, që një rregull përcjelljeje që mungon të mos merret për tunel të prishur.

Verifikoni me një kërkesë të vërtetë nga klienti te aplikacioni, duke e parë të kalojë nëpër ndërfaqen OpenVPN, vendimin IPsec dhe hostin e largët. Shqyrtoni përgjigjen si vëzhgim të veçantë, sepse një kërkesë që mbërrin dhe një përgjigje që nuk kthehet kurrë duken njësoj nga vendi i klientit. Një kërkesë e gjurmua valon më shumë se çdo numër ping-esh nga porta.

Mbajeni të ngushtë autorizimin e destinacionit gjatë provës, dhe konfirmoni që një klient pa rregullin nuk mund të arrijë shërbimin. Një rrugë e instaluar plus një asociacion i vendosur nuk është e njëjta gjë me aksesin e dhënë.