Povezani z OpenVPN, a ni pinga ali souporabe SMB? Preverite tri vrata

Tunel se dvigne, odjemalec dobi naslov, in nič na oddaljenem omrežju LAN se ne odzove. Ping ne uspe, souporaba se ne odpre in dnevnik VPN je videti čist, ker je s svojega vidika seja zdrava. Med to sejo in datoteko na strežniku stojijo tri neodvisna vrata: politika posredovanja, vrata, ki jih storitev potrebuje, in ime, ki ste ga vnesli namesto naslova.

Vsaka vrata ne uspejo z drugačnim simptomom, in samo prva so na strežniku VPN.

Posredovanje je politika na verigi FORWARD

Sprejem poslušalca OpenVPN se zgodi na INPUT, zato se tunel lahko poveže, medtem ko se vsak paket proti omrežju LAN zavrže. Promet, ki pride na tun0 in odide skozi vmesnik LAN, gre skozi FORWARD, in gostitelj s privzeto politiko DROP ga tam tiho zavrže. Preden se dotaknete česar koli drugega, preverite sysctl in verigo: sysctl net.ipv4.ip_forward in iptables -L FORWARD -v -n.

Dovolite smer, ki jo želite, in odgovore, ki ji pripadajo, na primer pravilo accept z vmesnika tunela na vmesnik LAN ter pravilo stateful za promet established in related. Če je omrežje LAN za drugim usmerjevalnikom, ta usmerjevalnik potrebuje pot nazaj v sklop odjemalcev ali source NAT na strežniku VPN. To pot potrdite z enim samim pingom, preden dodate več pravil, ker se pravilo, do katerega ni mogoče priti, nikoli ne pojavi v števcu.

SMB potrebuje več kot ena vrata

Souporaba datotek ni en pogovor TCP 445. Odkrivanje uporablja UDP 137 in 138, starejše seje NetBIOS uporabljajo TCP 139, sodobne seje SMB pa uporabljajo TCP 445. Pravilo, ki odpre samo 445, ustvari nadležen primer, ko preslikan pogon deluje, brskanje po omrežju pa ne, ali obratno.

Veliki prenosi skozi tunel zadenejo tudi težave z MSS, ki so videti kot pokvarjena souporaba. SYN, ki naznani polno velikost segmenta omrežja LAN, se zavrže zaradi manjšega MTU tunela, in povezava po rokovanju obvisi. Omejevanje MSS na poti posredovanja, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, odstrani to vrsto zastoja. Preverite s kopijo nekaj megabajtov namesto s seznamom mape, ker majhni odgovori pridejo skozi, tudi ko veliki prenosi ne.

Vmesnik tunela pride kot nov omrežni profil

Windows vsak vmesnik razvrsti v omrežni profil, in nov vmesnik tunela običajno pristane v Public, kjer so pravila za souporabo datotek in tiskalnikov blokirana. To je odločitev gostiteljske požarne pregrade na datotečnem strežniku, ne težava usmerjanja na strežniku VPN. Kategorijo zavestno spremenite z Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private potem ko potrdite, da politika to dovoljuje, ker kategorija spremeni tudi, katera dohodna pravila veljajo.

Isti profil pojasni ping, ki ne uspe, medtem ko TCP 445 uspe: odmevne zahteve se v Public privzeto zavržejo.

Imena sama ne prečkajo usmerjenega tunela

Razreševanje imen NetBIOS in lokalno odkrivanje se zanašata na oddajanja, ki jih usmerjen tunel ne prenaša. Zato vnos kratkega imena strežnika ne uspe, medtem ko njegov naslov deluje, in souporaba je videti pokvarjena, ko je pokvarjeno samo iskanje. Dodajte zapis DNS za strežnik v razreševalniku, ki ga tunel dodeli, ali uporabite naslov v bližnjici.

Če se uvedba še vedno opira na WINS, ga nastavite na odjemalcu, namesto da bi upali, da se bo pojavil oddajni promet. Najprej preizkusite z naslovom, da se napaka imena ne zamenja z napako požarne pregrade.

Preizkusite eno plast naenkrat in preberite prvo napako

Napredujte navzgor: pingajte prehod tunela, pingajte gostitelja LAN po naslovu, nato odprite vrata storitve z Test-NetConnection -ComputerName 10.8.0.5 -Port 445, in šele nato se overite v souporabi. Prvi korak, ki ne uspe, je plast, ki jo je treba popraviti, in vsak naslednji korak je šum, dokler ta ne uspe. Ping, ki odgovori, medtem ko vrata ostanejo zaprta, kaže na lastno požarno pregrade datotečnega strežnika, medtem ko vrata, ki se odprejo kljub tihim pingom, kažejo na filtriranje ICMP. Zapišite prvi neuspešni korak, preden karkoli spremenite, ker druga sprememba skrije rezultat prve.

Če strežnik VPN ni usmerjevalnik omrežja LAN, potrdite povratno pot na tem usmerjevalniku preden strežniku dodate več pravil. Brez nje zahteve dosežejo gostitelja, odgovori pa odidejo po privzeti poti proti internetu, kar z odjemalčeve strani izgleda natanko kot zavrženje s požarno pregrado.

V svojih zapiskih imejte račun za souporabo ločen od prijave VPN, ker uspešen tunel ne pove ničesar o dovoljenjih za datoteke. Izpostavljanje SMB internetu, da bi se izognili manjkajočemu pravilu, ni rešitev.