Të lidhur me OpenVPN por pa ping ose ndarje SMB? Kontrolloni tri porta

Tuneli ngrihet, klienti merr një adresë dhe asgjë në LAN-in e largët nuk përgjigjet. Ping-u dështon, ndarja nuk hapet dhe regjistri i VPN-së duket i pastër sepse nga këndvështrimi i tij sesioni është i shëndetshëm. Midis atij sesioni dhe një skedari në një server qëndrojnë tri porta të pavarura: politika e përcjelljes, portat që i nevojiten shërbimit dhe emri që shkruat në vend të një adrese.

Çdo portë dështon me një simptomë tjetër, dhe vetëm e para është në serverin VPN.

Përcjellja është një politikë në zinxhirin FORWARD

Pranimi i dëgjuesit të OpenVPN ndodh në INPUT, prandaj tuneli mund të lidhet ndërsa çdo paketë drejt LAN-it hidhet. Trafiku që vjen në tun0 dhe del përmes ndërfaqes LAN kalon nëpër FORWARD, dhe një host me politikë DROP të parazgjedhur atje e hedh në heshtje. Përpara se të prekni çdo gjë tjetër, kontrolloni si sysctl ashtu edhe zinxhirin: sysctl net.ipv4.ip_forward dhe iptables -L FORWARD -v -n.

Lejoni drejtimin që synoni dhe përgjigjet që i përkasin, për shembull një rregull accept nga ndërfaqja e tunelit në ndërfaqen LAN plus një rregull stateful për trafikun established dhe related. Nëse LAN-i ndodhet pas një routeri tjetër, ai router ka nevojë për një rrugë kthimi drejt grupit të klientëve ose source NAT në serverin VPN. Konfirmoni atë rrugë me një ping të vetëm përpara se të shtoni më shumë rregulla, sepse një rregull që nuk arrihet nuk shfaqet kurrë në numërues.

SMB ka nevojë për më shumë se një portë

Ndarja e skedarëve nuk është një bisedë e vetme TCP 445. Zbulimi përdor UDP 137 dhe 138, sesionet e vjetra NetBIOS përdorin TCP 139, dhe sesionet moderne SMB përdorin TCP 445. Një rregull që hap vetëm 445 krijon rastin e bezdisshëm ku një disk i montuar funksionon dhe shfletimi i rrjetit jo, ose e kundërta.

Transferimet e mëdha përmes një tuneli përballen gjithashtu me probleme MSS që duken si ndarje e prishur. Një SYN që shpall madhësinë e plotë të segmentit të LAN-it hidhet nga MTU më i vogël i tunelit, dhe lidhja mbetet e varur pas shtrëngimit të duarve. Kufizimi i MSS në rrugën e përcjelljes, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, e eliminon atë lloj bllokimi. Verifikoni me një kopje prej disa megabajtësh në vend të një liste drejtorie, sepse përgjigjet e vogla kalojnë edhe kur transferimet e mëdha nuk kalojnë.

Përshtatësi i tunelit vjen si një profil i ri rrjeti

Windows klasifikon çdo përshtatës në një profil rrjeti, dhe një përshtatës i ri tuneli zakonisht përfundon në Public, ku rregullat e ndarjes së skedarëve dhe printerëve janë të bllokuara. Ky është një vendim i firewall-it të hostit në serverin e skedarëve, jo një problem rrugëtimi në serverin VPN. Ndryshoni kategorinë me qëllim me Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private pasi të konfirmoni se politika e lejon, sepse kategoria ndryshon edhe cilat rregulla hyrëse zbatohen.

I njëjti profil shpjegon një ping që dështon ndërsa TCP 445 ka sukses: kërkesat e jehonës hidhen në Public si parazgjedhje.

Emrat nuk e kalojnë vetë një tunel të rrugëtuar

Zgjidhja e emrave NetBIOS dhe zbulimi lokal mbështeten në transmetime që një tunel i rrugëtuar nuk i mbart. Prandaj shkrimi i emrit të shkurtër të serverit dështon ndërsa adresa e tij funksionon, dhe ndarja duket e prishur kur është e prishur vetëm kërkimi. Shtoni një regjistrim DNS për serverin në zgjidhësin që jep tuneli, ose përdorni adresën në shkurtore.

Nëse vendosja varet ende nga WINS, konfiguroni atë në klient në vend që të shpresoni se do të shfaqet trafik transmetimi. Provoni fillimisht me adresë, që një dështim emri të mos ngatërrohet me një dështim firewall-i.

Provoni një shtresë në një herë dhe lexoni dështimin e parë

Ecni lart: bëni ping në portën e tunelit, bëni ping në një host të LAN-it me adresë, pastaj hapni portën e shërbimit me Test-NetConnection -ComputerName 10.8.0.5 -Port 445, dhe vetëm atëherë vërtetoni identitetin në ndarje. Hapi i parë që dështon është shtresa që duhet rregulluar, dhe çdo hap pas tij është zhurmë derisa ai të kalojë. Një ping që përgjigjet ndërsa porta mbetet e mbyllur tregon firewall-in e vetë serverit të skedarëve, ndërsa një portë që hapet pavarësisht ping-ve të heshtura tregon filtrimin ICMP. Shkruani hapin e parë që dështon përpara se të ndryshoni ndonjë gjë, sepse ndryshimi i dytë fsheh rezultatin e të parit.

Nëse serveri VPN nuk është routeri i LAN-it, konfirmoni rrugën e kthimit në atë router përpara se të shtoni më shumë rregulla në server. Pa të, kërkesat arrijnë te hosti dhe përgjigjet dalin përmes rrugës së parazgjedhur drejt internetit, gjë që nga ana e klientit duket saktësisht si hedhje nga firewall-i.

Mbani llogarinë e ndarjes të ndarë nga hyrja në VPN në shënimet tuaja, sepse një tunel i suksesshëm nuk thotë asgjë për lejet e skedarëve. Ekspozimi i SMB-së në internet për të anashkaluar një rregull që mungon nuk është zgjidhje.