OpenVPN-iga ühendatud, aga pingi ega SMB-jagamise vastust pole? Kontrolli kolme väravat

Tunnel tõuseb, klient saab aadressi ja kaugemas LAN-is ei vasta miski. Ping ebaõnnestub, jagamine ei avane ja VPN-i logi näeb puhas välja, sest selle vaatepunktist on sessioon terve. Selle sessiooni ja serveris oleva faili vahel on kolm sõltumatut väravat: edasisaatmise poliitika, teenusele vajalikud pordid ja nimi, mille sa aadressi asemel sisestasid.

Iga värav ebaõnnestub erineva sümptomiga ja ainult esimene on VPN-serveris.

Edasisaatmine on poliitika FORWARD-ahelas

OpenVPN-i kuulaja vastuvõtmine toimub INPUT-ahelas, seepärast saab tunnel ühenduda, samal ajal kui iga LAN-i suunatud pakett visatakse kõrvale. Liiklus, mis saabub tun0 kaudu ja väljub LAN-liidese kaudu, läbib FORWARD-i, ja vaikimisi DROP-poliitikaga host viskab selle seal vaikselt kõrvale. Enne millegi muu puudutamist kontrolli nii sysctl-i kui ka ahelat: sysctl net.ipv4.ip_forward ja iptables -L FORWARD -v -n.

Luba soovitud suund ja sellele kuuluvad vastused, näiteks accept-reegel tunneliliidesest LAN-liidesesse pluss stateful-reegel established ja related liikluse jaoks. Kui LAN asub teise ruuteri taga, vajab see ruuter tagasiteed kliendipooli või source NAT-i VPN-serveris. Kinnita see tee ühe pingiga enne uute reeglite lisamist, sest reegel, milleni ei saa jõuda, ei ilmu kunagi loendurisse.

SMB vajab rohkem kui ühte porti

Failijagamine ei ole üksainus TCP 445 vestlus. Avastamine kasutab UDP 137 ja 138, vanemad NetBIOS-sessioonid kasutavad TCP 139 ja kaasaegsed SMB-sessioonid kasutavad TCP 445. Reegel, mis avab ainult 445, tekitab masendava olukorra, kus kaardistatud ketas töötab ja võrgu sirvimine mitte, või vastupidi.

Suured ülekanded läbi tunneli tabavad ka MSS-probleeme, mis näevad välja nagu katkine jagamine. SYN, mis teatab LAN-i täis segmenti suuruse, visatakse tunneli väiksema MTU tõttu kõrvale, ja ühendus jääb pärast kätlemist rippuma. MSS-i piiramine edasisaatmise teel, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, kõrvaldab selle tõrke klassi. Kontrolli mõne megabaidi suuruse koopiaga, mitte kataloogi loendiga, sest väikesed vastused pääsevad läbi ka siis, kui suured ülekanded ei pääse.

Tunneliadapter saabub uue võrguprofiilina

Windows liigitab iga adapteri võrguprofiili, ja värske tunneliadapter maandub tavaliselt Public-profiili, kus faili- ja printerijagamise reeglid on blokeeritud. See on failiserveri host-tulemüüri otsus, mitte VPN-serveri marsruutimisprobleem. Muuda kategooriat teadlikult käsuga Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private pärast seda, kui oled kinnitanud, et poliitika seda lubab, sest kategooria muudab ka seda, millised sissetulevad reeglid kehtivad.

Sama profiil selgitab pingi, mis ebaõnnestub, samal ajal kui TCP 445 õnnestub: echo-päringud visatakse Public-profiilis vaikimisi kõrvale.

Nimed ei ületa marsruuditud tunnelit iseenesest

NetBIOS-i nimeotsing ja kohalik avastamine tuginevad saadetistele, mida marsruuditud tunnel ei kanna. Seetõttu ebaõnnestub serveri lühinime sisestamine, samal ajal kui selle aadress töötab, ja jagamine näeb katki välja, kui katki on ainult otsing. Lisa serveri jaoks DNS-kirje resolverisse, mille tunnel väljastab, või kasuta otseteel aadressi.

Kui juurutus sõltub endiselt WINS-ist, sea see kliendis sisse, selle asemel et loota saadetise liikluse ilmumist. Testi esmalt aadressiga, et nime tõrget ei aetaks segi tulemüüri tõrkega.

Testi ühte kihti korraga ja loe esimest tõrget

Liigu ülespoole: pingi tunneli lüüsi, pingi LAN-i hosti aadressi järgi, seejärel ava teenuse port käsuga Test-NetConnection -ComputerName 10.8.0.5 -Port 445, ja alles siis autendi end jagamise vastu. Esimene samm, mis ebaõnnestub, on kiht, mida parandada, ja iga järgnev samm on müra, kuni see läbib. Ping, mis vastab, samal ajal kui port jääb suletuks, osutab failiserveri enda tulemüürile, samal ajal kui port, mis avaneb vaatamata vaiksetele pingidele, osutab ICMP filtreerimisele. Kirjuta esimene ebaõnnestuv samm üles enne millegi muutmist, sest teine muudatus varjab esimese tulemuse.

Kui VPN-server ei ole LAN-i ruuter, kinnita tagasitee sellel ruuteril enne serverile uute reeglite lisamist. Ilma selleta jõuavad päringud hostini ja vastused väljuvad vaikimisi teekonda internetti, mis kliendi poolelt näeb täpselt välja nagu tulemüüri drop.

Hoia jagamise konto oma märkmetes VPN-i sisselogimisest eraldi, sest õnnestunud tunnel ei ütle failiõiguste kohta midagi. SMB avamine internetti, et puuduvast reeglist mööda minna, ei ole lahendus.