Odjemalci VPN dosežejo strežnik, ne pa omrežja LAN: katera rešitev?

Odjemalec pinga naslov predora strežnika OpenVPN in dobi odgovor, nato poskusi gostitelja v omrežju LAN strežnika in ne dobi ničesar. Ta ločnica močno zoži napako: predor je vzpostavljen, posredovanje verjetno deluje, odgovor pa odhaja skozi vrata, ki ne vodijo nazaj. Obstajajo tri rešitve, prava pa je odvisna od tega, kaj nadzorujete in čemu ste pripravljeni odpovedati. Odgovorite na tri vprašanja spodaj po vrsti in izbira ni več stvar okusa.

Najprej ugotovite, katera smer je pokvarjena

Zahteva prispe na vmesnik predora z izvornim naslovom iz nabora VPN. Strežnik jo posreduje gostitelju v omrežju LAN, ta gostitelj pa odgovori prehodu, ki ga imenuje njegova lastna tabela, običajno usmerjevalniku omrežja LAN. Če usmerjevalnik nima poti v nabor, odgovor tam umre ali se klati proti internetu.

Preizkusite oba stroja, preden katerega koli spremenite. Vprašajte strežnik, po kateri poti bi njegova tabela dosegla odjemalca; vprašajte gostitelja v omrežju LAN, kako bi dosegel isti naslov. Prvo iskanje običajno pokaže na predor, drugo na usmerjevalnik omrežja LAN, in ta razlika je napaka v eni vrstici. Dve iskanji sta cenejši od revizije požarnega zidu in določita smer težave.

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

Če gostitelj v omrežju LAN že kaže na strežnik VPN, je težava pravilo požarnega zidu ali omejitev MTU, ne manjkajoča pot nazaj. Ne dodajajte poti, da bi popravili filter.

Prvo vprašanje: ali lahko urejate usmerjevalnik oddaljenega omrežja LAN?

Ko je usmerjevalnik omrežja LAN vaš, je čist odgovor statična pot v nabor VPN z naslovom LAN strežnika VPN kot naslednjim skokom. Ohranja nedotaknjene izvorne naslove odjemalcev, kar je pomembno, ko gostitelji v omrežju LAN beležijo, filtrirajo ali omejujejo hitrost po naslovu. Prav tako ne potrebuje prevajanja na strežniku, zato predor ostane čista usmerjevalna pot. Obveznost, ki jo ustvari, je dokumentacijska, ker se morajo nabor, pot in konfiguracija strežnika ujemati.

Tiho odpove na dan, ko nekdo spremeni nabor. Zapišite vrednost enkrat in obravnavajte spremembo na katerem koli od treh mest kot spremembo vseh treh.

NAS ali Layer 3 stikalo, ki gosti storitev, potrebuje isto pot, razen če vse pošilja skozi usmerjevalnik, ki jo ima. Preverite napravo, ki zaključuje podomrežje, ne le tiste, obrnjene proti internetu. Majhna omrežja imajo pogosto tri naprave z mnenjem o usmerjanju.

Drugo vprašanje: ali lahko omrežje LAN preneha videti naslove odjemalcev?

Ko usmerjevalnik pripada nekomu drugemu, prevajanje na strežniku VPN ne potrebuje sodelovanja. Gostitelj v omrežju LAN vidi naslov LAN strežnika, nanj odgovori in strežnik prevede nazaj. Zato se naprave in vloge oddaljenega dostopa, ki temeljijo na NAT, obnašajo tako.

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

Cena je pripisovanje: naslovi na odjemalca izginejo iz dnevnikov omrežja LAN. Vsak seznam dovoljenih na gostitelju v omrežju LAN mora takrat navesti strežnik namesto nabora.

Izberite prevajanje, ko sodelovanje ni na voljo, ne ko je le neprijetno. Odjemalca skrije pred vsako prihodnjo preiskavo, tudi tisto, kjer morate vedeti, kateri prenosnik je odprl povezavo. Lahko tudi pokvari protokole, ki vdelujejo naslove v koristni tovor, ker prevajanje živi v glavi. Nobena možnost ni naprednejša; odgovarjata na različni vprašanji o lastništvu.

Tretje vprašanje: ali je strežnik sam odjemalec drugega predora?

Zamislite si drugo topologijo: strežnik VPN kliče tudi komercialnega ponudnika, zato ima dva predora in dva nabora naslovov. Promet, ki ga posreduje za svoje odjemalce, odhaja skozi ponudnika, ta pa odgovorov ne bo usmeril nazaj na naslove nabora. Zato odgovori izginejo, čeprav sta oba predora zdrava.

Rešitev je maskiranje tudi odhodnega predora, da ponudnik vidi le naslov predora strežnika. Nasprotna smer potrebuje svoje pravilo, ker je strežnik, ki vzpostavi povezavo do lastnega odjemalca, drug tok. Brez tega pravila odjemalec odgovori na naslov, ki ga ne more usmeriti. Postavite ozko pravilo pred vsako široko maskiranje, da zmaga konkretni prevod.

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

Gostitelji z več vmesniki dodajo sorodno napako, ki je z vidika odjemalca videti enako. Odgovor odide skozi vmesnik z nižjo metriko, ker je bil izvorni naslov izbran iz druge tabele. Preverite povratno pot z iskanjem, namesto da predpostavljate, da jo pot naprej vsebuje.

Nato preverite obe smeri in obe velikosti

Po spremembi pingajte z odjemalca na gostitelja v omrežju LAN in nato z gostitelja v omrežju LAN na odjemalca. Druga smer je tista, ki jo ljudje preskočijo, in prav ta razkrije nepopolno pravilo prevajanja. Zabeležite oba rezultata s časovnim žigom, da bo poznejša regresija primerljiva.

Nato premaknite prave podatke, ker je majhen ping, ki uspe, medtem ko se velik prenos ustavi, simptom MTU. Ta napaka se pojavi takoj potem, ko si čestitate za popravljeno pot.

Nazadnje znova preizkusite po ponovnem zagonu. Ukazi za poti in požarni zid med delovanjem tega ne preživijo, popravek, ki izgine ob naslednjem zagonu, pa bo znova diagnosticiral nekdo z manj konteksta. Naredite spremembo trajno tako, kot to vaš sistem že počne, nato pa enkrat namerno znova zaženite.