hostapd eta OpenVPN Pi bakarrean: nor da bide lehenetsiaren jabea?

hostapd eta OpenVPN bezero batek Pi bat parteka dezakete zubiak bere bide lehenetsia mantentzen badu eta tunelak bere zerbitzarirako bidea mantentzen badu. Komandoak eta itzultzea.

Telefonoak sarbide-puntuarekin elkartzen dira, helbide bat jasotzen dute eta gero ez dute ezer lortzen tunela altxatzen den unetik. hostapd normalean osasuntsu egoten da egoera horretan, eta OpenVPN ere bai; apurtzen dena bide lehenetsia da, eta hori edo ez zen inoiz zubian egon edo tunelak ordezkatu zuen VPN zerbitzarirako bidea utzi gabe. Eskuliburu honek bide hori bere tokian jartzen du eta emaitza bezero batetik frogatzen du, Pi-tik beharrean. Urrats bakoitza itzulgarria da, eta hemen ezerk ez du tunelaren konfigurazioa aldatzen, bertan zein trafiko nahi duzun jakin arte.

Zerrendatu interfazeak ezer editatu aurretik

Ohiko diseinuak haririk gabeko irratia eta kable portua br0 barruan jartzen ditu, hostapd zubiaren aurka abiarazten du eta dnsmasq-tik lizentziak banatzen ditu, OpenVPN bezero batek tun0 sortzen duen bitartean. Orduan hiru baldintza bereizik bat bezala ematen dute: sarbide-puntuko bezeroek Pi behar dute beren atebide gisa, Pi-k bide bat behar du internetera bere zerbitzaria lortzeko, eta zubiak bezero horiek erabil dezaketen atebide-helbide bat behar du.

Irakurri uneko egoera aldatu aurretik, lau komando hauek interfaze-arazo bat bideratze-arazo batetik bereizten baitute.

ip -br addr
ip route show
ip link show master br0
bridge link show

br0-k helbidea badu baina bide lehenetsirik ez, bezeroek Pi-ra iristen dira eta ez dute haratago ezer lortzen. Bide lehenetsia tun0-ra seinalatzen badu tunela behera dagoen bitartean, Pi-k ez du lan egiten duen biderik, eta bezeroaren sintomak berdin-berdin dirudi. Bi kasuak berdin ikusten dira telefono batetik, horregatik bide-taulak zuzenean irakurri behar dira.

Eman zubiari berea den bide lehenetsi bat

Raspberry Pi OS-k maiz uzten du zubia bide lehenetsirik gabe, zubia interfaze-fitxategia idatzi ondoren sortu bazen. Blokea /etc/dhcpcd.conf-n dago eta goiko routerra izendatu behar du, Pi ez ezik.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Adibide horretan 192.168.50.1 existitzen den routerra da eta 192.168.50.2 Pi-ren zubi-helbidea da azpisare berean, beraz jarri zure plan propioa zenbakiak kopiatu beharrean. Zubiaren kideek ere ez dute routerrik eskatu behar, bestela Pi-k lehiatutako bide lehenetsiak izango ditu, eta haien irabazlea metrikaren eta denboraren araberakoa izango da, asmoaren araberakoa beharrean.

systemctl restart dhcpcd ondoren ip route show default-k br0 behin zerrendatu behar du eta kable portutik bikoizturik ez. Egiaztatu bilaketa, taula ez, sarrera zaharkitu bat irabazle baten ondoan egon baitaiteke: ip -4 route get 203.0.113.10-k br0 izendatu behar du. Helbide hori TEST-NET-3 dokumentazio-barrutitik dator, beraz ezin du benetako zerbitzari batekin talkarik egin hau irakurtzen duzun bitartean.

Eragotzi tunelari bere zerbitzarirako bidea bahitzea

