Yhdistetty OpenVPN:ään mutta ei pingiä eikä SMB-jakoa? Tarkista kolme porttia

Tunneli nousee, asiakas saa osoitteen, eikä mikään kauko-LANissa vastaa. Ping epäonnistuu, jako ei avaudu ja VPN-loki näyttää puhtaalta, koska sen näkökulmasta istunto on terve. Istunnon ja palvelimella olevan tiedoston välissä on kolme itsenäistä porttia: edelleenohjauskäytäntö, palvelun tarvitsemat portit ja nimi, jonka kirjoitit osoitteen sijaan.

Jokainen portti epäonnistuu eri oireella, ja vain ensimmäinen on VPN-palvelimella.

Edelleenohjaus on FORWARD-ketjun käytäntö

OpenVPN-kuuntelijan hyväksyminen tapahtuu INPUT-ketjussa, siksi tunneli voi yhdistyä, vaikka jokainen LANiin suunnattu paketti pudotetaan. Liikenne, joka saapuu tun0 kautta ja poistuu LAN-liitännän kautta, kulkee FORWARDin läpi, ja isäntä, jolla on oletusarvoinen DROP-käytäntö, hylkää sen siellä hiljaa. Tarkista sekä sysctl että ketju ennen kuin kosket mihinkään muuhun: sysctl net.ipv4.ip_forward ja iptables -L FORWARD -v -n.

Salli haluamasi suunta ja siihen kuuluvat vastaukset, esimerkiksi accept-sääntö tunneliliitännästä LAN-liitäntään sekä stateful-sääntö established- ja related-liikenteelle. Jos LAN on toisen reitittimen takana, se reititin tarvitsee paluureitin asiakaspooliin tai source NATin VPN-palvelimelle. Vahvista se polku yhdellä pingillä ennen uusien sääntöjen lisäämistä, sillä sääntö, johon ei pääse, ei koskaan näy laskurissa.

SMB tarvitsee enemmän kuin yhden portin

Tiedostojen jakaminen ei ole yksi TCP 445 -keskustelu. Löytäminen käyttää UDP:tä 137 ja 138, vanhemmat NetBIOS-istunnot käyttävät TCP:tä 139 ja nykyaikaiset SMB-istunnot käyttävät TCP:tä 445. Sääntö, joka avaa vain portin 445, tuottaa turhauttavan tapauksen, jossa yhdistetty asema toimii ja verkon selaus ei, tai päinvastoin.

Suuret siirrot tunnelin läpi kohtaavat myös MSS-ongelmia, jotka näyttävät rikkoutuneelta jaolta. SYN, joka ilmoittaa LANin täyden segmenttikoonsa, pudotetaan tunnelin pienemmän MTUn takia, ja yhteys jää jumiin kättelyn jälkeen. MSS:n rajoittaminen edelleenohjauspolulla, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, poistaa tämän pysähdystyypin. Vahvista muutaman megatavun kopiolla hakemistoluettelon sijaan, sillä pienet vastaukset menevät läpi, vaikka suuret siirrot eivät.

Tunnelisovitin saapuu uutena verkko-profiilina

Windows luokittelee jokaisen sovittimen verkko-profiiliin, ja tuore tunnelisovitin päätyy yleensä Public-profiiliin, jossa tiedosto- ja tulostinjakoa koskevat säännöt on estetty. Se on tiedostopalvelimen isäntäpalomuurin päätös, ei VPN-palvelimen reititysongelma. Muuta luokkaa tietoisesti komennolla Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private kun olet vahvistanut, että käytäntö sallii sen, sillä luokka muuttaa myös sitä, mitkä saapuvat säännöt ovat voimassa.

Sama profiili selittää pingin, joka epäonnistuu samalla kun TCP 445 onnistuu: kaikupolut pudotetaan Public-profiilissa oletusarvoisesti.

Nimet eivät ylitä reititettyä tunnelia itsestään

NetBIOS-nimien ratkaisu ja paikallinen löytäminen nojaavat lähetyksiin, joita reititetty tunneli ei kuljeta. Siksi palvelimen lyhytnimen kirjoittaminen epäonnistuu, vaikka sen osoite toimii, ja jako näyttää rikkoutuneelta, kun vain haku on rikki. Lisää palvelimelle DNS-tietue siihen ratkaisijaan, jonka tunneli jakaa, tai käytä osoitetta pikakuvakkeessa.

Jos käyttöönotto riippuu yhä WINSistä, määritä se asiakkaalle sen sijaan että toivoisit lähetysliikenteen ilmestyvän. Testaa ensin osoitteella, jotta nimivirhe ei sekoitu palomuurivirheeseen.

Testaa yksi kerros kerrallaan ja lue ensimmäinen virhe

Etene ylöspäin: pingaa tunnelin yhdyskäytävää, pingaa LAN-isäntää osoitteella, avaa sitten palvelun portti komennolla Test-NetConnection -ComputerName 10.8.0.5 -Port 445, ja vasta sitten todentaudu jakoon. Ensimmäinen epäonnistuva askel on korjattava kerros, ja jokainen myöhempi askel on kohinaa, kunnes se menee läpi. Ping, joka vastaa portin pysyessä suljettuna, viittaa tiedostopalvelimen omaan palomuuriin, kun taas portti, joka avautuu hiljaisista pingistä huolimatta, viittaa ICMP-suodatukseen. Kirjoita ensimmäinen epäonnistuva askel muistiin ennen kuin muutat mitään, sillä toinen muutos peittää ensimmäisen tuloksen.

Jos VPN-palvelin ei ole LANin reititin, vahvista paluureitti sillä reitittimellä ennen kuin lisäät palvelimelle lisää sääntöjä. Ilman sitä pyynnöt saavuttavat isännän ja vastaukset lähtevät oletusreittiä internetiin, mikä asiakkaan puolelta näyttää täsmälleen palomuurin pudotukselta.

Pidä jakotili muistiinpanoissasi erillään VPN-kirjautumisesta, sillä onnistunut tunneli ei kerro mitään tiedostojen käyttöoikeuksista. SMB:n altistaminen internetille puuttuvan säännön kiertämiseksi ei ole korjaus.