Ansluten till OpenVPN men ingen ping eller SMB-delning? Kontrollera tre portar

Tunneln kommer upp, klienten får en adress, och ingenting på det avlägsna LAN:et svarar. Ping misslyckas, delningen öppnas inte, och VPN-loggen ser ren ut eftersom sessionen från dess synvinkel är frisk. Mellan den sessionen och en fil på en server står tre oberoende portar: vidarebefordringspolicyn, portarna tjänsten behöver och namnet du skrev i stället för en adress.

Varje port misslyckas med olika symptom, och bara den första finns på VPN-servern.

Vidarebefordran är en policy på FORWARD-kedjan

Godkännandet av OpenVPN-lyssnaren sker på INPUT, därför kan tunneln ansluta medan varje paket riktat mot LAN:et släpps. Trafik som kommer in på tun0 och går ut via LAN-gränssnittet passerar FORWARD, och en värd med standardpolicyn DROP där kastar den tyst. Kontrollera både sysctl och kedjan innan du rör något annat: sysctl net.ipv4.ip_forward och iptables -L FORWARD -v -n.

Tillåt den riktning du vill ha och svaren som hör till, till exempel en accept-regel från tunnelgränssnittet till LAN-gränssnittet plus en stateful-regel för established och related trafik. Om LAN:et ligger bakom en annan router behöver den routern en väg tillbaka till klientpoolen eller source NAT på VPN-servern. Bekräfta den vägen med en enda ping innan du lägger till fler regler, för en regel som inte går att nå visas aldrig i en räknare.

SMB behöver mer än en port

Fildelning är inte ett enda TCP 445-samtal. Upptäckt använder UDP 137 och 138, äldre NetBIOS-sessioner använder TCP 139, och moderna SMB-sessioner använder TCP 445. En regel som bara öppnar 445 ger det frustrerande fallet där en mappad enhet fungerar och bläddring i nätverket inte, eller tvärtom.

Stora överföringar genom en tunnel drabbas också av MSS-problem som ser ut som en trasig delning. En SYN som annonserar LAN:ets fulla segmentstorlek släpps av tunnelns mindre MTU, och anslutningen hänger efter handskakningen. MSS-klampning på vidarebefordringsvägen, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, tar bort den typen av stopp. Verifiera med en kopia på några megabyte i stället för en kataloglista, eftersom små svar kommer igenom även när stora överföringar inte gör det.

Tunneladaptern kommer som en ny nätverksprofil

Windows klassar varje adapter i en nätverksprofil, och en ny tunneladapter hamnar oftast i Public, där reglerna för fil- och skrivardelning är blockerade. Det är ett beslut i värdens brandvägg på filservern, inte ett routingproblem på VPN-servern. Ändra kategorin medvetet med Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private efter att ha bekräftat att policyn tillåter det, eftersom kategorin också ändrar vilka inkommande regler som gäller.

Samma profil förklarar en ping som misslyckas medan TCP 445 lyckas: eko-begäranden släpps i Public som standard.

Namn korsar inte en routad tunnel av sig själva

NetBIOS-namnmatchning och lokal upptäckt bygger på utsändningar som en routad tunnel inte bär. Därför misslyckas det att skriva serverns korta namn medan adressen fungerar, och delningen ser trasig ut när bara uppslaget är det. Lägg till en DNS-post för servern i resolvern som tunneln delar ut, eller använd adressen i genvägen.

Om driftsättningen fortfarande är beroende av WINS, konfigurera det på klienten i stället för att hoppas att utsändningstrafik dyker upp. Testa först med adress, så att ett namnfel inte förväxlas med ett brandväggsfel.

Testa ett lager i taget och läs det första felet

Arbeta dig uppåt: pinga tunnelns gateway, pinga en LAN-värd med adress, öppna sedan tjänsteporten med Test-NetConnection -ComputerName 10.8.0.5 -Port 445, och autentisera dig först därefter mot delningen. Det första steget som misslyckas är lagret som ska åtgärdas, och varje senare steg är brus tills det passerar. En ping som svarar medan porten förblir stängd pekar på filserverns egen brandvägg, medan en port som öppnas trots tysta pingar pekar på ICMP-filtrering. Skriv ner det första misslyckade steget innan du ändrar något, eftersom en andra ändring döljer resultatet av den första.

Om VPN-servern inte är LAN:ets router, bekräfta returvägen på den routern innan du lägger till fler regler på servern. Utan den når förfrågningar värden och svar lämnar via standardvägen mot internet, vilket från klientsidan ser ut precis som en brandväggsdrop.

Håll delningskontot åtskilt från VPN-inloggningen i dina anteckningar, eftersom en lyckad tunnel inte säger något om filrättigheter. Att exponera SMB mot internet för att kringgå en saknad regel är ingen lösning.