VPN klientai pasiekia serverį, bet ne LAN tinklą: kuris sprendimas?

Klientas pingina OpenVPN serverio tunelio adresą ir gauna atsakymą, paskui bando mazgą serverio LAN tinkle ir nieko negauna. Šis skirtumas gerokai susiaurina gedimą: tunelis pakeltas, persiuntimas tikriausiai veikia, o atsakymas išeina pro duris, kurios neveda atgal. Yra trys sprendimai, o teisingas priklauso nuo to, ką kontroliuojate ir ko esate pasirengę atsisakyti. Atsakykite į tris klausimus žemiau iš eilės ir pasirinkimas nustos būti skonio reikalu.

Pirmiausia nustatykite, kuri kryptis sugedusi

Užklausa ateina į tunelio sąsają su šaltinio adresu iš VPN telkinio. Serveris persiunčia ją LAN tinklo mazgui, o tas mazgas atsako šliuzui, kurį nurodo jo paties lentelė, paprastai LAN tinklo maršrutizatoriui. Jei maršrutizatorius neturi maršruto į telkinį, atsakymas ten miršta arba klajoja link interneto.

Išbandykite abi mašinas prieš keisdami bet kurią. Paklauskite serverio, kokiu keliu jo lentelė pasiektų klientą; paklauskite LAN tinklo mazgo, kaip jis pasiektų tą patį adresą. Pirmoji paieška paprastai nurodo tunelį, o antroji LAN tinklo maršrutizatorių, ir tas skirtumas yra gedimas vienoje eilutėje. Dvi paieškos pigesnės už ugniasienės auditą ir nustato problemos kryptį.

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

Jei LAN tinklo mazgas jau rodo į VPN serverį, jūsų problema yra ugniasienės taisyklė arba MTU riba, o ne trūkstamas grįžimo kelias. Nepridėkite maršruto, kad sutvarkytumėte filtrą.

Pirmas klausimas: ar galite redaguoti tolimo LAN tinklo maršrutizatorių?

Kai LAN tinklo maršrutizatorius jūsų, švarus atsakymas yra statinis maršrutas į VPN telkinį su VPN serverio LAN adresu kaip kitu šuoliu. Jis išlaiko nepakitusius klientų šaltinio adresus, o tai svarbu, kai LAN tinklo mazgai registruoja, filtruoja ar riboja spartą pagal adresą. Jam taip pat nereikia vertimo serveryje, todėl tunelis lieka grynu maršrutizavimo keliu. Įsipareigojimas, kurį jis sukuria, yra dokumentacinis, nes telkinys, maršrutas ir serverio konfigūracija turi sutapti.

Jis tyliai nepavyksta tą dieną, kai kas nors pakeičia telkinį. Užsirašykite reikšmę vieną kartą ir traktuokite pakeitimą bet kurioje iš trijų vietų kaip visų trijų pakeitimą.

NAS arba Layer 3 komutatorius, kuriame talpinama paslauga, reikalauja to paties maršruto, nebent viską siunčia per maršrutizatorių, kuris jį turi. Patikrinkite įrenginį, kuris užbaigia potinklį, o ne tik tą, kuris atsuktas į internetą. Mažuose tinkluose dažnai yra trys įrenginiai, turintys nuomonę apie maršrutizavimą.

Antras klausimas: ar LAN tinklas gali nustoti matyti klientų adresus?

Kai maršrutizatorius priklauso kam nors kitam, vertimas VPN serveryje nereikalauja bendradarbiavimo. LAN tinklo mazgas mato serverio LAN adresą, atsako jam, o serveris išverčia atgal. Todėl įrenginiai ir nuotolinės prieigos vaidmenys, pagrįsti NAT, elgiasi būtent taip.

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

Kaina yra priskyrimas: adresai vienam klientui dingsta iš LAN tinklo žurnalų. Bet koks leidžiamų sąrašas LAN tinklo mazge tada turi nurodyti serverį, o ne telkinį.

Rinkitės vertimą, kai bendradarbiavimo nėra, o ne tada, kai jis tiesiog nepatogus. Jis paslepia klientą nuo kiekvieno būsimo tyrimo, įskaitant tuos, kur reikia žinoti, kuris nešiojamasis kompiuteris atidarė ryšį. Jis taip pat gali sugadinti protokolus, kurie įterpia adresus į naudingąją apkrovą, nes vertimas gyvena antraštėje. Nė viena parinktis nėra pažangesnė; jos atsako į skirtingus nuosavybės klausimus.

Trečias klausimas: ar pats serveris yra kito tunelio klientas?

Įsivaizduokite kitą topologiją: VPN serveris taip pat skambina komerciniam tiekėjui, todėl turi du tunelius ir du adresų rinkinius. Srautas, kurį jis persiunčia savo klientams, išeina per tiekėją, o tas nenukreips atsakymų atgal į telkinio adresus. Todėl atsakymai dingsta, nors abu tuneliai sveiki.

Sprendimas yra maskuoti ir išeinantį tunelį, kad tiekėjas matytų tik serverio tunelio adresą. Priešingai krypčiai reikia savo taisyklės, nes serveris, pradedantis ryšį su savo klientu, yra kitas srautas. Be šios taisyklės klientas atsako adresui, kurio negali maršrutizuoti. Padėkite siaurą taisyklę prieš bet kokį platų maskavimą, kad laimėtų konkretus vertimas.

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

Mazgai su keliais tinklo adapteriais prideda giminingą gedimą, kuris iš kliento pusės atrodo vienodai. Atsakymas išeina per sąsają su mažesne metrika, nes šaltinio adresas buvo pasirinktas iš kitos lentelės. Patikrinkite grįžimo kelią paieška, o ne manykite, kad ėjimo kelias jį implikuoja.

Tada patikrinkite abi kryptis ir abu dydžius

Po pakeitimo pinginkite nuo kliento iki LAN tinklo mazgo, o paskui nuo LAN tinklo mazgo iki kliento. Antroji kryptis yra ta, kurią žmonės praleidžia, ir ji atskleidžia nepilną vertimo taisyklę. Užrašykite abu rezultatus su laiko žyma, kad vėlesnė regresija būtų palyginama.

Tada perkelkite tikrus duomenis, nes mažas pingas, kuris pavyksta, kai didelis perdavimas stringa, yra MTU simptomas. Tas gedimas pasirodo iškart po to, kai pasveikinate save sutvarkę maršrutą.

Galiausiai patikrinkite iš naujo po perkrovimo. Maršrutų ir ugniasienės komandos veikimo metu to nepatiria, o pataisa, kuri dingsta kitą kartą paleidus, bus vėl diagnozuojama ko nors su mažesniu kontekstu. Padarykite pakeitimą nuolatiniu taip, kaip jūsų sistema jau daro, ir tada vieną kartą sąmoningai perkraukite.