OpenVPN bezeroek ez dute elkar ikusten: azpisarea ala net30?

Erlaziorik gabeko bi matxurak kexa bera sortzen dute. Lehenengoan bezero bat ezin da bestearengana iritsi tunel helbideaz ere, helbideak azpisare berean ez daudelako edo zerbitzariak pareen arteko trafikoa birbidaltzen ez duelako. Bigarrenean ping-ek funtzionatzen du eta aplikazioaren gailu zerrenda hutsik geratzen da, aurkikuntza broadcast-en oinarritzen delako, eta 3. geruzako tunelek ezin du hori garraiatu. Ping bakar batek banatzen ditu, eta bakoitzaren konponbidea ez da batere antzekoa bestearenekin.

Ping bakar batek arazoa bitan zatitzen du

Bezero batetik, egin ping beste bezeroaren tunel helbideari, ez bere izenari eta ez bere LAN helbideari. Hori huts egiten badu, birbidalketa edo helbideratzea da arazoa eta aurkikuntza garrantzirik gabea da konpondu arte. Arrakasta badu, birbidalketa jada funtzionatzen ari da eta falta den hutsunea broadcast edo izenen ebazpena da.

ip addr show tun0

Irakurri bezeroaren interfazea beste edozer baino lehen, sare-maskak izendatzen baitu topologia. /24 edo beste azpisare maskara batek pool partekatua esan nahi du; pare helbidea duen /30 batek puntutik punturako diseinu zaharra esan nahi du, non bezero bakoitzak auzoko bat duen, zerbitzaria.

net30 versus azpisarea, bezeroaren aldetik irakurrita

net30-rekin zerbitzariak bezero bakoitzari bloke txiki bat ematen dio, beraz, ezin da beste bezero baten tunel helbiderako ibilbiderik egon zerbitzariak birbidaltzen ez badu. Azpisarearekin pool osoa sare bat da, bezero bakoitzak beste edozeri zuzendu diezaioke, eta zerbitzariak haien artean birbidaltzen du. Horregatik zerbitzari konfigurazio bat osasuntsu dirudi pareen arteko ping-ek huts egiten duten bitartean: ez dago ezer hondatuta, bezeroak ez daude sare berean besterik gabe. Bezeroak funtzionatzen duen esteka eta erantzuten ez duen pare helbidea ikusten ditu, suebaki bat bezala irakurtzen dena baina helbideratze diseinua dena.

Direktiba aldatzea zerbitzari aldeko edizioa eta berrabiaraztea da, eta hurrengo konexioari aplikatzen zaio, ez jada irekita dauden saioei. Berriz konektatu bezeroak aldaketa epaitu aurretik. Gailuak web interfazetik konfigurazioa birsortzen badu, idatzi direktiba, fitxategia eta data, eta egin edizioa interfazearen bidez existitzen denean, birsorkuntzak hurrengo gordetzean eskuzko edizioa gainidatziko baitu.

client-to-client ate bereizi bat da

Azpisare baten barruan ere, zerbitzariak baztertu egiten ditu bezero batetik datozen eta beste batera zuzendutako paketeak, client-to-client ezarrita ez badago. Gako-hitz horrek zerbitzaria pareen trafikoaren birbidaltzaile bihurtzen du, soilik onartzen duen amaiera-puntu izan beharrean. Topologia konpondu ondoren jendeak ahazten duen bigarren baldintza da.

Ez da broadcast-era hedatzen. Ezarpenak unicast-a birbidaltzen du bezeroen artean; ez du tunela segmentu partekatu bihurtzen, eta ez du inolako kantitaterik multicast aurkikuntza kontsulta pare guztiei entregatuko.

TUN versus TAP, eta bakoitzak zer garraia dezakeen

tap gailu bat LAN-era zubitzeak urrutiko bezeroak bulegoko broadcast domeinuan jartzen ditu, eta horrek aurkikuntza erabat konpontzen du. Prezioa TAP inplementatzen ez duten plataformak, zerbitzarian egon behar duen zubi bat eta hutsegite domeinu bat dira, non bulegoko kableko broadcast ekaitz batek urrutiko ordenagailu guztietara iristen den.

Izenen ebazpena behar duten bi edo hiru lan-posturentzat, hosts sarrera bat edo unicast helbide bat zubi bat baino askoz merkeagoa da. Egin TAP-era ordezkatu ezin duzun protokolo bat 2. geruzako aurkikuntzaren mende dagoenean, eta ez lehenago.

Zubirik gabeko azpisare bereko bezeroak

LAN barrutiko helbide bat esleitzeak ez du bezeroa kablean jartzen. Zerbitzariak tuneletik Ethernet-era bideratzen du, beraz helbide horretarako ARP zerbitzariaren interfazean gelditzen da eta LAN gainerakoak ez du inoiz jakiten non bizi den.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP-k hutsune hori ixten du zerbitzariak bezeroaren izenean erantzun dezan. Barruti baterako, parpd-k sarrerak kudeatzen ditu bezeroak etorri eta joan ahala, eta sysctl net.ipv4.conf.eth0.proxy_arp=1-k beste nonbait bideratutako guztiarentzat erantzuten du, zeina nahikoa zabala den segmentu okupatu batean bere harridurak sortzeko.

Aukeratzen duzun bidea aukeratuta ere, kendu NAT tunelaren eta kablearen artean. MASQUERADE arau batek erantzun nahi duzun helbideratze galdera ezkutatzen du zehazki. Gainera, hurrengo pertsonari bezeroaren aldetik arrazoitu ezin duen topologia uzten dio.

Ezer aldatu aurretik, harrapatu saiakera bat zerbitzarian tcpdump -ni tun0 erabiliz eta egiaztatu parearen paketea iristen den ala ez. Iritsi eta baztertzea client-to-client-en seinale da; inoiz ez iristea topologia edo bideratzearen seinale. OpenVPN 2.6 eskuliburuak bi gako-hitzak eta topologia lehenetsia dokumentatzen ditu, eta merezi du zure bertsioarekin alderatzea foroko mezu batetik lerro bat kopiatu aurretik.

• tun interfazeak pool maskara erakusten du /30 pare bikotearen ordez.
• Beste tunel helbidera ping zuzena lortzen da aurkikuntza probatu aurretik.
• Zerbitzariaren konfigurazioak client-to-client dakar pareek paketeak trukatu behar dituzten bakoitzean.
• Aipa probatzen ari zaren aurkikuntza protokoloa, aplikazioak huts egiten duela esan beharrean.
• Erabili TAP taldeko bezero plataforma guztiek onartzen badute soilik.
• Mantendu NAT kanpoan tunelaren eta LANaren arteko bidetik azpisare bereko irisgarritasuna garrantzitsua denean.