Verbonden met OpenVPN maar geen ping of SMB-share? Controleer drie poorten

De tunnel komt op, de client krijgt een adres, en niets op de verre LAN antwoordt. Ping faalt, de share opent niet, en het VPN-log ziet er schoon uit omdat de sessie vanuit zijn oogpunt gezond is. Tussen die sessie en een bestand op een server staan drie onafhankelijke poorten: het forwardingbeleid, de poorten die de dienst nodig heeft, en de naam die je in plaats van een adres typte.

Elke poort faalt met een ander symptoom, en alleen de eerste staat op de VPN-server.

Forwarding is een beleid op de FORWARD-keten

Het accepteren van de OpenVPN-listener gebeurt op INPUT, daarom kan de tunnel verbinden terwijl elk pakket richting de LAN wordt gedropt. Verkeer dat binnenkomt op tun0 en via de LAN-interface naar buiten gaat, passeert FORWARD, en een host met een standaard DROP-beleid daar gooit het stil weg. Controleer zowel de sysctl als de keten voordat je iets anders aanraakt: sysctl net.ipv4.ip_forward en iptables -L FORWARD -v -n.

Sta de richting toe die je bedoelt en de antwoorden die daarbij horen, bijvoorbeeld een accept-regel van de tunnelinterface naar de LAN-interface plus een stateful-regel voor established en related verkeer. Staat de LAN achter een andere router, dan heeft die router een route terug naar de clientpool nodig of source NAT op de VPN-server. Bevestig dat pad met één ping voordat je meer regels toevoegt, want een regel die niet bereikbaar is verschijnt nooit in een teller.

SMB heeft meer dan één poort nodig

Bestandendeling is niet één TCP 445-gesprek. Discovery gebruikt UDP 137 en 138, oudere NetBIOS-sessies gebruiken TCP 139, en moderne SMB-sessies gebruiken TCP 445. Een regel die alleen 445 opent, levert het frustrerende geval op waarin een toegewezen schijf werkt en het netwerk browsen niet, of andersom.

Grote overdrachten door een tunnel lopen ook tegen MSS-problemen aan die op een kapotte share lijken. Een SYN die de volledige segmentgrootte van de LAN aankondigt, wordt door de kleinere MTU van de tunnel gedropt, en de verbinding blijft hangen na de handshake. MSS-clamping op het forwardingpad, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, haalt dat soort stilstand weg. Controleer met een kopie van een paar megabyte in plaats van een mapweergave, want kleine antwoorden komen erdoor, ook wanneer grote overdrachten dat niet doen.

De tunneladapter komt binnen als een nieuw netwerkprofiel

Windows classificeert elke adapter in een netwerkprofiel, en een nieuwe tunneladapter belandt meestal in Public, waar de regels voor bestands- en printerdeling geblokkeerd zijn. Dat is een beslissing van de hostfirewall op de fileserver, geen routingprobleem op de VPN-server. Wijzig de categorie bewust met Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private nadat je hebt bevestigd dat het beleid het toestaat, want de categorie verandert ook welke inkomende regels gelden.

Hetzelfde profiel verklaart een ping die faalt terwijl TCP 445 slaagt: echo-verzoeken worden in Public standaard gedropt.

Namen steken niet vanzelf een gerouteerde tunnel over

NetBIOS-naamresolutie en lokale discovery leunen op broadcasts die een gerouteerde tunnel niet draagt. Het typen van de korte naam van de server faalt daarom terwijl het adres werkt, en de share lijkt kapot terwijl alleen de opzoeking kapot is. Voeg een DNS-record voor de server toe bij de resolver die de tunnel uitgeeft, of gebruik het adres in de snelkoppeling.

Als de uitrol nog van WINS afhangt, configureer het dan op de client in plaats van te hopen dat broadcastverkeer verschijnt. Test eerst op adres, zodat een naamfout niet voor een firewallfout wordt aangezien.

Test één laag tegelijk en lees de eerste fout

Werk omhoog: ping de tunnelgateway, ping een LAN-host op adres, open dan de dienstpoort met Test-NetConnection -ComputerName 10.8.0.5 -Port 445, en pas daarna authenticeer je op de share. De eerste stap die faalt is de laag die je moet repareren, en elke latere stap is ruis tot die slaagt. Een ping die antwoordt terwijl de poort dicht blijft wijst op de eigen firewall van de fileserver, terwijl een poort die opengaat ondanks stille pings wijst op ICMP-filtering. Schrijf de eerste falende stap op voordat je iets verandert, want een tweede wijziging verbergt het resultaat van de eerste.

Als de VPN-server niet de router van de LAN is, bevestig dan de retourroute op die router voordat je meer regels aan de server toevoegt. Zonder die route bereiken verzoeken de host en verlaten antwoorden via de standaardroute richting internet, wat vanaf de clientkant precies op een firewalldrop lijkt.

Houd het share-account in je notities gescheiden van de VPN-login, want een geslaagde tunnel zegt niets over bestandsrechten. SMB naar het internet blootstellen om een ontbrekende regel te omzeilen is geen oplossing.