OpenVPN-klienter ser inte varandra: subnet eller net30?

Klienterna når servern men inte varandra. Dela felet med ett enda ping och välj sedan subnätstopologi, client-to-client eller ett bryggat TAP-segment.

Två oberoende fel ger samma klagomål. I det första når en klient inte en annan ens via tunneladressen, eftersom adresserna inte ligger i samma subnät eller servern inte vidarebefordrar trafik mellan parter. I det andra fungerar ping men appens enhetslista förblir tom, eftersom upptäckten bygger på broadcast som en tunnel på lager 3 inte kan bära. Ett enda ping skiljer dem, och rättelsen för den ena liknar inte alls rättelsen för den andra.

Ett ping delar problemet i två

Från en klient, pinga den andra klientens tunneladress, inte namnet och inte LAN-adressen. Om det misslyckas är vidarebefordran eller adressering problemet och upptäckt är irrelevant tills det är åtgärdat. Om det lyckas fungerar vidarebefordran redan och det som saknas är broadcast eller namnmatchning.

ip addr show tun0

Läs klientens gränssnitt före allt annat, eftersom nätmasken namnger topologin. En /24 eller annan subnätsmask betyder en delad pool; en /30 med en partadress betyder den äldre punkt-till-punkt-layouten, där varje klient har exakt en granne, servern.

net30 kontra subnet, läst från klientsidan

What you observenet30subnet
Client netmask/30 with a peer addressThe pool's own mask
Peers a client can address directlyOne, the serverEvery client in the pool
AddressingOne /30 block per client, with the server as the only peerOne pool mask shared by all clients
Effect of client-to-clientRequired for any peer trafficRequired for peer traffic, still no broadcast

Med net30 delar servern ut ett litet block per klient, så det finns ingen väg till en annan klients tunneladress om inte servern vidarebefordrar den. Med subnet är hela poolen ett nät, varje klient kan adressera varje annan och servern vidarebefordrar mellan dem. Därför kan en serverkonfiguration se frisk ut medan ping mellan parter misslyckas: ingenting är trasigt, klienterna är helt enkelt inte i ett nät. Klienten ser en fungerande länk och en partadress som inte svarar, vilket läses som en brandvägg men är en adresseringslayout.

Att byta direktivet är en redigering på serversidan plus en omstart, och den gäller nästa anslutning, inte sessioner som redan är uppe. Anslut klienterna igen innan du bedömer ändringen. Om en apparat återskapar konfigurationen från ett webbgränssnitt, anteckna direktivet, filen och datumet, och gör ändringen via gränssnittet när det finns, eftersom en återuppbyggnad skriver över en handredigering vid nästa sparning.

client-to-client är en egen port

Även inom ett subnät kastar servern paket som kommer från en klient och är adresserade till en annan, om inte client-to-client är satt. Det nyckelordet gör servern till en vidarebefordrare för parttrafik i stället för en slutpunkt som bara tar emot den. Det är det andra villkoret folk missar efter att ha rättat topologin.

Det sträcker sig inte till broadcast. Inställningen vidarebefordrar unicast mellan klienter; den gör inte tunneln till ett delat segment, och ingen mängd av den levererar en multicast-upptäcktsförfrågan till varje part.

TUN kontra TAP, och vad var och en kan bära

PropertyTUNTAP
LayerLayer 3, IP packetsLayer 2, Ethernet frames
Broadcast and multicastNot carriedCarried
Bridging to the LANNot applicableRequired for a shared segment
Client platform supportEverywhereMissing on Android and iOS, limited on macOS

Att brygga en tap-enhet in i LAN sätter fjärrklienter i kontorets broadcastdomän, vilket löser upptäckten helt. Priset är plattformarna som inte implementerar TAP, en brygga som måste finnas på servern, och en felddomän där en broadcaststorm på kontorskabeln når varje fjärrbärbar dator.

För två eller tre arbetsstationer som behöver namnmatchning är en hosts-post eller en unicast-adress mycket billigare än en brygga. Gripa efter TAP när ett protokoll du inte kan ersätta beror på upptäckt på lager 2, och inte tidigare.

Klienter i samma subnät utan brygga

Att tilldela en adress från LAN-området sätter inte klienten på kabeln. Servern routar mellan tunnel och Ethernet, så ARP för den adressen stannar vid serverns gränssnitt och resten av LAN får aldrig veta var den bor.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP stänger det gapet genom att låta servern svara i klientens ställe. För ett område hanterar parpd posterna när klienter kommer och går, medan sysctl net.ipv4.conf.eth0.proxy_arp=1 svarar för allt som routas någon annanstans, vilket är brett nog att skapa sina egna överraskningar på ett trafikerat segment.

Vilken väg du än väljer, ta bort NAT mellan tunneln och kabeln. En MASQUERADE-regel döljer precis den adresseringsfråga du försöker besvara. Den lämnar också nästa person med en topologi som hen inte kan resonera om från klientsidan.

Innan du ändrar något, fånga ett försök på servern med tcpdump -ni tun0 och bekräfta om partpaketet över huvud taget anländer. Att det anländer och kastas pekar på client-to-client; att det aldrig anländer pekar på topologi eller routing. OpenVPN 2.6-handboken dokumenterar båda nyckelorden och standardtopologin, vilket är värt att kontrollera mot din version innan du kopierar en rad från ett foruminlägg.

  • tun-gränssnittet visar en poolmask i stället för ett /30-partpar.
  • Ett direkt ping till den andra tunneladressen lyckas innan du testar upptäckt.
  • Serverkonfigurationen innehåller client-to-client närhelst parter måste utbyta paket.
  • Namnge upptäcktsprotokollet du testar i stället för att säga att appen misslyckas.
  • Använd TAP bara om varje klientplattform i gruppen stöder det.
  • Håll NAT utanför vägen mellan tunnel och LAN när nåbarhet inom samma subnät spelar roll.

Relaterade artiklar