VPN-klientar når tenaren, men ikkje LAN-et: kva løysing?

Klienten pingar tunneladressa til OpenVPN-tenaren og får svar, prøver så ein vert i LAN-et til tenaren og får ingenting. Denne delinga snevrar feilen mykje inn: tunnelen er oppe, vidaresendinga verkar å fungere, og svaret går ut gjennom ei dør som ikkje fører attende. Det finst tre løysingar, og den rette kjem an på kva du styrer og kva du er viljug til å gje opp. Svar på dei tre spørsmåla nedanfor i rekkjefølgje, så er valet ikkje lenger ei smakssak.

Fyrst må du stadfeste kva retning som er broten

Førespurnaden kjem inn på tunneleininga med ei kjeldeadresse frå VPN-poolen. Tenaren sender han vidare til verten i LAN-et, og den verten svarar den gatewayen som den eiga tabella nemner, vanlegvis rutaren i LAN-et. Har rutaren inga rute til poolen, døyr svaret der eller flakkar mot internett.

Test begge maskinene før du endrar noka av dei. Spør tenaren kva veg rutetabellen hans ville ta til ein klient; spør verten i LAN-et korleis han ville nå same adressa. Det fyrste oppslaget peikar vanlegvis på tunnelen og det andre på rutaren i LAN-et, og den skilnaden er feilen på éi line. To oppslag er billegare enn ein brannmur-revisjon, og dei avgjer retninga på problemet.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Viser verten i LAN-et alt til VPN-tenaren, er problemet ditt ein brannmurregel eller ei MTU-grense og ikkje ein manglande returveg. Ikkje legg til ei rute for å rette eit filter.

Spørsmål ein: kan du endre rutaren i det fjerne LAN-et?

Når rutaren i LAN-et er din, er eit statisk rute til VPN-poolen med LAN-adressa til VPN-tenaren som neste hopp det reine svaret. Ho held kjeldeadressene til klientane intakte, noko som tel når vertar i LAN-et loggar, filtrerer eller avgrensar fart etter adresse. Ho krev heller ikkje omsetjing på tenaren, så tunnelen blir verande ein rein rutesti. Plikta ho skapar, er dokumentasjon, fordi poolen, ruta og tenarkonfigurasjonen må stemme overeins.

Ho sviktar stille den dagen nokon endrar poolen. Skriv ned verdien éin gong og handsam ei endring på eitt av dei tre stadene som ei endring på alle tre.

Ein NAS eller ein Layer 3-svitsj som er vert for tenesta treng same ruta, med mindre han sender alt gjennom ein rutar som har ho. Sjekk eininga som avsluttar subnettet, ikkje berre den som vender mot internett. Små nett har ofte tre einingar med meining om rutingsarbeidet.

Spørsmål to: kan LAN-et slutta å sjå klientadresser?

Når rutaren høyrer til nokon andre, krev omsetjing på VPN-tenaren ingen samarbeid. Verten i LAN-et ser LAN-adressa til tenaren, svarar henne, og tenaren omset attende. Difor oppfører apparat og NAT-baserte fjernåtkomstroller seg slik.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Prisen er tilskriving: adresser per klient forsvinn frå loggane i LAN-et. Kvar allowlist på verten i LAN-et må då namngje tenaren i staden for poolen.

Vel omsetjing når samarbeid ikkje er tilgjengeleg, ikkje når det berre er uhendig. Ho løyner klienten for kvar framtidig gransking, også dei der du må vita kva berbar datamaskin som opna ei tilknyting. Ho kan òg bryte protokollar som byggjer adresser inn i lasta, fordi omsetjinga bur i hovudet. Ingenting av alternativa er meir avansert; dei svarar på ulike spørsmål om eigarskap.

Spørsmål tre: er tenaren sjølv klient hos ein annan tunnel?

Sjå føre deg den andre topologien: VPN-tenaren ringjer òg ein kommersiell tilbydar, så han har to tunnelar og to sett adresser. Trafikken han sender vidare for sine eigne klientar, går ut gjennom tilbydaren, og den rutar ikkje svar attende til pooladressene. Difor forsvinn svara sjølv om begge tunnelane er friske.

Løysinga er å maskere den utgåande tunnelen òg, så tilbydaren berre ser tunneladressa til tenaren. Motsett retning treng si eiga regel, fordi tenaren som opnar ei tilknyting til ein av sine eigne klientar er ein annan straum. Utan den regelen svarar klienten ei adresse han ikkje kan rute. Set den tronge regelen før kvar brei maskering, så den spesifikke omsetjinga vinn.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Vertar med fleire grensesnitt legg til ein skyld feil som ser identisk ut frå klienten. Svaret går ut gjennom grensesnittet med lågare metrikk fordi kjeldeadressa vart vald frå ei anna tabell. Sjekk returvegen med eit oppslag i staden for å gå ut frå at vegen ut inneber han.

Deretter stadfest begge retningar og begge storleikar

Etter endringa, ping frå klienten til ein vert i LAN-et og så frå verten i LAN-et til klienten. Den andre retninga er den folk hoppar over, og ho er den som avdekkjer ein ufullstendig omsetjingsregel. Skriv ned begge resultata med tidsstempel, så ein seinare regresjon kan samanliknast.

Flytt så verkelege data, fordi ein liten ping som går gjennom medan ein stor overføring stoggar, er eit MTU-symptom. Den feilen dukkar opp rett etter at du har gratulert deg sjølv med å ha retta ruta.

Til slutt, test på nytt etter ein omstart. Rute- og brannmurkøyreordrer i drift overlever ikkje ein, og ei retting som forsvinn ved neste oppstart, blir diagnostisert på nytt av nokon med mindre samanheng. Gjer endringa varig slik systemet ditt alt gjer det, og start så om éin gong med vilje.