Kopla til OpenVPN, men ingen ping eller SMB-deling? Sjekk tre portar

Tunnelen kjem opp, klienten får ei adresse, og ingenting på det fjerne LANet svarar. Ping sviktar, delinga opnar seg ikkje, og VPN-loggen ser rein ut fordi sesjonen frå synsstaden hans er sunn. Mellom den sesjonen og ei fil på ein tenar står tre uavhengige portar: videresendingspolitikken, portane tenesta treng, og namnet du skreiv i staden for ei adresse.

Kvar port sviktar med eit ulikt symptom, og berre den første ligg på VPN-tenaren.

Videresending er ein politikk på FORWARD-kjeda

Godkjenning av OpenVPN-lyttaren skjer på INPUT, difor kan tunnelen kopla til medan kvar pakke retta mot LANet blir droppa. Trafikk som kjem inn på tun0 og går ut via LAN-grensesnittet passerer FORWARD, og ein vert med standard DROP-politikk der kastar han stille. Sjekk både sysctl og kjeda før du rører noko anna: sysctl net.ipv4.ip_forward og iptables -L FORWARD -v -n.

Tillat retninga du vil ha og svara som høyrer til, til dømes ein accept-regel frå tunellgrensesnittet til LAN-grensesnittet pluss ein stateful regel for established og related trafikk. Om LANet ligg bak ein annan ruter, treng den ruteren ei rute tilbake til klientpoolen eller source NAT på VPN-tenaren. Stadfest den vegen med éin enkelt ping før du legg til fleire reglar, for ein regel som ikkje kan nåast dukkar aldri opp i ein teljar.

SMB treng meir enn éin port

Fildeling er ikkje éin enkelt TCP 445-samtale. Oppdaging brukar UDP 137 og 138, eldre NetBIOS-sesjonar brukar TCP 139, og moderne SMB-sesjonar brukar TCP 445. Ein regel som berre opnar 445 gjev det frustrerande tilfellet der ein tilkopla stasjon verkar og nettlesing av nettverket ikkje, eller omvendt.

Store overføringar over ein tunnel treff også MSS-problem som ser ut som ei øydelagd deling. Ein SYN som annonserer full segmentstorleik på LANet blir droppa av den mindre MTU-en til tunnelen, og sambandet heng etter handtrykket. MSS-klamping på videresendingsvegen, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, fjernar den typen stans. Stadfest med ein kopi på nokre få megabyte i staden for ei katalogliste, fordi små svar slepp gjennom sjølv når store overføringar ikkje gjer det.

Tunneladapteren kjem som ein ny nettverksprofil

Windows klassifiserer kvar adapter i ein nettverksprofil, og ein ny tunneladapter hamnar vanlegvis i Public, der reglane for fildeling og skrivardeling er blokkerte. Det er eit vedtak i brannmuren til verten på filtenaren, ikkje eit ruteproblem på VPN-tenaren. Endre kategorien med vilje med Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private etter at du har stadfesta at politikken tillèt det, fordi kategorien også endrar kva innkommande reglar som gjeld.

Same profil forklarer ein ping som sviktar medan TCP 445 lykkast: ekko-førespurnader blir droppa i Public som standard.

Namn kryssar ikkje ein ruta tunnel av seg sjølv

NetBIOS-namneoppslag og lokal oppdaging er avhengige av kringkasting som ein ruta tunnel ikkje ber. Difor sviktar det å skrive inn det korte namnet til tenaren medan adressa verkar, og delinga ser øydelagd ut når berre oppslaget er det. Legg til ein DNS-post for tenaren i resolvaren tunnelen deler ut, eller bruk adressa i snøggvegen.

Om utrullinga framleis er avhengig av WINS, konfigurer det på klienten i staden for å håpe at kringkastingstrafikk dukkar opp. Test først med adresse, så ein namnefeil ikkje blir forveksla med ein brannmurfeil.

Test eitt lag om gongen og les den første feilen

Arbeid deg oppover: ping gatewayen til tunnelen, ping ein LAN-vert med adresse, opne deretter tenesteporten med Test-NetConnection -ComputerName 10.8.0.5 -Port 445, og først då autentiser deg mot delinga. Det første trinnet som sviktar er laget som må rettast, og kvart seinare trinn er støy til det passerer. Ein ping som svarar medan porten blir verande lukka peikar på brannmuren til filtenaren sjølv, medan ein port som opnar seg trass stille ping peikar på ICMP-filtrering. Skriv ned det første feilande trinnet før du endrar noko, fordi ei anna endring skjuler resultatet av den første.

Om VPN-tenaren ikkje er ruteren til LANet, stadfest returruta på den ruteren før du legg til fleire reglar på tenaren. Utan henne når førespurnader verten, og svar forlet via standardruta mot internett, noko som frå klientsida ser nøyaktig ut som ein brannmur-drop.

Hald delingskontoen åtskild frå VPN-innlogginga i notata dine, sidan ein vellukka tunnel ikkje seier noko om filrettar. Å eksponere SMB mot internett for å unngå ein manglande regel er ikkje ei løysing.