OpenVPN LAN-åtkomst trasig? Kontrollera zoner, rutter och returväg

Routern svarar för att den är lokal. För att nå en maskin bakom den krävs en vidarebefordringsregel, ett prefix på klienten och en väg tillbaka för svaret.

Tunneln rapporterar en lyckad anslutning, routerns egen sida laddas, och nätverksdisken till en maskin bakom den går fortfarande ut på tid. Inget i den kombinationen är motsägelsefullt: routern svarar som sig själv, och att något bakom den är ett annat beslut som fattas någon annanstans. Arbeta igenom kontrollerna nedan i ordning och stanna vid första felet, eftersom varje vilar på den föregående. När alla fyra passerar sitter felet ovanför tunneln och inte i den.

Vilket filter ser ett paket på väg till LAN-et

Ett paket adresserat till routern förbrukas lokalt; ett paket adresserat till en värd bakom den måste vidarebefordras, och brandväggar bedömer de två fallen separat. Tillstånd att nå routern säger därför ingenting om tillstånd att passera den. Firmware som döljer sina regeluppsättningar implementerar ändå båda, oftast som en väljare med LAN, internet eller båda. Om väljaren utelämnar LAN-et spelar ingen senare kontroll någon roll.

OpenWrt gör uppdelningen granskningsbar, och skillnaden är värd en genomläsning. Zonen som avslutar tunneln behöver en vidarebefordringsregel mot LAN-zonen, medan en ingångsregel bara styr tjänster på routern själv. En fungerande administratörssida bredvid ett dött LAN är det vanliga resultatet av den saknade vidarebefordringsregeln.

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

Titta på vidarebefordringsmålet för zonen som bär tunneln: accept är det stegen behöver, och reject förklarar varje tidsgräns nedanför. Två närliggande inställningar ger samma symptom, så uteslut dem medan du är här. Trådlös isolering döljer trådbundna värdar för trådlösa klienter, och en router som behandlar inaktiva LAN-värdar som offline kan släppa svaren även efter att vidarebefordringen fungerar.

Varför en delad tunnel behöver det pushade prefixet

En klient som skickar all trafik genom tunneln har redan LAN-prefixet via sin standardrutt, så det finns inget att lägga till. Den delade tunneln är fallet som kräver att prefixet anges uttryckligen, eftersom inget annat i konfigurationen nämner det. Lägg till direktivet i serverkonfigurationen och ladda om tjänsten.

push "route 192.168.50.0 255.255.255.0"

Profiler som innehåller route-nopull ignorerar pushade rutter, så samma prefix hör hemma i klientfilen i stället. Bekräfta hur som helst att posten kom fram i stället för att anta det, eftersom en tyst överskrivning ser identisk ut med ett brandväggsproblem.

ip route show | grep 192.168.50

En site-till-site-partner begär mer än en push. Servern måste lära sig vilka prefix som ligger bakom den partnern, vilket en iroute-rad i dess client-config-dir-fil gör, och dess egen tabell behöver en matchande rutt in i tunneln.

Svaret behöver en adress som det kan nå

Att vidarebefordra begäran är bara halva utbytet, eftersom LAN-värden måste svara på en adress i tunnelpoolen. Små routrar ordnar det vanligtvis genom att översätta källan på tunnelzonen, så svaret adresseras till routern och behöver ingen konfiguration någon annanstans. Ta bort den översättningen och värden behöver sin egen rutt till poolen, vilken den får gratis när routern är dess standardgateway. En värd med handinställd adress och en annan gateway svarar via den gatewayen i stället, och klienten ser en session öppnas och sedan stanna.

tcpdump -ni tun0 host 192.168.50.20

Kör detta på routern medan klienten upprepar sin begäran, och läs svarets destination i stället för begäran. Ett svar adresserat till poolen betyder att returvägen fungerar och att felet sitter längre in. Inget svar alls betyder att värden aldrig tog emot paketet, vilket skickar dig tillbaka till regeluppsättningen.

En stege som slutar på rätt ställe

Fyra kontroller lokaliserar lagret, och var och en är ett enda kommando i stället för en bedömning. Kör dem i ordning och stanna vid första felet. Ordningen betyder mer än kommandona, eftersom ett senare steg som passerar döljer orsaken till att ett tidigare misslyckades.

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

Namn hör hemma i slutet av stegen, aldrig i början. En delning som svarar som 192.168.50.20 men inte som nas.local pekar på namnuppslagning eller ett söksuffix, och brandväggsändringar kan inte ändra något av dem.

Notera det första steget som misslyckades och ge sedan tjänsteportarna sin egen runda, eftersom en lyssnare och ett värdtillstånd är separata krav. Fildelning, fjärrskrivbord och kameraströmmar behöver båda, och en värdbrandvägg som litar på LAN-subnätet men inte på tunnelpoolen släpper klienten medan ping fortfarande lyckas. När alla kontroller passerar och programmet ändå misslyckas sitter felet ovanför tunneln: en tjänst bunden till ett gränssnitt, eller en proxy konfigurerad på klienten.

Relaterade artiklar