Met OpenVPN verbind maar geen ping of SMB-deel nie? Kontroleer drie hekke

Die tonnel kom op, die kliënt kry 'n adres, en niks op die verre LAN antwoord nie. Ping misluk, die deel maak nie oop nie, en die VPN-log lyk skoon omdat die sessie vanuit sy oogpunt gesond is. Drie onafhanklike hekke sit tussen daardie sessie en 'n lêer op 'n bediener: stuurbeleid, die poorte wat die diens nodig het, en die naam wat jy in plaas van 'n adres getik het.

Elke hek misluk met 'n ander simptoom, en net die eerste een is op die VPN-bediener.

Stuur is 'n beleid op die FORWARD-ketting

Die aanvaarding van die OpenVPN-luisteraar gebeur op INPUT, daarom kan die tonnel verbind terwyl elke pakkie na die LAN weggegooi word. Verkeer wat op tun0 aankom en op die LAN-koppelvlak vertrek, gaan deur FORWARD, en 'n gasheer met 'n verstek-DROP-beleid daar gooi dit stilweg weg. Kontroleer beide die sysctl en die ketting voordat jy iets anders aanraak: sysctl net.ipv4.ip_forward en iptables -L FORWARD -v -n.

Laat die rigting toe wat jy bedoel en die antwoorde wat daarby hoort, byvoorbeeld 'n aanvaardingsreël van die tonnelkoppelvlak na die LAN-koppelvlak plus 'n toestandsgebaseerde reël vir gevestigde en verwante verkeer. As die LAN agter 'n ander router sit, het daardie router 'n roete terug na die kliëntpoel nodig of 'n bron-NAT op die VPN-bediener. Bevestig daardie pad met 'n enkele ping voordat jy meer reëls byvoeg, want 'n reël wat nie bereik kan word nie, verskyn nooit in 'n teller nie.

SMB het meer as een poort nodig

Lêerdeling is nie 'n enkele TCP 445-gesprek nie. Ontdekking gebruik UDP 137 en 138, ouer NetBIOS-sessies gebruik TCP 139, en moderne SMB-sessies gebruik TCP 445. 'n Reël wat net 445 oopmaak, lewer die tergende geval waarin 'n gekoppelde skyf werk en netwerkblaai nie, of omgekeerd.

Groot oorplasings deur 'n tonnel kry ook MSS-probleme wat soos 'n stukkende deel lyk. 'n SYN wat die LAN se volle segmentgrootte adverteer, word deur die tonnel se kleiner MTU weggegooi, en die verbinding hang ná die handshake. Die vaspen van MSS op die stuurpad, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, verwyder daardie soort stalling. Verifieer met 'n kopie van 'n paar megagrepe eerder as 'n gidslys, want klein antwoorde pas deur selfs wanneer groot oorplasings nie.

Die tonneladapter kom as 'n nuwe netwerkprofiel

Windows klassifiseer elke adapter in 'n netwerkprofiel, en 'n nuwe tonneladapter beland gewoonlik in Public, waar reëls vir lêer- en drukkerdeling geblokkeer is. Dit is 'n gasheer-firewallbesluit op die lêerbediener, nie 'n roeteprobleem op die VPN-bediener nie. Verander die kategorie doelbewus met Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private nadat jy bevestig het die beleid laat dit toe, want die kategorie verander ook watter inkomende reëls geld.

Dieselfde profiel verduidelik 'n ping wat misluk terwyl TCP 445 slaag: eggo-versoeke word by verstek op Public weggegooi.

Name kruis nie vanself 'n gerouteerde tonnel nie

NetBIOS-naamresolusie en plaaslike ontdekking berus op uitsendings wat 'n gerouteerde tonnel nie dra nie. Om die bediener se kort naam te tik misluk dus terwyl sy adres werk, en die deel lyk stukkend terwyl net die opsoek dit is. Voeg 'n DNS-rekord vir die bediener by op die resolver wat die tonnel uitdeel, of gebruik die adres in die snelloop.

As die ontplooiing nog op WINS staatmaak, stel dit op die kliënt in eerder as om te hoop uitsaaiverkeer verskyn. Toets eers per adres sodat 'n naamfout nie vir 'n firewallfout aangesien word nie.

Toets een laag op 'n slag en lees die eerste fout

Werk opwaarts: ping die tonnelpoort, ping 'n LAN-gasheer per adres, maak dan die dienspoort oop met Test-NetConnection -ComputerName 10.8.0.5 -Port 445, en verifieer eers daarna by die deel. Die eerste stap wat misluk, is die laag om reg te maak, en elke latere stap is geraas tot dit slaag. 'n Ping wat antwoord terwyl die poort toe bly, wys na die lêerbediener se eie firewall, terwyl 'n poort wat oopgaan ondanks stil pings na ICMP-filtering wys. Skryf die eerste mislukte stap neer voordat jy iets verander, want 'n tweede verandering verberg die resultaat van die eerste.

As die VPN-bediener nie die LAN se router is nie, bevestig die terugroete op daardie router voordat jy meer reëls by die bediener voeg. Sonder dit bereik versoeke die gasheer en verlaat antwoorde die verstekroete na die internet, wat van die kliëntkant presies soos 'n firewall-wegGooi lyk.

Hou die deelrekening apart van die VPN-aanmelding in jou notas, want 'n suksesvolle tonnel sê niks oor lêertoestemmings nie. Om SMB aan die internet bloot te stel om 'n ontbrekende reël te omseil, is nie 'n oplossing nie.