OpenVPN klienti neredz viens otru: apakštīkls vai net30?
Klienti sasniedz serveri, bet ne viens otru. Atdaliet kļūmi ar vienu ping un tad izvēlieties apakštīkla topoloģiju, client-to-client vai tiltota TAP segmentu.
Divas nesaistītas kļūdas rada vienu un to pašu sūdzību. Pirmajā gadījumā viens klients nevar sasniegt otru pat pēc tuneļa adreses, jo adreses nav vienā apakštīklā vai serveris nepārsūta satiksmi starp vienaudžiem. Otrajā gadījumā ping darbojas, bet lietotnes ierīču saraksts paliek tukšs, jo atklāšana balstās uz apraidi, ko 3. slāņa tunelis nespēj pārnest. Viens ping tos atdala, un katra labojums nepavisam nelīdzinās otra labojumam.
Viens ping sadala problēmu divās
No viena klienta pingojiet otra klienta tuneļa adresi, nevis tā vārdu un nevis tā LAN adresi. Ja tas neizdodas, problēma ir pārsūtīšanā vai adresēšanā, un atklāšana nav būtiska, līdz tas nav izlabots. Ja izdodas, pārsūtīšana jau darbojas, un atlikušā plaisa ir apraide vai vārdu atrisināšana.
ip addr show tun0Vispirms izlasiet klienta saskarni, jo tīkla maska nosauc topoloģiju. /24 vai cita apakštīkla maska nozīmē kopīgu pūlu; /30 ar vienaudža adresi nozīmē vecāko punkts-punktā izkārtojumu, kur katram klientam ir tieši viens kaimiņš, serveris.
net30 pret apakštīklu, lasīts no klienta puses
| 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 |
Ar net30 serveris piešķir mazu bloku katram klientam, tāpēc maršruts uz cita klienta tuneļa adresi nepastāv, ja vien serveris to nepārsūta. Ar apakštīklu viss pūls ir viens tīkls, katrs klients var uzrunāt katru citu, un serveris pārsūta starp tiem. Tāpēc viena servera konfigurācija var izskatīties vesela, kamēr ping starp vienaudžiem neizdodas: nekas nav salauzts, klienti vienkārši nav vienā tīklā. Klients redz darbojošos saiti un neatbildošu vienaudža adresi, kas lasās kā ugunsmūris, bet patiesībā ir adresēšanas izkārtojums.
Direktīvas maiņa ir servera puses rediģēšana un restartēšana, un tā attiecas uz nākamo savienojumu, nevis jau atvērtām sesijām. Pirms vērtējat izmaiņas, pievienojiet klientus no jauna. Ja ierīce ģenerē konfigurāciju no jauna no tīmekļa saskarnes, pierakstiet direktīvu, failu un datumu, un veiciet rediģēšanu caur saskarni, kad tāda ir, jo pārģenerēšana pārrakstīs manuālu rediģējumu nākamajā saglabāšanā.
client-to-client ir atsevišķi vārti
Pat vienā apakštīklā serveris izmet paketes, kas nāk no viena klienta un ir adresētas citam, ja vien client-to-client nav iestatīts. Šis atslēgvārds pārvērš serveri par vienaudžu satiksmes pārsūtītāju, nevis galapunktu, kas to tikai pieņem. Tas ir otrais nosacījums, ko cilvēki izlaiž pēc topoloģijas izlabošanas.
Tas neattiecas uz apraidi. Iestatījums pārsūta unicast starp klientiem; tas nepārvērš tuneli kopīgā segmentā, un neviens tā apjoms nepiegādās multicast atklāšanas vaicājumu katram vienaudzim.
TUN pret TAP, un ko katrs spēj pārnest
| 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 ierīces tiltotiešana LAN tīklā ievieto attālos klientus biroja apraides domēnā, kas pilnībā atrisina atklāšanu. Cena ir platformas, kas neievieš TAP, tilts, kam jāpastāv uz servera, un bojājumu domēns, kur apraides vētra biroja kabelī sasniedz katru attālo klēpjdatoru.
Divām vai trim darbstacijām, kurām vajadzīga vārdu atrisināšana, hosts ieraksts vai unicast adrese ir daudz lētāka par tiltu. Pievērsieties TAP tad, kad protokols, kuru nevarat aizstāt, ir atkarīgs no 2. slāņa atklāšanas, un ne agrāk.
Tā paša apakštīkla klienti bez tilta
Adreses piešķiršana no LAN diapazona neieliek klientu kabelī. Serveris maršrutē starp tuneli un Ethernet, tāpēc šīs adreses ARP apstājas servera saskarnē, un pārējais LAN nekad neuzzina, kur tā dzīvo.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP aizver šo plaisu, liekot serverim atbildēt klienta vārdā. Diapazonam parpd pārvalda ierakstus, klientiem nākot un ejot, bet sysctl net.ipv4.conf.eth0.proxy_arp=1 atbild par visu, kas maršrutēts citur, kas ir pietiekami plats, lai radītu savus pārsteigumus noslogotā segmentā.
Lai kādu ceļu izvēlētos, noņemiet NAT starp tuneli un kabeli. MASQUERADE noteikums slēpj tieši to adresēšanas jautājumu, uz kuru mēģināt atbildēt. Tas arī atstāj nākamajam cilvēkam topoloģiju, par kuru viņš no klienta puses nevar spriest.
Pirms kaut ko maināt, noķeriet vienu mēģinājumu serverī ar tcpdump -ni tun0 un apstipriniet, vai vienaudža pakete vispār pienāk. Pienāk un tiek izmesta — tas norāda uz client-to-client; nekad nepienāk — norāda uz topoloģiju vai maršrutēšanu. OpenVPN 2.6 rokasgrāmata dokumentē abus atslēgvārdus un noklusējuma topoloģiju, ko ir vērts salīdzināt ar savu versiju pirms rindas kopēšanas no foruma ziņas.
- tun saskarne rāda pūla masku, nevis /30 vienaudžu pāri.
- Tiešs ping uz otru tuneļa adresi izdodas pirms atklāšanas pārbaudes.
- Servera konfigurācija ietver
client-to-clientikreiz, kad vienaudžiem jāapmainās ar paketēm. - Nosauciet pārbaudāmo atklāšanas protokolu, nevis sakiet, ka lietotne neizdodas.
- Izmantojiet TAP tikai tad, ja to atbalsta katra grupas klienta platforma.
- Turiet NAT ārpus ceļa starp tuneli un LAN, kad svarīga ir sasniedzamība tajā pašā apakštīklā.