OpenVPN-kliento por la tuta LAN ĉe OpenWrt: funkcianta ordo

Posedo de la interfaco, zona politiko, maskado kaj tabeloj por ĉiu SSID estas kvar apartaj taskoj. Faru ilin laŭorde kaj la tunelo por la tuta enkursigilo ĉesos batali kontraŭ vi.

Kvar sendependaj taskoj metas la tutan LAN de enkursigilo malantaŭ unu tunelon. La tunela aparato bezonas posedanton, fajroŝirman zonon, tradukan celon al la suprenligo kaj, se iuj klientoj devas resti ekster la VPN, enkursigon laŭ fonta adreso. Tunelo, kiu konektiĝas dum nenio trapasas, kutime mankas unu el tiuj kvar. Labori laŭ dependa ordo signifas, ke fiasko ĉe la fino apartenas al la paŝo, kiun vi ĵus ŝanĝis. Ĉiu paŝo malsupre finiĝas per io observebla, kaj tio gardas la sekvan kontraŭ esti konjekto.

Decidu, kio dividas la tunelon

La enkursigilo, kiu disdonas Wi-Fi kaj DHCP, povas mem ruli la klienton. Tio metas ĉiun alfiksitan aparaton malantaŭ la tunelon sen agordo por ĉiu aparato, kaj tio estas la aranĝo, kiun volas plej multaj malgrandaj ejoj. Ĝi ankaŭ estas tiu kun la plej vasta efiko, kiam la tunelo falas, ĉar ĉiuj aparatoj perdas sian vojon samtempe. Nenio en la LAN retenas funkciantan eliron.

Dua enkursigilo malantaŭ la unua, rulante la klienton kun propra subreto, limigas la tunelon al siaj propraj aparatoj. Ĝi estas pli facile forigebla kaj pli facile klarigebla al tiu, kiu ĝin heredas. La kosto estas atingeblo inter la du flankoj sen enkursiga vojo aŭ porda plusendo.

Ĉiel ajn, faru la LAN-subretojn malsamaj. Identaj gamoj igas unu flankon ŝajni rekte konektita, kaj la rezulta nigra truo aspektas kiel VPN-fiasko dum horoj.

Donu al la tunelo posedanton

Deklaru la tunelon kiel retinterfacon kun nomo, aparato kaj sen propra protokolo. La retsistemo tiam kreas kaj administras la aparaton, kaj ĉio malsupra referencas la interfacon per nomo anstataŭ per aparato. Tio ebligas al la zono trovi ĝin.

Ne kreu la saman aparaton en du lokoj. Mane farita tunelo apud deklarita interfaco produktas aparaton, kiu ekzistas sed ne estas en zono, aŭ unu, kiu malaperas ĉe reŝargo. Ambaŭ aspektas kiel fiasko de la kliento, kaj neniu produktas eraron, kiu nomas la veran kaŭzon. Elektu la deklaratan vojon kaj forigu la manan.

Tenu la nomon identa en la reta, fajroŝirma kaj VPN-agordo. La zono listigas retojn laŭ nomo, do tajperaro lasas la tunelon ekster ĉiu zono, dum la interfaco mem aspektas sana. Sana interfaco sen politiko estas la plej malfacile rimarkebla stato.

Metu ĝin en zonon, poste plusendu en ĝin

Fajroŝirma zono estas kie loĝas politiko: input, output, forward kaj masquerade. Tunelo en neniu zono estas regata de defaŭltoj, kiujn vi ne elektis, kaj tio malofte estas tio, kion bezonas enkursigila kliento. La blokoj malsupre deklaras la interfacon, metas ĝin en zonon kaj permesas LAN-trafikon en tiun zonon.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

En eldonoj pli malnovaj ol 21.02 la sama interfaca linio estas skribata option ifname, do kontrolu, kiun formon la instalita firmvaro analizas antaŭ ol alglui. La plusenda bloko estas la permeso, kiu entute lasas LAN-trafikon uzi la tunelon. Sen ĝi la aparato estas supre, la kliento konektita, kaj neniu LAN-gastiganto atingas la tunelon. Tio estas la plej ofta raporto konektita sed sen interreto ĉe enkursigilaj klientoj.

