OpenVPN-viðskiptavinir sjá hvorn annan ekki: subnet eða net30?
Viðskiptavinir ná í netþjóninn en ekki hvern annan. Aðskiljið bilunina með einu pingi og veljið þá subnet-topologíu, client-to-client eða brúað TAP-hluta.
Tvær ótengdar bilanir gefa sömu kvörtun. Í fyrri nær einn viðskiptavinur ekki öðrum jafnvel með göngufanginu, því föngin eru ekki í sama subneti eða netþjónninn sendir ekki umferð milli jafningja. Í seinni virkar ping og tækjalisti forritsins er áfram tómur, því uppgötvun byggist á broadcast sem göng í lagi 3 geta ekki borið. Eitt ping aðskilur þau, og viðgerðin á hvoru um sig líkist alls ekki viðgerðinni á hinu.
Eitt ping klýfur vandann í tvennt
Frá einum viðskiptavini, pingaðu göngufang annars viðskiptavinar, ekki nafnið og ekki LAN-fangið. Ef það mistekst er sendingin eða fangamerkingin vandamálið og uppgötvun óviðkomandi þar til það er lagað. Ef það tekst virkar sendingin þegar og það sem vantar er broadcast eða nafnaupplausn.
ip addr show tun0
Lestu viðmót viðskiptavinarins fyrir allt annað, því netgríman nefnir topologíuna. /24 eða önnur subnetgríma þýðir sameiginlegt þyrpingu; /30 með jafningjafangi þýðir eldra punkt-í-punkt-fyrirkomulagið, þar sem hver viðskiptavinur hefur nákvæmlega einn nágranna, netþjóninn.
net30 á móti subnet, lesið frá hlið viðskiptavinarins
| 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 |
Með net30 úthlutar netþjónninn litlum blokk á hvern viðskiptavin, svo leið að göngufangi annars viðskiptavinar er ekki til nema netþjónninn sendi hana. Með subneti er allt þyrpingin eitt net, hver viðskiptavinur getur ávarpað hvern annan og netþjónninn sendir á milli. Þess vegna getur ein netþjónsuppsetning litið heilbrigð út á meðan ping milli jafningja mistekst: ekkert er bilað, viðskiptavinirnir eru einfaldlega ekki í einu neti. Viðskiptavinurinn sér virka tengingu og jafningjafang sem svarar ekki, sem les eins og eldveggur en er fangamerkingarfyrirkomulag.
Að skipta um tilskipun er breyting á netþjónshliðinni ásamt endurræsingu, og hún gildir fyrir næstu tengingu en ekki lotur sem þegar eru opnar. Tengdu viðskiptavini aftur áður en þú metur breytinguna. Ef tæki endurgerir uppsetninguna úr vefviðmóti skaltu skrá tilskipunina, skrána og dagsetninguna, og gera breytinguna í gegnum viðmótið þegar það er til, því endurgerð mun skrifa yfir handvirka breytingu við næstu vistun.
client-to-client er sér hlið
Jafnvel innan eins subnets hendir netþjónninn böggum sem koma frá einum viðskiptavini og eru stílaðir á annan nema client-to-client sé stillt. Það lykilorð gerir netþjóninn að sendanda umferðar milli jafningja í stað endapunkts sem tekur aðeins við henni. Það er annað skilyrðið sem fólk missir af eftir að hafa lagað topologíuna.
Þetta nær ekki til broadcast. Stillingin sendir unicast milli viðskiptavina; hún gerir göngin ekki að sameiginlegum hluta, og engin upphæð af henni mun skila multicast-uppgötvunarfyrirspurn til hvers jafningja.
TUN á móti TAP, og hvað hvort getur borið
| 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 |
Að brúa tap-tæki inn í LAN setur fjartengda viðskiptavini í broadcast-lén skrifstofunnar, sem leysir uppgötvun að fullu. Verðið er þær kerfisstöðvar sem innleiða ekki TAP, brú sem verður að vera á netþjóninum, og bilanalén þar sem broadcast-stormur á skrifstofusnúrunni nær til hverrar fjartengdrar fartölvu.
Fyrir tvo eða þrjá vinnustöðvar sem þurfa nafnaupplausn er hosts-færsla eða unicast-fang mun ódýrara en brú. Gríptu til TAP þegar samskiptaregla sem þú getur ekki skipt út byggist á uppgötvun í lagi 2, og ekki fyrr.
Viðskiptavinir í sama subneti án brúar
Að úthluta fangi úr LAN-bilinu setur ekki viðskiptavininn á snúruna. Netþjónninn beinir milli gagnagangs og Ethernet, svo ARP fyrir það fang stöðvast við viðmót netþjónsins og restin af LAN-inu kemst aldrei að því hvar það býr.
ip neigh add proxy 10.50.1.250 dev eth0
Proxy ARP lokar því bili með því að láta netþjóninn svara fyrir hönd viðskiptavinarins. Fyrir bil heldur parpd utan um færslurnar þegar viðskiptavinir koma og fara, á meðan sysctl net.ipv4.conf.eth0.proxy_arp=1 svarar fyrir allt sem er beint annað, sem er nógu breitt til að skapa eigin óvart á annasömum hluta.
Hvaða leið sem þú velur, fjarlægðu NAT milli gagnagangsins og snúrunnar. MASQUERADE-regla felur einmitt fangamerkingarspurninguna sem þú ert að reyna að svara. Hún skilur líka eftir næstu manneskju með topologíu sem hún getur ekki hugsað um frá hlið viðskiptavinarins.
Áður en þú breytir einhverju skaltu grípa eina tilraun á netþjóninum með tcpdump -ni tun0 og staðfesta hvort jafningjabaggi kemur yfirhöfuð. Að koma og vera hent bendir til client-to-client; að koma aldrei bendir til topologíu eða leiðar. OpenVPN 2.6 handbókin skjalfestir bæði lykilorðin og sjálfgefnu topologíuna, sem er þess virði að bera saman við þína útgáfu áður en þú afritar línu úr spjallborðsfærslu.
- tun-viðmótið sýnir grímu þyrpingar en ekki /30 jafningjapar.
- Beint ping á hitt göngufangið tekst áður en þú prófar uppgötvun.
- Netþjónsuppsetningin inniheldur
client-to-clienthvenær sem jafningjar þurfa að skiptast á böggum. - Nefndu uppgötvunarsamskiptaregluna sem þú prófar í stað þess að segja að forritið mistakist.
- Notaðu TAP aðeins ef hver viðskiptavinaekerfisstöð í hópnum styður það.
- Haltu NAT utan við leiðina milli gagnagangs og LAN þegar aðgengi innan sama subnets skiptir máli.