Kvifor LAN-et ditt ikkje når ei teneste på ein VPN-klient

Tunnelen din er oppe, tenesta lyttar, og LAN-et på kontoret får framleis ingenting tilbake. Ingen har øydelagt VPN-en. Frå LAN-sida finst ikkje tunneladressa til laptoppen før noko fortel LAN-et korleis det skal nå ho, og svaret må kome tilbake same vegen som førespurnaden gjekk ut. Eg har sett folk byggje opp att ein heilt frisk tunnel tre gonger før nokon såg på returvegen.

Det er ikkje tunnelen som er øydelagd

Begge endar sit på private område, som er det normale tilfellet og ikkje ein feilkonfigurasjon. Ei adresse som 10.8.0.6 er ekte inne i tunnelen og finst ingen andre stader, så LAN-et har ingen grunn til å sende noko dit. Før du rører rutinga, stadfest at tenesta i det heile er tilgjengeleg inne i tunnelen: på klienten viser ss -ltn om lyttaren bind til 127.0.0.1, LAN-grensesnittet eller tunneladressa. Ein daemon som berre er bunden til loopback svarar ingen andre enn seg sjølv, og inga rute, DNAT eller portvideresending endrar det.

Ein proxy på port 80 eller 443 er eit anna verktøy med ei anna synlegheit. Han flyttar førespurnader, ikkje pakkar, så han er feil lag for ei rå databasekopling, og å gripe etter han er korleis dette problemet endar tre verktøy djupt før nokon måler noko.

Ruteform: fortel LAN-et kvar puljen ligg

Ei statisk rute på LAN-gatewayen er det reinaste svaret når LAN-et og tunnelpuljen ikkje overlappar. Peik puljen mot maskinen som avsluttar tunnelen:

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 reparerer berre éin retning, og difor ser halvferdige versjonar av denne endringa ut som framgang. Tunnelsida treng den tilsvarande halvdelen, elles forlèt svaret klienten via si eiga standardrute og døyr undervegs:

push "route 192.168.1.0 255.255.255.0"

For eit subnett som ligg bak éin klient i staden for bak serveren, treng serveren både ei systemrute og ei iroute-oppføring i fila til den klienten under client-config-dir. Utan iroute veit OpenVPN at prefikset finst, og har inga aning om kva klient som eig det: pakkane kjem inn, og daemonen har ingenting å matche dei mot.

Her er myten som fortener eit namn. Ei rute gjer ei adresse tilgjengeleg; ho gjer ikkje den andre sida viljug til å svare. Site-til-site-partnarar legg på eit lag til, fordi den eksterne gatewayen berre godtek kjelder innanfor prefiksa i policyen sin, og ein laptop som kjem frå ein heimepulje er ikkje innanfor dei.

NAT-form: DNAT inn, og SNAT-linja alle hoppar over

Når du ikkje kan røre LAN-gatewayen, eller du vil publisere nøyaktig éin port, fungerer omsetjing på VPN-verten utan noka rute på LAN-et i det heile. Publiser porten, videresend han, og omset kjelda på vegen inn i tunnelen:

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 linja er den som forsvinn. Hopp over henne, og klienten ser den opphavlege LAN-adressa som kjelde, svarar via si eiga standardrute, og det svaret går inn i tunnelen i staden for tilbake mot LAN-et. Om sambandet overlever avheng då av ruting du aldri planla. Med SNAT ser klienten tunneladressa til serveren, så svaret følgjer tunnelen tilbake til den einaste verten som kan oppheve omsetjinga.

Forbrukarfastvare brukar sine eigne kjedenamn og genererer ikkje den omsetjinga for deg. På Tomato landar ei innkommande regel i WANPREROUTING og deretter i ein filterkjede som wanin, og eit regelsett som ser komplett ut treng framleis ei manuell POSTROUTING-linje. Det er ikkje ein fastvarefeil; det er eit regelsett skrive berre for innkommande trafikk.

Kvifor ein regel som ser riktig ut likevel slepp pakken

Dei fleste av desse feila sit ikkje i regelen du stirrar på. Sjekk fire ting i denne rekkjefølgja, og stopp ved den første som ikkje held:

• Kjederekkjefølgja. iptables -I set inn øvst og -A legg til nedst, så ein tidlegare tillatande eller blokkerande regel avgjer først.
• Feil kjede. Trafikk adressert til ruteren sjølv går gjennom INPUT, og videresend trafikk rører henne aldri. Å publisere éi teneste kan krevje reglar i begge.
• Retningsflagg. -i tun0 matchar trafikk som kjem frå klientar, og -o tun0 trafikk som går mot dei. Ein REJECT med feil flagg blokkerer noko du ikkje meinte.
• Kjeldeavgrensing. Ei videresending som godtek éi klientadresse verkar frå den klienten og slepp kvar annan kjelde utan eit ord.

Ein regel med ein pakketeljar på null er ikkje på vegen i det heile, og å lese teljarane er den raskaste måten å skilje eit feil-kjede-problem frå eit feil-regel-problem.

Den lokale videresendinga, når ingenting på LAN-et kan endrast

Ei lokal SSH-videresending omgår heile spørsmålet. Ho treng inga rute på LAN-et, ikkje samarbeid frå brannmuren til klienten og ingen port publisert nokon stad:

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

Tenesta dukkar då opp på localhost:3000 på maskinen som held tunnelen, og ingen andre stader. Det er grensa: éin arbeidsstasjon, éin port, og videresendinga døyr med økta med mindre noko startar henne på nytt. For ein administrator som sjekkar ein staging-database er det rett verktøy. For eit kamera eller ein skannar som andre må nå, er det ikkje, fordi kvar brukar ville trengt si eiga videresending.

Stadfest begge retningar før du legg til ein ny regel

Omsetjing etterlèt spor, og å lese dei slår å gjette. På VPN-verten viser conntrack -L om omsetjinga skjedde i det heile, iptables -t nat -L -n -v viser om teljarane flytta seg, og tcpdump -ni any port 3000 viser kva kjeldadresse som faktisk kom inn. På klienten stadfester ss -ltn at lyttaren er på ei adresse tunnelen kan nå.

Vel så forma du behald. Éin publisert port, ei rute for heile puljen og ei videresending for éin administrator er tre ulike forpliktingar, og å blande dei er korleis eit oppsett som verkar blir eitt ingen kan forklare seks månader seinare. Skriv ned kva adresse som er tilgjengeleg kvarfrå, og neste person som feilsøkjer dette startar ved svaret i staden for ved tunnelen.