Ferbûn mei OpenVPN mar gjin ping of SMB-dieling? Kontrolearje trije poarten

De tunnel komt op, de klant krijt in adres, en neat op it fiere LAN antwurdet. Ping mislearret, de dieling iepenet net, en it VPN-log sjocht der skjin út, om’t de sesje fan syn eachpunt út sûn is. Tusken dy sesje en in bestân op in server steane trije ûnôfhinklike poarten: it trochstjoerbelied, de poarten dy’t de tsjinst nedich hat, en de namme dy’tst yn plak fan in adres yntypst hast.

Elke poarte mislearret mei in oar symptoom, en allinnich de earste stiet op de VPN-server.

Trochstjoeren is in belied op de FORWARD-ketting

It akseptearjen fan de OpenVPN-listener bart op INPUT, dêrom kin de tunnel ferbine wylst elk pakket rjochting it LAN fuortsmitten wurdt. Ferkear dat oankomt op tun0 en ferlit fia de LAN-ynterface giet troch FORWARD, en in host mei in standert DROP-belied smyt it dêr stil fuort. Kontrolearje sawol de sysctl as de ketting foar’tst eat oars oanrekket: sysctl net.ipv4.ip_forward en iptables -L FORWARD -v -n.

Stean de rjochting ta dy’tst wolst en de antwurden dy’t dêrby hearre, bygelyks in accept-regel fan de tunnel-ynterface nei de LAN-ynterface plus in stateful-regel foar established en related ferkear. As it LAN efter in oare router sit, hat dy router in rûte werom nei de klantpoel nedich of source NAT op de VPN-server. Befêstigje dat paad mei ien ping foar’tst mear regels tafoegest, om’t in regel dy’t net berikt wurde kin nea yn in teller ferskynt.

SMB hat mear as ien poarte nedich

Bestânsdieling is net ien inkel TCP 445-petear. Untdekking brûkt UDP 137 en 138, âldere NetBIOS-sesjes brûke TCP 139, en moderne SMB-sesjes brûke TCP 445. In regel dy’t allinnich 445 iepenet makket it frustrearjende gefal wêryn’t in keppele skiif wurket en it sneupen troch it netwurk net, of oarsom.

Grutte oerdrachten oer in tunnel reitsje ek MSS-problemen dy’t op in stikken dieling lykje. In SYN dy’t de folsleine segmintgrutte fan it LAN oankundiget wurdt troch de lytsere MTU fan de tunnel fuortsmitten, en de ferbining hinget nei de hânskuteling. MSS beheine op it trochstjoerpaad, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, hellet dy klasse fan stilstand wei. Kontrolearje mei in kopy fan in pear megabyte yn plak fan in mapskerm, om’t lytse antwurden trochkomme sels as grutte oerdrachten dat net dogge.

De tunneladapter komt as in nij netwurkprofyl

Windows klassifisearret elk adapter yn in netwurkprofyl, en in nij tunneladapter lânet meast yn Public, wêr’t de regels foar bestâns- en printerdieling blokkearre binne. Dat is in beslút fan ’e host-firewall op de bestânsserver, gjin routingprobleem op de VPN-server. Feroarje de kategory bewust mei Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private nei’tst befêstige hast dat it belied it talit, om’t de kategory ek feroaret hokker ynkommende regels jilde.

Itselde profyl ferklearret in ping dy’t mislearret wylst TCP 445 slagget: echo-fersiken wurde op Public standert fuortsmitten.

Nammen geane net fansels oer in rûtearre tunnel

NetBIOS-namme-oplossing en lokale ûntdekking fertrouwe op útstjoerings dy’t in rûtearre tunnel net draacht. De koarte namme fan de server yntype mislearret dêrom wylst syn adres wurket, en de dieling sjocht der stikken út wylst allinnich it opfreegjen stikken is. Foegje in DNS-record foar de server ta op de resolver dy’t de tunnel jout, of brûk it adres yn ’e fluchkeppeling.

As de útrôl noch fan WINS ôfhinget, konfigurearje it dan op de klant yn plak fan te hoopjen dat útstjoerferkear ferskynt. Test earst op adres, sadat in namme-flater net foar in firewall-flater oansjoen wurdt.

Test ien laach tagelyk en lês de earste flater

Werkje omheech: ping de tunnelgateway, ping in LAN-host op adres, iepenje dan de tsjinstpoarte mei Test-NetConnection -ComputerName 10.8.0.5 -Port 445, en autentisearje dy pas dêrnei by de dieling. De earste stap dy’t mislearret is de laach om te reparearjen, en elke lettere stap is lûd oant dy foarby is. In ping dy’t antwurdet wylst de poarte ticht bliuwt wiist op ’e eigen firewall fan de bestânsserver, wylst in poarte dy’t iepenet nettsjinsteande stille pings wiist op ICMP-filters. Skriuw de earste mislearjende stap op foar’tst eat feroarest, om’t in twadde feroaring it resultaat fan ’e earste ferberget.

As de VPN-server net de router fan it LAN is, befêstigje de weromrûte op dy router foar’tst mear regels oan de server tafoegest. Sûnder dy berikke fersiken de host en ferlitte antwurden fia de standertrûte rjochting it ynternet, wat fan ’e klantkant krekt op in firewall-drop liket.

Hâld it dielingsaccount yn dyn notysjes los fan ’e VPN-oanmelding, om’t in slagge tunnel neat seit oer bestânsrjochten. SMB oan it ynternet bleatstelle om in ûntbrekkende regel te ûntwykjen is gjin oplossing.