Varför ditt LAN inte når en tjänst på en VPN-klient

En VPN-klient kan vara värd för en tjänst som LAN-et inte kan öppna. Det som oftast saknas är returvägen: en rutt, ett DNAT-par eller SNAT-raden som ingen lägger till.

Din tunnel är uppe, tjänsten lyssnar, och kontorets LAN får fortfarande ingenting tillbaka. Ingen har förstört VPN:en. Från LAN-sidan finns inte laptopens tunneladress förrän något berättar för LAN-et hur det ska nå den, och svaret måste komma tillbaka samma väg som begäran gick ut. Jag har sett folk bygga om en helt frisk tunnel tre gånger innan någon tittade på returvägen.

Det är inte tunneln som gick sönder

Båda ändarna sitter på privata intervall, vilket är det normala fallet och inte en felkonfiguration. En adress som 10.8.0.6 är verklig inne i tunneln och finns ingen annanstans, så LAN-et har ingen anledning att skicka något dit. Innan du rör routingen, bekräfta att tjänsten över huvud taget är nåbar inne i tunneln: på klienten visar ss -ltn om lyssnaren binder till 127.0.0.1, LAN-gränssnittet eller tunneladressen. En daemon som bara är bunden till loopback svarar ingen utom sig själv, och ingen rutt, DNAT eller portvidarebefordran ändrar det.

En proxy på port 80 eller 443 är ett annat verktyg med en annan synlighet. Den flyttar begäranden, inte paket, så den är fel lager för en rå databasanslutning, och att gripa efter den är hur det här problemet hamnar tre verktyg djupt innan någon mäter något.

Ruttform: berätta för LAN-et var poolen finns

En statisk rutt på LAN-gatewayen är det renaste svaret när LAN-et och tunnelpoolen inte överlappar. Peka poolen mot maskinen som avslutar tunneln:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Det reparerar bara en riktning, och därför ser halvfärdiga versioner av den här ändringen ut som framsteg. Tunnelsidan behöver den matchande halvan, annars lämnar svaret klienten via sin egen standardrutt och dör på vägen:

push "route 192.168.1.0 255.255.255.0"

För ett subnät som ligger bakom en klient i stället för bakom servern behöver servern både en systemrutt och en iroute-post i den klientens fil under client-config-dir. Utan iroute vet OpenVPN att prefixet finns och har ingen aning om vilken klient som äger det: paketen kommer in och daemonen har inget att matcha dem mot.

Här är myten som förtjänar ett namn. En rutt gör en adress nåbar; den gör inte andra sidan villig att svara. Site-till-site-partner lägger på ett lager till, eftersom den avlägsna gatewayen bara accepterar källor inom prefixen i sin policy, och en laptop som kommer från en hemmapool är inte inom dem.

NAT-form: DNAT in, och SNAT-raden som alla hoppar över

När du inte kan röra LAN-gatewayen, eller vill publicera exakt en port, fungerar översättning på VPN-värden utan någon rutt på LAN-et alls. Publicera porten, vidarebefordra den och översätt källan på vägen in i tunneln:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Den tredje raden är den som försvinner. Hoppa över den och klienten ser den ursprungliga LAN-adressen som källa, svarar via sin egen standardrutt, och det svaret går in i tunneln i stället för tillbaka mot LAN-et. Om anslutningen överlever beror då på routing du aldrig planerade. Med SNAT ser klienten serverns tunneladress, så svaret följer tunneln tillbaka till den enda värd som kan upphäva översättningen.

Konsumentfirmware använder sina egna kedjenamn och genererar inte den översättningen åt dig. På Tomato landar en inkommande regel i WANPREROUTING och sedan i en filterkedja som wanin, och en regeluppsättning som ser komplett ut behöver fortfarande en manuell POSTROUTING-rad. Det är inget firmwarefel; det är en regeluppsättning skriven bara för inkommande trafik.

Varför en regel som ser korrekt ut ändå släpper paketet

De flesta av dessa fel sitter inte i regeln du stirrar på. Kontrollera fyra saker i den här ordningen och stanna vid den första som inte håller:

  • Kedjeordning. iptables -I lägger in överst och -A lägger till sist, så en tidigare tillåtande eller blockerande regel avgör först.
  • Fel kedja. Trafik adresserad till routern själv passerar INPUT, och vidarebefordrad trafik rör den aldrig. Att publicera en tjänst kan kräva regler i båda.
  • Riktningsflaggor. -i tun0 matchar trafik som kommer från klienter och -o tun0 trafik som går mot dem. En REJECT med fel flagga blockerar något du inte menade.
  • Källbegränsning. En vidarebefordran som accepterar en klientadress fungerar från den klienten och släpper varje annan källa utan ett ord.

En regel med en paketräknare på noll är inte på vägen alls, och att läsa räknarna är det snabbaste sättet att skilja ett fel-kedja-problem från ett fel-regel-problem.

Den lokala vidarebefordran, när ingenting på LAN-et kan ändras

En lokal SSH-vidarebefordran kringgår hela frågan. Den behöver ingen rutt på LAN-et, inget samarbete från klientens brandvägg och ingen port publicerad någonstans:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Tjänsten dyker då upp på localhost:3000 på maskinen som håller tunneln, och ingen annanstans. Det är gränsen: en arbetsstation, en port, och vidarebefordran dör med sessionen om inte något startar om den. För en administratör som kontrollerar en staging-databas är det rätt verktyg. För en kamera eller en scanner som andra måste nå är det inte, eftersom varje användare skulle behöva sin egen vidarebefordran.

Kontrollera båda riktningarna innan du lägger till en regel till

Översättning lämnar spår, och att läsa dem slår att gissa. På VPN-värden visar conntrack -L om översättningen skedde alls, iptables -t nat -L -n -v visar om räknarna flyttade sig, och tcpdump -ni any port 3000 visar vilken källadress som faktiskt kom in. På klienten bekräftar ss -ltn att lyssnaren finns på en adress som tunneln kan nå.

Välj sedan den form du behåller. En publicerad port, en rutt för hela poolen och en vidarebefordran för en enda administratör är tre olika åtaganden, och att blanda dem är hur en fungerande uppsättning blir en som ingen kan förklara sex månader senare. Skriv ner vilken adress som är nåbar varifrån, och nästa person som felsöker detta börjar vid svaret i stället för vid tunneln.

Relaterade artiklar