Koblet til OpenVPN, men ingen ping eller SMB-deling? Sjekk tre porter

Tunnelen kommer opp, klienten får en adresse, og ingenting på det fjerne LANet svarer. Ping feiler, delingen åpnes ikke, og VPN-loggen ser ren ut fordi sesjonen fra dens synspunkt er sunn. Mellom den sesjonen og en fil på en server står tre uavhengige porter: videresendingspolitikken, portene tjenesten trenger, og navnet du skrev i stedet for en adresse.

Hver port feiler med et ulikt symptom, og bare den første ligger på VPN-serveren.

Videresending er en politikk på FORWARD-kjeden

Godkjenning av OpenVPN-lytteren skjer på INPUT, derfor kan tunnelen koble til mens hver pakke rettet mot LANet droppes. Trafikk som kommer inn på tun0 og går ut via LAN-grensesnittet passerer FORWARD, og en vert med standard DROP-politikk der forkaster den stille. Sjekk både sysctl og kjeden før du rører noe annet: sysctl net.ipv4.ip_forward og iptables -L FORWARD -v -n.

Tillat retningen du vil ha og svarene som hører til, for eksempel en accept-regel fra tunellgrensesnittet til LAN-grensesnittet pluss en stateful regel for established og related trafikk. Hvis LANet ligger bak en annen ruter, trenger den ruteren en rute tilbake til klientpoolen eller source NAT på VPN-serveren. Bekreft den veien med én enkelt ping før du legger til flere regler, for en regel som ikke kan nås dukker aldri opp i en teller.

SMB trenger mer enn én port

Fildeling er ikke én enkelt TCP 445-samtale. Oppdagelse bruker UDP 137 og 138, eldre NetBIOS-sesjoner bruker TCP 139, og moderne SMB-sesjoner bruker TCP 445. En regel som bare åpner 445 gir det frustrerende tilfellet der en tilkoblet stasjon virker og nettlesing av nettverket ikke, eller omvendt.

Store overføringer over en tunnel treffer også MSS-problemer som ser ut som en ødelagt deling. En SYN som annonserer LANets fulle segmentstørrelse blir droppet av tunnelens mindre MTU, og forbindelsen henger etter håndtrykket. MSS-klamping på videresendingsveien, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, fjerner den typen stans. Verifiser med en kopi på noen få megabyte i stedet for en katalogliste, fordi små svar slipper gjennom selv når store overføringer ikke gjør det.

Tunneladapteren kommer som en ny nettverksprofil

Windows klassifiserer hver adapter i en nettverksprofil, og en ny tunneladapter havner vanligvis i Public, der reglene for fildeling og skriverdeling er blokkert. Det er en beslutning i vertens brannmur på filserveren, ikke et ruteproblem på VPN-serveren. Endre kategorien bevisst med Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private etter å ha bekreftet at politikken tillater det, fordi kategorien også endrer hvilke innkommende regler som gjelder.

Samme profil forklarer en ping som feiler mens TCP 445 lykkes: ekko-forespørsler droppes i Public som standard.

Navn krysser ikke en rutet tunnel av seg selv

NetBIOS-navneoppslag og lokal oppdagelse er avhengig av kringkasting som en rutet tunnel ikke bærer. Derfor feiler det å skrive inn det korte navnet til serveren mens adressen virker, og delingen ser ødelagt ut når bare oppslaget er det. Legg til en DNS-post for serveren i resolvertjenesten tunnelen deler ut, eller bruk adressen i snarveien.

Hvis utrullingen fortsatt avhenger av WINS, konfigurer det på klienten i stedet for å håpe at kringkastingstrafikk dukker opp. Test først med adresse, så en navnefeil ikke forveksles med en brannmurfeil.

Test ett lag om gangen og les den første feilen

Arbeid deg oppover: ping tunnelens gateway, ping en LAN-vert med adresse, åpne deretter tjenesteporten med Test-NetConnection -ComputerName 10.8.0.5 -Port 445, og først da autentiser deg mot delingen. Det første trinnet som feiler er laget som må rettes, og hvert senere trinn er støy til det passerer. En ping som svarer mens porten forblir lukket peker på filserverens egen brannmur, mens en port som åpnes tross stille ping peker på ICMP-filtrering. Skriv ned det første feilende trinnet før du endrer noe, fordi en annen endring skjuler resultatet av den første.

Hvis VPN-serveren ikke er LANets ruter, bekreft returruten på den ruteren før du legger til flere regler på serveren. Uten den når forespørsler verten, og svar forlater via standardruten mot internett, noe som fra klientsiden ser nøyaktig ut som en brannmur-drop.

Hold delingskontoen atskilt fra VPN-innloggingen i notatene dine, siden en vellykket tunnel ikke sier noe om filrettigheter. Å eksponere SMB mot internett for å unngå en manglende regel er ikke en løsning.