OpenVPN iroute kundrejt rrugës së kernelit: cila mungon?

Një paketë për 10.77.20.0/24 merr dy vendime të ndara në një server OpenVPN: sistemi operativ duhet ta dorëzojë te ndërfaqja VPN, dhe OpenVPN duhet të dijë se cili klient i lidhur zotëron atë prefiks. Një rrugë kernel që mungon e hedh poshtë përpara tunelit, dhe një rrugë peer që mungon e hedh poshtë pas tij. Të dyja dështimet duken njësoj nga LAN-i i largët, dhe diagnostikimi se cilën keni kërkon një komandë në secilën anë.

Në rrugën klasike të të dhënave në hapësirën e përdoruesit, rruga e kernelit e çon paketën në procesin e tunelit, dhe iroute i thotë atij procesi cili peer duhet ta marrë. Asnjëra nuk zëvendëson tjetrën, dhe një konfigurim me vetëm njërën prej tyre do të duket i arsyeshëm deri në ping-un e parë.

Dy vendime, jo një rrugë

Imagjinoni një lidhje mes site-eve ku 10.77.20.0/24 ndodhet pas një klienti të vetëm. Rruga e kernelit të serverit, për shembull ip route add 10.77.20.0/24 dev tun0, i dërgon paketat përkatëse pajisjes së tunelit. Pastaj OpenVPN konsulton tabelën e vet të brendshme, të ndërtuar nga hyrjet iroute në drejtorinë e konfigurimit të klientit, për të vendosur cila lidhje peer i merr ato. Pa rrugën e kernelit paketa nuk arrin kurrë te procesi, dhe pa rrugën e peer-it arrin te procesi dhe nuk shkon askund.

Ajo ndarje harrohet lehtë, sepse një rresht i vetëm rruge në profilin e klientit mund të duket sikur bën të dyja punët. Nuk i bën: shtyrja e një rruge u thotë klientëve çfarë të dërgojnë përmes tunelit, ndërsa iroute i thotë serverit kush zotëron një interval adresash pas një klienti. Ato jetojnë në skedarë të ndryshëm, lexohen nga anë të ndryshme dhe dështojnë në drejtime të kundërta.

Ku hyn iroute dhe çfarë thotë

Hyrja shkon në një skedar për klient, i emërtuar sipas common_name të klientit, brenda client-config-dir, si iroute 10.77.20.0/24. Përputhja e emrit të skedarit nuk është kozmetike: OpenVPN kërkon identitetin e vërtetuar dhe lexon skedarin pikërisht me atë emër, kështu që një skedar i quajtur site-a vlen vetëm për një klient emri i përbashkët i të cilit është site-a. Shtoni ccd-exclusive nëse klientët pa një skedar të tillë duhet të refuzohen plotësisht, që është cilësimi i duhur kur çdo klient është një portë site-i. Mbani një skedar për çdo portë dhe emërtojeni sipas subjektit të certifikatës që lëshoni vërtet.

Testoni hyrjen nga serveri përpara se të fajësoni LAN-in e largët. Skedari i statusit liston klientët e lidhur me emrat e tyre të përbashkët, dhe një server që punon me --verb 4 regjistron instalimin e iroute në momentin që peer-i lidhet. Nëse në lidhje nuk shfaqet asgjë, skedari është në drejtorinë e gabuar ose emërton identitetin e gabuar.

Kurthi: skedari ekziston, identiteti është i gabuar

Një iroute që duket i saktë por është i lidhur me peer-in e gabuar humb më shumë kohë sesa një skedar që mungon, sepse gjithçka në disk duket në rregull. Riemërtimi i certifikatave, emrat e përbashkët të dyfishuar dhe username-as-common-name që ndryshon identitetin efektiv i prodhojnë të gjitha. Kontrolloni cilin identitet vërtetoi serveri, jo atë që prisnit: dalja e statusit është autoritative, ndërsa emri i skedarit është vetëm një çelës kërkimi.

Një rrugë mund ta mbijetojë pronarin e saj. Rrugët statike dhe hyrjet iroute përshkruajnë një prefiks, jo një garanci disponueshmërie, prandaj trafiku mund të vazhdojë të drejtohet drejt një peer-i që aktualisht është i shkëputur.

Përfundoni rrugën përtej peer-it

Pronësia e peer-it është mesi i rrugës, jo fundi. Klienti duhet t’i përcjellë paketat nga tuneli në LAN-in e vet, që do të thotë përcjellje IP e aktivizuar në atë host dhe një rregull firewall që lejon kalimin. Hostet në LAN-in e largët kanë nevojë për një rrugë kthimi për adresën e tunelit: ose një rrugë që tregon përsëri drejt portës, ose një dizajn NAT të qëllimshëm në anën e klientit. Konfirmoni cilësimin e përcjelljes në klient me sysctl net.ipv4.ip_forward në vend që të supozoni një vlerë të parazgjedhur të shpërndarjes.

Nëse klientë të tjerë VPN duhet të arrijnë atë nënrrjet, rregullimi rritet përsëri: serveri ka nevojë për client-to-client, dhe ata klientë duhet ta drejtojnë prefiksin përmes tunelit. Asgjë nga kjo nuk rrjedh nga tabela e rrugëve e vetë serverit.

Verifikoni një destinacion nga një burim real në vend të vetë serverit. Një ping nga një host LAN i palidhur drejt një hosti pas klientit ushtron rrugën e kthimit, rregullin e përcjelljes dhe pronësinë e peer-it në një lëvizje të vetme, ndërsa një handshake i suksesshëm provon vetëm identitetin. Pastaj shkëputni peer-in pronar dhe shënoni çfarë bën rruga, sepse ajo përgjigje është mënyra juaj e dështimit.