OpenVPN-asiakkaat eivät näe toisiaan: subnet vai net30?
Asiakkaat tavoittavat palvelimen mutta eivät toisiaan. Erota vika yhdellä pingillä ja valitse sitten subnet-topologia, client-to-client tai sillattu TAP-segmentti.
Kaksi toisistaan riippumatonta vikaa tuottaa saman valituksen. Ensimmäisessä yksi asiakas ei tavoita toista edes tunneliosoitteella, koska osoitteet eivät ole samassa subnetissä tai palvelin ei välitä vertaisliikennettä. Toisessa ping toimii ja sovelluksen laiteluettelo jää tyhjäksi, koska löytäminen perustuu broadcastiin, jota kerroksen 3 tunneli ei voi kuljettaa. Yksi ping erottaa ne, eikä kummankaan korjaus muistuta lainkaan toisen korjausta.
Yksi ping jakaa ongelman kahtia
Pingaa yhdestä asiakkaasta toisen asiakkaan tunneliosoitetta, ei sen nimeä eikä sen LAN-osoitetta. Jos se epäonnistuu, vika on välityksessä tai osoitteistuksessa, eikä löytäminen merkitse mitään ennen kuin se on korjattu. Jos se onnistuu, välitys toimii jo ja jäljellä oleva puute on broadcast tai nimien selvitys.
ip addr show tun0Lue asiakkaan liitäntä ennen kaikkea muuta, koska verkkomaski nimeää topologian. /24 tai muu aliverkon maski tarkoittaa jaettua poolia; /30, jossa on vertaisosoite, tarkoittaa vanhempaa piste-piste-asettelua, jossa jokaisella asiakkaalla on täsmälleen yksi naapuri, palvelin.
net30 vastaan subnet, luettuna asiakkaan puolelta
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
net30:ssä palvelin jakaa jokaiselle asiakkaalle pienen lohkon, joten reittiä toisen asiakkaan tunneliosoitteeseen ei ole, ellei palvelin välitä sitä. Subnetissä koko pooli on yksi verkko, jokainen asiakas voi osoittaa jokaista muuta ja palvelin välittää niiden välillä. Siksi yksi palvelinkokoonpano voi näyttää terveeltä, vaikka vertaisten pingit epäonnistuvat: mikään ei ole rikki, asiakkaat eivät yksinkertaisesti ole samassa verkossa. Asiakas näkee toimivan yhteyden ja vertaisosoitteen, joka ei vastaa, mikä kuulostaa palomuurilta mutta on osoitteistusratkaisu.
Direktiivin vaihtaminen on palvelinpuolen muokkaus ja uudelleenkäynnistys, ja se koskee seuraavaa yhteyttä, ei jo avoinna olevia istuntoja. Yhdistä asiakkaat uudelleen ennen muutoksen arvioimista. Jos laite luo kokoonpanon uudelleen verkkoliittymästä, kirjaa direktiivi, tiedosto ja päivämäärä, ja tee muokkaus liittymän kautta kun sellainen on, koska uudelleenluonti korvaa käsin tehdyn muokkauksen seuraavassa tallennuksessa.
client-to-client on erillinen portti
Jopa yhden subnetin sisällä palvelin pudottaa paketit, jotka tulevat yhdeltä asiakkaalta ja on osoitettu toiselle, ellei client-to-client ole asetettu. Se avainsana tekee palvelimesta vertaisliikenteen välittäjän sen sijaan, että se olisi vain vastaanottava päätepiste. Se on toinen ehto, jonka ihmiset ohittavat korjattuaan topologian.
Se ei ulotu broadcastiin. Asetus välittää unicastia asiakkaiden välillä; se ei tee tunnelista jaettua segmenttiä, eikä mikään määrä sitä toimita multicast-löytämiskyselyä jokaiselle vertaiselle.
TUN vastaan TAP, ja mitä kumpikin voi kuljettaa
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
tap-laitteen sillaus LANiin tuo etäasiakkaat toimiston broadcast-verkkotunnukseen, mikä ratkaisee löytämisen täysin. Hinta on alustat, jotka eivät toteuta TAPia, palvelimella oltava silta ja vikavyöhyke, jossa toimiston kaapelin broadcast-myrsky yltää jokaiseen etäkannettavaan.
Kahdelle tai kolmelle työasemalle, jotka tarvitsevat nimien selvitystä, hosts-merkintä tai unicast-osoite on paljon halvempi kuin silta. Turvaudu TAPiin, kun protokolla, jota et voi korvata, riippuu kerroksen 2 löytämisestä, eikä ennen sitä.
Saman subnetin asiakkaat ilman siltaa
Osoitteen antaminen LANin alueelta ei tuo asiakasta kaapeliin. Palvelin reitittää tunnelin ja Ethernetin välillä, joten kyseisen osoitteen ARP pysähtyy palvelimen liitäntään eikä muu LAN saa koskaan tietää, missä se asuu.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP sulkee tämän aukon siten, että palvelin vastaa asiakkaan puolesta. Alueelle parpd hallitsee merkintöjä asiakkaiden tullessa ja mennessä, kun taas sysctl net.ipv4.conf.eth0.proxy_arp=1 vastaa kaikesta muualle reititetystä, mikä on tarpeeksi laajaa luomaan omat yllätyksensä vilkkaalla segmentillä.
Minkä reitin valitsetkin, poista NAT tunnelin ja kaapelin välistä. MASQUERADE-sääntö kätkee juuri sen osoitteistuskysymyksen, johon yrität vastata. Se jättää myös seuraavalle henkilölle topologian, josta hän ei voi päätellä asiakkaan puolelta.
Ennen kuin muutat mitään, tallenna palvelimella yksi yritys tcpdump -ni tun0-komennolla ja varmista, saapuuko vertaispaketti lainkaan. Saapuminen ja hylkääminen viittaa client-to-clientiin; se, ettei se koskaan saavu, viittaa topologiaan tai reititykseen. OpenVPN 2.6 -käsikirja dokumentoi molemmat avainsanat ja oletustopologian, ja se kannattaa tarkistaa versiotasi vasten ennen kuin kopioit rivin foorumiviestistä.
- tun-liitäntä näyttää poolin maskin eikä /30-vertaisparia.
- Suora ping toiseen tunneliosoitteeseen onnistuu ennen kuin testaat löytämistä.
- Palvelinkokoonpano sisältää
client-to-clientaina, kun vertaisten on vaihdettava paketteja. - Nimeä löytämisprotokolla, jota testaat, sen sijaan että sanoisit sovelluksen epäonnistuvan.
- Käytä TAPia vain, jos jokainen ryhmän asiakasalusta tukee sitä.
- Pidä NAT poissa tunnelin ja LANin väliseltä polulta, kun saavutettavuus saman subnetin sisällä on tärkeää.