Forbundet til OpenVPN, men ingen ping eller SMB-deling? Tjek tre porte

Tunnelen kommer op, klienten får en adresse, og intet på det fjerne LAN svarer. Ping fejler, delingen åbner ikke, og VPN-loggen ser ren ud, fordi sessionen fra dens synspunkt er sund. Tre uafhængige porte står mellem den session og en fil på en server: videresendelsespolitik, de porte tjenesten har brug for, og det navn du skrev i stedet for en adresse.

Hver port fejler med et forskelligt symptom, og kun den første ligger på VPN-serveren.

Videresendelse er en politik på FORWARD-kæden

Accept af OpenVPN-lytteren sker på INPUT, og derfor kan tunnelen forbinde, mens hver pakke rettet mod LAN’et droppes. Trafik, der ankommer på tun0 og forlader via LAN-interfacet, passerer FORWARD, og en vært med en standard-DROP-politik der kasserer den lydløst. Tjek både sysctl og kæden, før du rører noget andet: sysctl net.ipv4.ip_forward og iptables -L FORWARD -v -n.

Tillad den retning, du ønsker, og de svar, der hører til, for eksempel en accept-regel fra tunneinterfacet til LAN-interfacet plus en stateful regel for established og related trafik. Hvis LAN’et ligger bag en anden router, har den router brug for en rute tilbage til klientpoolen eller source NAT på VPN-serveren. Bekræft den vej med et enkelt ping, før du tilføjer flere regler, for en regel, der ikke kan nås, dukker aldrig op i en tæller.

SMB har brug for mere end én port

Fildeling er ikke én enkelt TCP 445-samtale. Opdagelse bruger UDP 137 og 138, ældre NetBIOS-sessioner bruger TCP 139, og moderne SMB-sessioner bruger TCP 445. En regel, der kun åbner 445, skaber det frustrerende tilfælde, hvor et tilknyttet drev virker, og gennemsyn af netværket ikke gør, eller omvendt.

Store overførsler over en tunnel rammer også MSS-problemer, der ligner en ødelagt deling. En SYN, der annoncerer LAN’ets fulde segmentstørrelse, droppes af tunnelens mindre MTU, og forbindelsen hænger efter håndtrykket. MSS-clamping på videresendelsesvejen, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, fjerner den slags stop. Kontroller med en kopi på nogle få megabyte i stedet for en mappeliste, fordi små svar slipper igennem, selv når store overførsler ikke gør.

Tunneladapteren ankommer som en ny netværksprofil

Windows klassificerer hvert adapter i en netværksprofil, og et nyt tunneladapter lander normalt i Public, hvor reglerne for fildeling og printersharing er blokeret. Det er en beslutning i værtens firewall på fileserveren, ikke et routingproblem på VPN-serveren. Skift kategorien bevidst med Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private efter at have bekræftet, at politikken tillader det, fordi kategorien også ændrer, hvilke indgående regler der gælder.

Den samme profil forklarer et ping, der fejler, mens TCP 445 lykkes: echo-anmodninger droppes som standard i Public.

Navne krydser ikke en routet tunnel af sig selv

NetBIOS-navneopløsning og lokal opdagelse afhænger af broadcast, som en routet tunnel ikke bærer. Derfor fejler et kortere servernavn, mens adressen virker, og delingen ser ødelagt ud, når det kun er opslaget, der er det. Tilføj en DNS-post for serveren på den resolver, tunnelen udleverer, eller brug adressen i genvejen.

Hvis udrulningen stadig afhænger af WINS, skal du konfigurere det på klienten i stedet for at håbe på broadcast-trafik. Test først med adresse, så en navnefejl ikke forveksles med en firewallfejl.

Test ét lag ad gangen og læs den første fejl

Arbejd opad: ping tunnelens gateway, ping en LAN-vært via adresse, åbn derefter tjenestens port med Test-NetConnection -ComputerName 10.8.0.5 -Port 445, og først derefter godkend dig til delingen. Det første trin, der fejler, er det lag, der skal rettes, og hvert senere trin er støj, indtil det passerer. Et ping, der svarer, mens porten forbliver lukket, peger på fileserverens egen firewall, mens en port, der åbner trods tavse ping, peger på ICMP-filtrering. Skriv det første fejlende trin ned, før du ændrer noget, fordi en anden ændring skjuler resultatet af den første.

Hvis VPN-serveren ikke er LAN’ets router, bekræft returruten på den router før du tilføjer flere regler på serveren. Uden den når anmodninger værten, og svar forlader via standardruten mod internettet, hvilket fra klientsiden ligner præcis et firewall-drop.

Hold delingskontoen adskilt fra VPN-loginet i dine noter, fordi en vellykket tunnel intet siger om filrettigheder. At eksponere SMB mod internettet for at omgå en manglende regel er ikke en løsning.