Masquerade en la VPN-zono kunpremas ĉiun LAN-adreson en la tunelan adreson de la enkursigilo antaŭ ol la paketo eliras. Tio forigas la bezonon de revena vojo al via subreto ĉe la malproksima flanko.

Se la malproksima flanko jam enkursigas vian LAN, malŝalti masquerade tenas fontajn adresojn videblaj kaj igas protokolojn por ĉiu kliento signifoplenaj. Elektu unu kaj skribu kiun, ĉar la du elektoj poste produktas malsamajn subtenajn demandojn. Forigi la defaŭltan plusendadon de LAN al WAN estas aparta decido kun propra sekvo. Forigu ĝin kaj la propra interreta aliro de la enkursigilo foriras kun ĝi.

Nomu la veran suprenligon en NAT

En firmvaro, kie la traduka regulo estas mane skribita, la elira interfaco estas la kampo, kiu eraras. Regulo nomanta vlan2 faras nenion, kiam la seanco finiĝas ĉe ppp0. Regulo tute sen interfaco povas traduki trafikon, kiu devintus resti privata. Neniu el la eraroj anoncas sin, ĉar la tunelo daŭre funkcias.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Anstataŭigu ppp0 en tiu regulo per la interfaco el ip route aŭ el la listo de funkciantaj interfacoj, poste rigardu la nombrilon dum LAN-gastiganto ŝargas paĝon. Ĉe enkursigilo kun unu provizanto, unu masquerade-regulo por la suprenligo kutime sufiĉas. Dua regulo por la tunela interfaco ne anstataŭas la unuan.

Poste aldonu la klientajn opciojn, kiuj decidas, kio eniras la tunelon. La direktivo redirect-gateway sendas la interretan trafikon de la kliento tra la VPN, kaj sen ĝi la tunelo portas nur la vojojn, kiujn la servilo puŝas. Kontrolu la rezultan enkursigan tabelon antaŭ ol tuŝi DNS.

Dividu la Wi-Fi per dua tabelo

Unu enkursiga tabelo ne povas teni du defaŭltojn. Dua SSID, kiu devas preterpasi la tunelon, do bezonas propran subreton kaj propran tabelon. Donu al la tuneligita SSID propran gamon, poste enkursigu nur tiun gamon en la tunelon per regulo, kiu elektas la tabelon.

Politik-bazitaj enkursigaj pakoj ĉe OpenWrt esprimas ĝuste tiun kombinaĵon. Mane ankaŭ eblas: per fonta regulo kaj tabelo, kies defaŭlto montras al la tunela aparato.

Kontrolu la dividon el ambaŭ retoj. Kliento ĉe la tuneligita SSID devus montri la eliran adreson de la VPN, kaj kliento ĉe la ordinara SSID tiun de la provizanto. Kiam ambaŭ aspektas samaj, la regulo trafas malĝustan fonton aŭ la tabelo neniam estas konsultata. Testu ankaŭ post rekonekto, ĉar regulo dependanta de la interfaca nomo rompiĝas, kiam la aparato renumeriĝas.

Suspektu la horloĝon kaj la aparatan flagon

La flago persist-tun lasas la tunelan aparaton surloke tra restartoj. Tio taŭgas por servilo kaj konfuzas klienton, kies stato devas esti rekonstruata de nulo. Forigu ĝin dum vi diagnozas enkursigilan klienton, ĉar aparato, kiu postvivas malsukcesan intertraktadon, kaŝas, kiu paŝo efektive rompiĝis. Remetu ĝin, kiam la kliento konektiĝas fidinde, kaj ne antaŭe.

La horloĝo estas la alia silenta fiasko. Enkursigilo sen bateria horloĝo komenciĝas ĉe la epoko, kio signifas, ke atestilaj kontroloj malsukcesas ĝis NTP atingos. Komparu la tempajn markojn de la protokolo kun la reala tempo antaŭ ol tuŝi atestilon, ĉar kliento, kiu konektiĝas minuton post lanĉo, kutime atendas tempan sinkronigon.

Rilataj artikoloj