OpenVPN-clients zien elkaar niet: subnet of net30?

Twee losse fouten geven dezelfde klacht. Bij de eerste bereikt de ene client de andere niet eens via het tunneladres, omdat de adressen niet in één subnet zitten of de server verkeer tussen peers niet doorstuurt. Bij de tweede werkt ping wel, maar blijft de apparatenlijst van de app leeg, omdat ontdekking afhangt van broadcast die een tunnel op laag 3 niet kan dragen. Eén ping scheidt ze, en de oplossing voor de een lijkt totaal niet op die voor de ander.

Eén ping splitst het probleem in twee

Ping vanaf de ene client het tunneladres van de andere, niet de naam en niet het LAN-adres. Mislukt dat, dan is doorsturen of adressering het probleem en is ontdekking irrelevant tot dat is opgelost. Lukt het, dan werkt doorsturen al en is wat ontbreekt broadcast of naamresolutie.

ip addr show tun0

Lees eerst de interface van de client, want het netmasker benoemt de topologie. Een /24 of een ander subnetmasker betekent een gedeelde pool; een /30 met een peeradres betekent de oudere punt-tot-punt-indeling, waarbij elke client precies één buur heeft, de server.

net30 tegenover subnet, gelezen vanaf de clientkant

Met net30 deelt de server een klein blok per client uit, dus er bestaat geen route naar het tunneladres van een andere client tenzij de server die doorstuurt. Met subnet is de hele pool één netwerk, kan elke client elke andere aanspreken en stuurt de server tussen hen door. Daarom kan één serverconfiguratie gezond lijken terwijl pings tussen peers mislukken: niets is stuk, de clients zitten simpelweg niet in één netwerk. De client ziet een werkende verbinding en een peeradres dat niet antwoordt, wat klinkt als een firewall maar een adresseringsindeling is.

De richtlijn omzetten is een aanpassing aan de serverkant plus een herstart, en die geldt voor de volgende verbinding, niet voor sessies die al open zijn. Verbind de clients opnieuw voordat u de wijziging beoordeelt. Als een apparaat de configuratie opnieuw genereert vanuit een webinterface, noteer dan de richtlijn, het bestand en de datum, en maak de aanpassing via de interface wanneer die er is, want een herbouw overschrijft een handmatige aanpassing bij de volgende opslag.

client-to-client is een aparte poort

Zelfs binnen één subnet gooit de server pakketten weg die van de ene client komen en aan een andere zijn geadresseerd, tenzij client-to-client is ingesteld. Dat sleutelwoord maakt de server een doorgever voor verkeer tussen peers in plaats van een eindpunt dat het alleen aanneemt. Het is de tweede voorwaarde die mensen missen nadat ze de topologie hebben hersteld.

Dat strekt zich niet uit tot broadcast. De instelling stuurt unicast tussen clients door; ze maakt de tunnel geen gedeeld segment, en geen enkele hoeveelheid ervan levert een multicast-ontdekkingsvraag bij elke peer af.

TUN tegenover TAP, en wat elk kan dragen

Een tap-apparaat in het LAN bruggen zet externe clients in het broadcastdomein van het kantoor, wat ontdekking volledig oplost. De prijs zijn de platformen die TAP niet implementeren, een brug die op de server moet bestaan, en een foutdomein waarin een broadcaststorm op de kantoorbekabeling elke externe laptop bereikt.

Voor twee of drie werkstations die naamresolutie nodig hebben, is een hosts-regel of een unicastadres veel goedkoper dan een brug. Kies TAP wanneer een protocol dat u niet kunt vervangen afhankelijk is van ontdekking op laag 2, en niet eerder.

Clients in hetzelfde subnet zonder brug

Een adres uit het LAN-bereik toewijzen zet de client niet op de kabel. De server routeert tussen tunnel en Ethernet, dus ARP voor dat adres stopt bij de interface van de server en de rest van het LAN leert nooit waar het woont.

ip neigh add proxy 10.50.1.250 dev eth0

Proxy ARP dicht die kloof door de server namens de client te laten antwoorden. Voor een bereik beheert parpd de regels terwijl clients komen en gaan, terwijl de sysctl net.ipv4.conf.eth0.proxy_arp=1 antwoordt voor alles wat elders wordt gerouteerd, wat breed genoeg is om op een druk segment zijn eigen verrassingen te scheppen.

Welke weg u ook kiest, haal NAT tussen de tunnel en de kabel weg. Een MASQUERADE-regel verbergt precies de adresseringsvraag die u probeert te beantwoorden. Ze laat de volgende persoon ook achter met een topologie waarover hij vanaf de clientkant niet kan redeneren.

Voordat u iets wijzigt, vang één poging op de server op met tcpdump -ni tun0 en bevestig of het peerpakket überhaupt aankomt. Aankomen en weggegooid worden wijst op client-to-client; nooit aankomen wijst op topologie of routering. De OpenVPN 2.6-handleiding documenteert beide sleutelwoorden en de standaardtopologie, wat het waard is om tegen uw versie te controleren voordat u een regel uit een forumpost kopieert.

• De tun-interface toont een poolmasker in plaats van een /30-peerpaar.
• Een directe ping naar het andere tunneladres slaagt voordat u ontdekking test.
• De serverconfiguratie bevat client-to-client wanneer peers pakketten moeten uitwisselen.
• Benoem het ontdekkingsprotocol dat u test in plaats van te zeggen dat de app faalt.
• Gebruik TAP alleen als elk clientplatform in de groep het ondersteunt.
• Houd NAT buiten het pad tussen tunnel en LAN wanneer bereikbaarheid binnen hetzelfde subnet telt.