Klientët e OpenVPN nuk shihen me njëri-tjetrin: subnet apo net30?

Dy defekte të palidhura japin të njëjtin ankth. Në të parin, një klient nuk arrin tjetrin as përmes adresës së tunelit, sepse adresat nuk janë në një subnet ose serveri nuk përcjell trafikun mes palëve. Në të dytin, ping funksionon, por lista e pajisjeve të aplikacionit mbetet bosh, sepse zbulimi mbështetet në broadcast që një tunel i shtresës 3 nuk mund ta mbajë. Një ping i ndan ata, dhe rregullimi për secilin nuk i ngjan aspak rregullimit për tjetrin.

Një ping e ndan problemin në dy

Nga një klient, pingoni adresën e tunelit të klientit tjetër, jo emrin dhe jo adresën e LAN-it. Nëse dështon, problemi është përcjellja ose adresimi dhe zbulimi është i parëndësishëm derisa të rregullohet. Nëse funksionon, përcjellja tashmë punon dhe ajo që mungon është broadcast ose zgjidhja e emrave.

ip addr show tun0

Lexoni ndërfaqen e klientit para çdo gjëje tjetër, sepse maska e rrjetit emërton topologjinë. Një /24 ose një maskë tjetër subnet-i do të thotë një pishinë e përbashkët; një /30 me adresë pale do të thotë rregullimi i vjetër pikë-për-pikë, ku çdo klient ka saktësisht një fqinj, serverin.

net30 kundrejt subnet, lexuar nga ana e klientit

Me net30 serveri shpërndan një bllok të vogël për klient, kështu që nuk ekziston rrugë drejt adresës së tunelit të një klienti tjetër, përveç nëse serveri e përcjell. Me subnet e gjithë pishina është një rrjet, çdo klient mund të adresojë çdo tjetrin, dhe serveri përcjell mes tyre. Prandaj një konfigurim serveri mund të duket i shëndetshëm ndërsa ping-et mes palëve dështojnë: asgjë nuk është prishur, klientët thjesht nuk janë në një rrjet. Klienti sheh një lidhje që punon dhe një adresë pale që nuk përgjigjet, gjë që lexohet si firewall, por është një skemë adresimi.

Ndryshimi i direktivës është redaktim në anën e serverit plus rinisje, dhe vlen për lidhjen tjetër, jo për sesionet tashmë të hapura. Rilidhni klientët para se ta gjykoni ndryshimin. Nëse një pajisje rigjeneron konfigurimin nga një ndërfaqe web, shënoni direktivën, skedarin dhe datën, dhe bëjeni redaktimin përmes ndërfaqes kur ekziston, sepse një rindërtim do të mbishkruajë një redaktim manual në ruajtjen tjetër.

client-to-client është një portë më vete

Edhe brenda një subnet-i serveri hedh poshtë paketat që vijnë nga një klient dhe janë adresuar për një tjetër, përveç nëse client-to-client është vendosur. Ajo fjalë kyçe e kthen serverin në një përcjellës të trafikut mes palëve, në vend të një pike fundore që thjesht e pranon. Është kushti i dytë që njerëzit e humbin pasi rregullojnë topologjinë.

Kjo nuk shtrihet te broadcast. Cilësimi përcjell unicast mes klientëve; nuk e kthen tunelin në një segment të përbashkët, dhe asnjë sasi e tij nuk do t'i dorëzojë një kërkesë zbulimi multicast çdo pale.

TUN kundrejt TAP, dhe çfarë mund të mbajë secili

Urëzimi i një pajisjeje tap në LAN i vendos klientët e largët në domenin e broadcast të zyrës, gjë që e zgjidh plotësisht zbulimin. Çmimi janë platformat që nuk implementojnë TAP, një urë që duhet të ekzistojë në server, dhe një domen dështimi ku një stuhi broadcast në kabllon e zyrës arrin çdo laptop të largët.

Për dy ose tre stacione pune që kanë nevojë për zgjidhje emrash, një zë hosts ose një adresë unicast është shumë më e lirë se një urë. Drejtohuni te TAP kur një protokoll që nuk mund ta zëvendësoni varet nga zbulimi i shtresës 2, dhe jo më parë.

Klientë të të njëjtit subnet pa urë

Caktimi i një adrese nga diapazoni i LAN-it nuk e vendos klientin në kabllo. Serveri rrugëton mes tunelit dhe Ethernet, prandaj ARP për atë adresë ndalon në ndërfaqen e serverit dhe pjesa tjetër e LAN-it nuk mëson kurrë ku banon.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP e mbyll atë boshllëk duke bërë serverin të përgjigjet në emër të klientit. Për një diapazon, parpd administron zërat ndërsa klientët vijnë dhe shkojnë, ndërsa sysctl net.ipv4.conf.eth0.proxy_arp=1 përgjigjet për gjithçka që rrugëtohet diku tjetër, e cila është mjaftueshëm e gjerë për të krijuar surprizat e veta në një segment të ngarkuar.

Cilën rrugë të zgjidhni, hiqni NAT mes tunelit dhe kabllos. Një rregull MASQUERADE fsheh pikërisht pyetjen e adresimit të cilës po përpiqeni t'i përgjigjeni. Ai gjithashtu i lë personit tjetër një topologji për të cilën nuk mund të arsyetojë nga ana e klientit.

Para se të ndryshoni gjë, kapni një provë në server me tcpdump -ni tun0 dhe konfirmoni nëse paketa e palës arrin fare. Të arrijë dhe të hidhet poshtë tregon client-to-client; të mos arrijë kurrë tregon topologjinë ose rrugëtimin. Manualja e OpenVPN 2.6 dokumenton të dyja fjalët kyçe dhe topologjinë e parazgjedhur, gjë që ia vlen të krahasohet me versionin tuaj para se të kopjoni një rresht nga një postim forumi.

• Ndërfaqja tun shfaq një maskë pishine, jo një çift palësh /30.
• Një ping i drejtpërdrejtë te adresa tjetër e tunelit funksionon para se të provoni zbulimin.
• Konfigurimi i serverit përfshin client-to-client sa herë që palët duhet të shkëmbejnë paketa.
• Emërtoni protokollin e zbulimit që po provoni, në vend që të thoni se aplikacioni dështon.
• Përdorni TAP vetëm nëse çdo platformë klienti në grup e mbështet.
• Mbani NAT jashtë rrugës mes tunelit dhe LAN-it kur ka rëndësi arritshmëria brenda të njëjtit subnet.