OpenVPN LAN-adgang i stykker? Tjek zoner, ruter og returvej

Tunnelen rapporterer en vellykket forbindelse, routerens egen side indlæses, og drevmapping til en maskine bag den udløber stadig. Intet i den kombination er selvmodsigende: routeren svarer som sig selv, og at nå noget bag den er en anden beslutning, truffet et andet sted. Kør kontrollerne nedenfor i rækkefølge, og stop ved den første fejl, fordi hver af dem hviler på den foregående. Når alle fire består, ligger fejlen over tunnelen og ikke i den.

Hvilket filter ser en pakke på vej til LAN'et

En pakke adresseret til routeren forbruges lokalt; en pakke adresseret til en vært bag den skal videresendes, og firewalls vurderer de to tilfælde hver for sig. Tilladelse til at nå routeren siger derfor intet om tilladelse til at krydse den. Firmware, der skjuler sine regelsæt, implementerer stadig begge, normalt som en vælger med LAN, internettet eller begge. Hvis vælgeren udelader LAN'et, betyder ingen senere kontrol noget.

OpenWrt gør opdelingen inspicerbar, og forskellen er værd at læse én gang. Zonen, der afslutter tunnelen, skal have en videresendelsesregel rettet mod LAN-zonen, mens en inputregel kun styrer tjenester på routeren selv. En fungerende administrationsside ved siden af et dødt LAN er det sædvanlige resultat af den manglende videresendelsesregel.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Se på videresendelsesmålet for zonen, der bærer tunnelen: accept er det, trappen har brug for, og reject forklarer hver timeout nedenfor. To tilstødende indstillinger giver samme symptom, så udeluk dem, mens du er her. Trådløs isolering skjuler kablede værter for trådløse klienter, og en router, der behandler inaktive LAN-værter som offline, kan droppe svarene, selv efter at videresendelsen virker.

Hvorfor en splittet tunnel har brug for det push'ede præfiks

En klient, der sender al trafik gennem tunnelen, har allerede LAN-præfikset via sin standardrute, så der er intet at tilføje. En splittet tunnel er det tilfælde, der kræver, at præfikset angives eksplicit, fordi intet andet i konfigurationen nævner det. Føj direktivet til serverkonfigurationen, og genindlæs tjenesten.

push "route 192.168.50.0 255.255.255.0"

Profiler, der indeholder route-nopull ignorerer push'ede ruter, så samme præfiks hører i klientfilen i stedet. Bekræft under alle omstændigheder, at posten kom frem, i stedet for at antage det, fordi en tavs tilsidesættelse ser identisk ud med et firewallproblem.

ip route show | grep 192.168.50

En site-til-site-partner kræver mere end et push. Serveren skal lære, hvilke præfikser der ligger bag den partner, hvilket en iroute-linje i dens client-config-dir-fil gør, og dens egen tabel skal have en matchende rute ind i tunnelen.

Svaret har brug for en adresse, det kan nå

Videresendelse af anmodningen er kun halvdelen af en udveksling, fordi LAN-værten skal svare på en adresse i tunnelpuljen. Små routere klarer det normalt ved at oversætte kilden på tunnelzonen, så svaret er adresseret til routeren og kræver ingen konfiguration andre steder. Fjern den oversættelse, og værten skal have sin egen rute til puljen, som den får gratis, når routeren er dens standardgateway. En vært med håndsat adresse og en anden gateway svarer gennem den gateway i stedet, og klienten ser en session åbne og derefter gå i stå.

tcpdump -ni tun0 host 192.168.50.20

Kør det på routeren, mens klienten gentager sin anmodning, og læs svarets destination i stedet for anmodningen. Et svar adresseret til puljen betyder, at returvejen virker, og at fejlen er længere inde. Intet svar betyder, at værten aldrig accepterede pakken, hvilket sender dig tilbage til regelsættet.

En trappe, der ender det rigtige sted

Fire kontroller lokaliserer laget, og hver især er én kommando frem for en vurdering. Kør dem i rækkefølge, og stop ved den første fejl. Rækkefølgen betyder mere end kommandoerne, fordi et senere trin, der består, skjuler årsagen til, at et tidligere fejlede.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Navne hører til i slutningen af trappen, aldrig i begyndelsen. En delt mappe, der svarer som 192.168.50.20 men ikke som nas.local, peger på navneopløsning eller på et søge-suffiks, og firewall-ændringer kan ikke ændre nogen af dem.

Notér det første fejlede trin, og giv derefter tjenesteporte deres egen runde, fordi en lytter og en værtstilladelse er separate krav. Fildeling, fjernskrivebord og kamerastrømme kræver begge, og en vært-firewall, der stoler på LAN-subnettet men ikke tunnelpuljen, dropper klienten, mens ping stadig lykkes. Når alle kontroller består, og programmet stadig fejler, ligger fejlen over tunnelen: en tjeneste bundet til ét interface, eller en proxy konfigureret på klienten.