VPN-klientoj atingas la servilon sed ne la LAN-on: kiu riparo?

La kliento pings la tunelan adreson de la OpenVPN-servilo kaj ricevas respondon, poste provas gastiganton en la LAN de la servilo kaj ricevas nenion. Tiu divido tre mallarĝigas la difekton: la tunelo staras, la plusendado verŝajne funkcias, kaj la respondo eliras tra pordo kiu ne kondukas reen. Ekzistas tri riparoj, kaj la ĝusta dependas de tio, kion vi regas kaj kion vi pretas forlasi. Respondu la tri demandojn sube laŭorde kaj la elekto ne plu estos afero de gusto.

Unue konfirmu, kiun direkton estas difektita

La peto alvenas al la tunela interfaco kun fonta adreso el la VPN-baseno. La servilo plusendas ĝin al gastiganto en la LAN, kaj tiu gastiganto respondas al la kluzo nomata de ĝia propra tabelo, kutime la enkursigilo de la LAN. Se la enkursigilo ne havas itineron al la baseno, la respondo mortas tie aŭ vagas direkte al la interreto.

Testu ambaŭ maŝinojn antaŭ ol ŝanĝi iun ajn. Demandu la enkursigan tabelon de la servilo kiel ĝi atingus klienton; demandu la gastiganton en la LAN kiel ĝi atingus la saman adreson. La unua serĉo kutime montras al la tunelo kaj la dua al la enkursigilo de la LAN, kaj tiu diferenco estas la difekto en unu linio. Du serĉoj malpli kostas ol fajroŝirma revizio kaj ili fiksas la direkton de la problemo.

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

Se la gastiganto en la LAN jam montras al la VPN-servilo, via problemo estas fajroŝirma regulo aŭ MTU-limo, ne mankanta revena vojo. Ne aldonu itineron por ripari filtrilon.

Unua demando: ĉu vi povas redakti la enkursigilon de la malproksima LAN?

Kiam la enkursigilo de la LAN estas via, la pura respondo estas ŝtata itinero al la VPN-baseno kun la LAN-adreso de la VPN-servilo kiel la sekva salto. Ĝi konservas la fontajn adresojn de la klientoj sendifektaj, kio gravas kiam gastigantoj en la LAN protokolas, filtras aŭ limigas la rapidon laŭ adreso. Ĝi ankaŭ ne bezonas tradukadon sur la servilo, do la tunelo restas pura enkursiga vojo. La devo kiun ĝi kreas estas dokumentado, ĉar la baseno, la itinero kaj la agordo de la servilo devas kongrui.

Ĝi malsukcesas silente en la tago kiam iu ŝanĝas la basenon. Notu la valoron unufoje kaj traktu ŝanĝon en iu ajn el la tri lokoj kiel ŝanĝon en ĉiuj tri.

NAS aŭ Layer 3 ŝaltilo kiu gastigas la servon bezonas la saman itineron, krom se ĝi sendas ĉion tra enkursigilo kiu havas ĝin. Kontrolu la aparaton kiu finas la subreton, ne nur tiun turnitan al la interreto. Malgrandaj retoj ofte havas tri aparatojn kun opinio pri enkursigado.

Dua demando: ĉu la LAN povas ĉesi vidi la adresojn de la klientoj?

Kiam la enkursigilo apartenas al iu alia, tradukado sur la VPN-servilo ne postulas kunlaboron. La gastiganto en la LAN vidas la LAN-adreson de la servilo, respondas al ĝi, kaj la servilo tradukas reen. Tial aparatoj kaj NAT-bazitaj roloj de fora aliro kondutas tiel.

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

La kosto estas atribuo: adresoj po kliento malaperas el la protokoloj de la LAN. Ĉiu permeslisto sur la gastiganto en la LAN tiam devas nomi la servilon anstataŭ la basenon.

Elektu tradukadon kiam kunlaboro ne haveblas, ne kiam ĝi estas nur maloportuna. Ĝi kaŝas la klienton de ĉiu estonta enketo, inkluzive de tiuj kie vi devas scii kiu tekkomputilo malfermis konekton. Ĝi ankaŭ povas rompi protokolojn kiuj enkorpigas adresojn en la ŝarĝon, ĉar la tradukado vivas en la kaplinio. Neniu opcio estas pli progresinta; ili respondas malsamajn demandojn pri proprieto.

Tria demando: ĉu la servilo mem estas kliento de alia tunelo?

Imagu la alian topologion: la VPN-servilo ankaŭ vokas komercan provizanton, do ĝi havas du tunelojn kaj du adresarojn. La trafiko kiun ĝi plusendas por siaj propraj klientoj eliras tra la provizanto, kaj tiu ne enkursigos respondojn reen al la basenaj adresoj. Tial respondoj malaperas kvankam ambaŭ tuneloj estas sanaj.

La riparo estas maski ankaŭ la eliran tunelon, por ke la provizanto vidu nur la tunelan adreson de la servilo. La kontraŭa direkto bezonas sian propran regulon, ĉar servilo kiu komencas konekton al unu el siaj propraj klientoj estas alia fluo. Sen tiu regulo la kliento respondas al adreso kiun ĝi ne povas enkursigi. Metu la mallarĝan regulon antaŭ ĉiu larĝa maskado por ke la specifa tradukado gajnu.

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

Gastigantoj kun pluraj interfacoj aldonas parencan difekton kiu aspektas identa de la klienta flanko. La respondo eliras tra la interfaco kun la pli malalta metriko ĉar la fonta adreso estis elektita el alia tabelo. Kontrolu la revenan vojon per serĉo anstataŭ supozi ke la antaŭa vojo implicas ĝin.

Poste kontrolu ambaŭ direktojn kaj ambaŭ grandojn

Post la ŝanĝo, pingu de la kliento al gastiganto en la LAN kaj poste de la gastiganto en la LAN al la kliento. La dua direkto estas tiu kiun homoj preterlasas, kaj ĝi estas tiu kiu malkaŝas nekompletan tradukan regulon. Notu ambaŭ rezultojn kun tempstampo por ke posta regreso estu komparebla.

Poste movu verajn datumojn, ĉar malgranda pingo kiu sukcesas dum granda transdono haltas estas MTU-simptomo. Tiu difekto aperas ĝuste post kiam vi gratulas vin pri la riparita itinero.

Fine, testu denove post restartigo. Itineraj kaj fajroŝirmaj komandoj dum funkciado ne postvivas ĝin, kaj riparo kiu malaperas ĉe la sekva ekfunkciigo estos diagnozita denove de iu kun malpli da kunteksto. Faru la ŝanĝon daŭra tiel kiel via sistemo jam faras, poste restartigu unufoje intence.