redirect-gateway onartzen duen OpenVPN bezero batek bide lehenetsia hartzen du eta tunelera zuzentzen du. Hori zuzena da sarbide-puntuko bezero guztiek VPN-a erabili behar dutenean, eta okerra helmuga batzuek bakarrik behar dutenean. Edonola ere, Pi-k zerbitzariarekiko duen konexio propioak ez du oraindik eraikitzen ari den tunelaren barruan bidaiatu behar. OpenVPN-k ostalari-bide bat gehitzen dio urrunekoari jatorrizko atebidearen bidez bide lehenetsia birbideratzen duenean, eta hori da hain zuzen garraioa bizirik mantentzen duen jokabidea; bide hori falta bada, tunela erori egiten da finkatzen den unetik.

Garraio-bide horren konparazio azkarra konektatu aurretik eta ondoren merezi ditu hamar segundoek. ip -4 route get 203.0.113.10-k azpiko gailua izendatu behar du bi egoeretan, metrika soilik aldatuta. Tunela altxatu ondoren tun0 izendatzen badu, ostalari-bidea ez zen inoiz instalatu eta hurrengo berrikonexioak huts egingo du.

Tunela aurrizki hautatuek bakarrik zeharkatu behar dutenean, erabili route-nopull eta gehitu nahi dituzun bideak eskuz, edo bota multzo estuagoa zerbitzaritik. Zubiak bide lehenetsia mantentzen du diseinu horretan, eta DNS hurrengo erabakia bihurtzen da: dnsmasq etxeko ebazpenera birbidaltzeak zentzua du han benetan bizi diren izenentzat soilik.

Erabaki birbidaltzearen eta NAT-aren kontua

Tunel osoak Pi-n gaitutako birbidaltzea behar du eta urruneko aldean sarbide-puntuko azpisarea bideratzeko prest dagoen atebide bat. Egiaztatu birbidaltzea beste edozer baino lehen, zero batek bide-aldaketa guztiak garrantzirik gabe uzten baititu.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

NAT araua zerbitzariak sarbide-puntuko aurrizkia onartuko ez duenean funtzionatzen duen lasterbidea da, kostua da bezero bakoitza Pi-ren tunel-helbide gisa agertzea urruneko aldeko erregistroetan. Aurrizkia NAT gabe bideratzeak helbideak ikusgai mantentzen ditu eta etxeko aldean 192.168.50.0/24-rako itzulera-bide baten mende dago.

Idatzi aukera suebakiaren arauen ondoan, diseinuan ikusezina den NAT araua azaldu ezina bihurtzen baita sei hilabete geroago. Mantendu IPv6 erabaki berean; funtzionatzen duen IPv4 bidea IPv6 bide hautsitik ondoan oraindik erdi hautsita irakurtzen da nabigatzailean.

Egiaztatu bezero batetik, gero itzuli garbi

Probatu ordena honetan sarbide-puntuko telefono edo eramangarri batetik: dnsmasq-tik lizentzia bat, zubiaren helbidera ping bat, gero tunelaren urruneko aldeko helmuga bat. Urrats bakoitzak geruza bat bakartzen du, huts alfer bakarra sortu beharrean.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Gero egiaztatu Pi-k oraindik baduela bere irteera: ip route get 203.0.113.10-k azpiko gailua izendatu behar du, eta ping -c 3 -I br0 203.0.113.10-k erantzun behar du zerbitzariak ICMP baimentzen badu. Lehen bi bezero-urratsek gainditzen badute eta hirugarrenak huts egiten badu, akatsa birbidaltzean edo NAT-en dago. Bigarren urratsak huts egiten badu, zubia edo DHCP osatu gabe daude oraindik.

Itzultzea fitxategi-editaketa bat eta bi komando dira: kendu blokea, berrabiarazi dhcpcd eta ordezkatu bide lehenetsia esplizituki ip route replace default via 192.168.50.1 dev br0-rekin. Egin hori mantenimendu-leihoa itxi aurretik, ez ondoren, bide lehenetsia galdu duen Pi bat konpontzeko erabiliko zenukeen saretik iristezina baita.

Erlazionatutako artikuluak