OpenVPN bezeroak zerbitzarira iristen da, baina ez LANeko ostalarietara: kontrol-zerrenda

Bezeroak konektatuta dagoela dio, tuneleko helbideak ping bati erantzuten dio, eta bulegoko LANeko ezerk ez du erantzuten. Hori ia bezeroaren eguneraketa bakoitzaren ondoren ikusten dut, eta lehen sena suebakia irekitzea da, normalean mugimendu okerra: tunela ondo dago, eta haustura paketeak igaro behar duen hiru jauzietako batean dago. Egin bidea paketeak hartzen duen ordenan, lehenik bezeroaren bidea, gero zerbitzariaren birbidalketa, gero itzulerako bidaia, eta hutsegitearen jabea pare bat minututan aurkituko duzu.

Lehen urratsa: bezeroaren bideratze-erabakia behatu

Zerbitzaria ukitu aurretik, frogatu bezeroak paketea tunelera bidaltzen duela. Galdetu kernelari zein interfaze erabiliko lukeen LANeko ostalari zehatz batentzat, taula osoa irakurtzen ibili beharrean:

ip route get 192.168.50.10

Erantzunak zure adaptagailu fisikoa eta bulegoko atebidea aipatzen baditu, zerbitzariaren aldeko aldaketak ezin du ezer konpondu. OpenVPN(e)k bideak banatzen ditu zerbitzariak bultzatzen dituenean soilik, beraz bilatu push "route 192.168.50.0 255.255.255.0" zerbitzariaren konfigurazioan, eta gero konektatu bezeroa berriro. Bezero gehienek bultzatutako bideak konektatzean aplikatzen dituzte, ez profila berriz kargatzean.

Windowsen galdera berak beste komando bat du. Find-NetRoute -RemoteIPAddress 192.168.50.10(e)k interfazea eta pilak aukeratuko lukeen hurrengo jauzia inprimatzen ditu, eta route print -4(e)k bultzatutako aurrizkia existitzen den erakusten du.

Bigarren urratsa: berretsi zerbitzariak paketea birbidaliko duela

Bezeroaren bidea zuzena bada, paketea zerbitzarira iristen da, eta zerbitzariak onartu behar du birbidaltzea. Kernelaren etengailua lehen atea da, eta sysctl net.ipv4.ip_forward(e)k 1 itzuli behar du. echo 1 > /proc/sys/net/ipv4/ip_forward erabiliz ezartzeak hurrengo berrabiaraztera arte funtzionatzen du, eta horrexegatik itzultzen da kexa bera astebete geroago.

Idatzi berrabiaraztea gainditzen duen leku batean:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Bigarren atea iragazki-taula da. Docker instalatuta duen ostalari batek sarritan FORWARD politikaren balioa DROP du, eta tunelek erabaki hori heredatzen du. iptables -L FORWARD -v -n(e)k politika eta pakete-kontagailuak erakusten ditu; politika DROP bada, birbidalketak onarpen esplizitua behar du tunelatik LANera norabiderako eta beste bat erantzunerako.

Hirugarren urratsa: jarraitu paketea LANera eta bilatu erantzuna

Begiratu zerbitzariaren bi aldeak aldi berean. Harrapatu tunelean eta LAN interfazean, bezero bakarrera eta ostalari bakarrera iragazita, irteera irakurgarri gera dadin:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

tun0 interfazean eta gero eth0 interfazean 10.8.0.x iturriarekin agertzen diren eskaerek, ondoren isiltasunak, paketea iritsi zela eta erantzuna beste nonbaitetik joan zela esan nahi dute. LANeko ostalariak bere atebide lehenetsiari erantzuten dio, atebide horrek ez du VPN igerilekuarentzat biderik, eta erantzuna LANeko bideratzailean hiltzen da. Zerbitzaritik LANeko ostalariari ping egiteak ez du ezer frogatzen bide honetaz, trafiko horrek ez baitu inoiz tunela zeharkatzen.

Laugarren urratsa: aukeratu itzulpenaren eta itzulera-bidearen artean

Bi konponketak zuloa ixten dute, eta aukerak ondorioak ditu ping-ek funtzionatzen duen ala ez baino harago. Iturburuko itzulpenak zerbitzaria bidaltzaile itxurakoa egiten du:

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

Mugatu araua igerilekuari eta LAN interfazeari, eta gero egin iraunkor, bestela hurrengo suebaki-kargak zure konponketa isil-isilik kenduko du. Kostua identitatea da: bezero bakoitzak VPN zerbitzariaren itxura du LANeko erregistroetan eta sarbide-arauetan, eta per-client policy becomes guesswork.

LANeko bideratzailean VPN zerbitzarira seinalatzen duen 10.8.0.0/24rako bide estatiko batek bezeroen helbideak ikusgai mantentzen ditu eta epe luzerako erantzun hobea da bideratzaile hori zurea denean. Leku askok biak erabiltzen dituzte denbora batez, NAT berehalako konponketarako eta bidea suebakiaren politika idatzitakoan. Zerbitzaria gunez guneko parekidea bada igerilekua izan beharrean, zerbitzariaren aldeak iroute bat ere behar du urruneko azpisarearentzat, bestela parekidearen bidea existitzen da, baina bezeroen trafikoa ez da inoiz harekin lotzen.

Bosgarren urratsa: egiaztatu bezerotik eta idatzi zer aldatu den

Itxi begizta bezerotik, ez zerbitzaritik. Konektatu LANeko ostalariko zerbitzu erreal batera, eta gero egiaztatu itzulpen-kontagailuak iptables -t nat -L POSTROUTING -v -n erabiliz mugitu direla, zero paketeko araua inoiz bat etorri ez den araua baita. conntrack -L -s 10.8.0.5(e)k fluxua eta bere egoera erakusten ditu itzulera-norabidea jarraitzen dela frogatu behar duzunean.

Utzi ohar bat zerbitzariaren konfigurazioan: zein azpisare, zein interfaze, zein arau, eta LANeko bideratzaileak itzulera-bidea daraman ala ez. Hurrengo aldiz bezeroaren eguneraketak bultzatutako bide bat ezabatzean, ohar horrek suteak itzaltzeko saioa lerro bakarreko konponketa bihurtzen du.