Guneen arteko VPNaren erantzuna ez da tunelatik pasatzen
Tunela saihesten duen erantzuna urruneko aldeko bideratze-erabakia da. Egiaztatu ostalari-taula, hautatzaileak eta rp_filter, eta gero aukeratu bidea edo NAT.
Goiz bat eman nuen tunel batean, garbi sortu eta trafikoa norabide bakarrean soilik eramaten zuena: sukurtsalak hiriburuko fitxategi-zerbitzaria iristen zuen, eta hiriburutik sukurtsalera irekitako konexio bakoitza lehen SYN-ean hiltzen zen. SAak aktibo zeuden, tunelaren kontagailuak igotzen ziren, eta eskuko heltzea ez zen inoiz arazoa. Erantzuna tunelak estaltzen ez duen toki batera bideratzen zen, eta hautapen hori urruneko aldearena da. Guneen arteko VPN batek ostalariak atebideari ematen dizkion paketeak bakarrik garraiatzen ditu, eta ostalari bakoitzak hautapen hori bereiz egiten du, norabide bakoitzean, bere bideratze-taulatik.
Bi norabideak bereiz bideratzen dira
IPk ez du elkarrizketa baten norabidearen memoria gordetzen. Pakete bat bidaltzen duen ostalari bakoitzak bere aurrizkirik luzeenaren bilaketa egiten du, hurrengo jauzi bat aukeratzen du eta erabakia ahazten du. Eskaera eta erantzuna konexio berari kasualitatez dagozkion bi pakete erlaziorik gabeak dira, eta tunela bietako edozeinek erabil dezakeen edo ez duen jauzi bat da. IKE trukean ezerk ez dio urruneko zerbitzariari zure azpisarera nola iritsi irakasten; negoziazioak zein aurrizki zifra daitezkeen adosten du soilik.
Akordio hori bigarren atea da. strongSwanen trafiko-hautatzaileak leftsubnet eta rightsubnet dira, eta negoziatutako bikotearen kanpoan geratzen den jatorri edo helmugako paketea ez da zifratzen, bideratze-taulak esaten duena esanda ere. Tunelera bideratzen den baina hautatzaileetan falta den aurrizkia isil-isilikako norabide bakarreko hutsegitea da: bidea zuzena dirudi, paketea oraindik argi ateratzen da edo baztertu egiten da, eta charon-en erregistroak soilik kexatzen dira.
Urruneko ostalariak ez daki ezer zure tunelaz
Urruneko LANaren barruan erantzuna zure bezeroari zuzendutako pakete arrunta da. Helmuga-ostalariak ez du IPsec goibururik ikusten eta ez du VPN atebidea hobesteko arrazoirik; zure aurrizkia bilatzen du, bere bide lehenetsia baino zehatzago ezer aurkitzen ez du eta hari jarraitzen dio. Lehenetsiak suebaki nagusi batera eramaten badu, suebakiak tunelera itzultzeko bidea du edo ez du. Ez badu, isil-isilikako baztertzea, ICMP unreachable bat edo internet aldera begira dagoen interfazetik atera eta hiltzen den erantzun bat jasoko duzu.
Bigarren interfaze bat nahikoa da hau hausteko bidea badagoenean ere. Beste VLAN batean kudeaketa-esteka duen NAS bat, babesko uplink duen zerbitzari bat, jatorri-barruti bat bigarren taula batera bidaltzen duen politika-arau bat: horietako edozeinek har dezake erantzuna. Linuxen, ip rule show eta ip route show table all erakusten dituzte zerrenda lehenetsiak ezkutatzen dituen arauak eta taulak.
Irakurri erabakia erantzuna bidaltzen duen makinan
Galdetu nukleoari ezer aldatu aurretik, eta eman jatorri-helbidea, jatorriaren araberako arauek erantzuna aldatzen baitute.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"Irteerak irteera-interfazea eta hurrengo jauzia aipatzen ditu. Interfazea VPN atebidera begira dagoena ez bada, akatsa aurkitu duzu, eta gainerako lana bidea non dagokion hautatzea da. Atebidetik egindako pingek gutxi frogatzen dute hemen: urruneko ostalariak kokatu dezakeen helbide batekin erantzuten du, zure eramangarriaren helbidearekin ez.
Windowsen baliokideak Find-NetRoute -RemoteIPAddress 10.10.5.10 dira erabakirako eta Get-NetRoute taularako. Lehenetsia baino metrikoa handiagoa duen New-NetRoute erabiliz gehitutako bidea isilik galtzen da, beraz irakurri metrika-zutabea, ez sarrera. Gero egiaztatu paketekin: tcpdump -ni any "host 10.10.5.10 and tcp port 445" urruneko LAN interfazean eskaera erakusten du, eta tunelaren aldean iragazki berak erantzunik itzuli den erakusten du. Eskaera ikusgai erantzunik gabe esan nahi du erantzuna beste norabait bideratu zela edo baztertu zela; interfaze okerrean erantzun batek erruduna ematen dizu bide bat ukitu aurretik.
Zerbitzariaren atebidea VPNaren amaiera-puntua ez denean
Toki askok suebaki bat jartzen dute zerbitzarien eta kontzentratzailearen artean. Suebaki horrek erantzuna birbidaltzen du, beraz zure bezeroaren aurrizkiarentzako bidea behar du VPN atebidera seinalatuz, eta birbidaltze-politika bi norabideetan. Egoera duten gailuek okerrera egiten dute: eskaerak suebakia zeharkatu zuen baimendu zuen LAN ostalari batetik, erantzuna orain beste norabide batetik iristen da, eta konexio-jarraipenaren sarrera ez dator bat, beraz paketea baliogabe gisa baztertzen da ukatu beharrean. Horregatik politika-erregistroa hutsik dirudi trafikoa desagertzen den bitartean.
Atebideak bere bigarren iragazkia du. Linuxen alderantzizko bidearen iragazketak baztertzen ditu iritsi ziren interfazetik jatorria irisgarria ez duten paketeak, eta hori da itzulera-bide asimetriko legitimo baten itxura zehatza. strongSwanen birbidaltze-gida net.ipv4.ip_forward eta net.ipv4.conf.all.rp_filter lasaiago bat eskatzen ditu horregatik. Atebideren batean 1 balio zorrotzak isilik hausten du bide zuzen bat, eta nstat -az baztertzeak erakusten ditu non begiratu badakizu.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Bideratu edo itzuli, eta gero egiaztatu bi norabideetan
Bi konponketak ez dira baliokideak. Bidea gehitzeak bezeroaren helbidea ukitu gabe uzten du, beraz jatorrian oinarritutako arauek, auditoretza-erregistroek eta deitzailea erregistratzen duten aplikazioek lanean jarraitzen dute; prezioa da erabakia hartzen duen jauzi bakoitzak bidea behar duela, hau da, okerrera egiteko toki gehiago. Maskaratzea urruneko atebidean itzulera-bidea jauzi bakarrera murrizten du, erantzuna orain atebideari berari zuzenduta baitago, eta zein bezerok zer egin zuen ezkutatzen du.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEAukeratu kontzienteki: bezeroak atebidearen helbide gisa agertzen hasitakoan, jatorrian oinarritutako ACLek ez dituzte gehiago bereizten, eta conntrack erregistroak mapaketa eutsi behar du erantzuna tunelera berridazteko. Hautatzaileek bezeroaren aurrizkia baztertzen badute oraindik, NATek ez du ezer aldatzen, eskaera ez baitzen inoiz tunelera sartu.
Konponduta dela esan aurretik, egiaztatu lau gauza hurrenez hurren: erantzuna bidaltzen duen ostalariaren bidea, birbidaltzen duen jauzi bakoitzaren bidea, bi aurrizkiak estaltzen dituzten hautatzaileak, eta erantzuna espero duzun jatorriarekin tunelera sartzen dela erakusten duen harrapaketa bat. Gero errepikatu proba beste gunetik. Norabide bat pasatzea erdi-irekiko diseinua da, eta bigarren norabideak huts egiten du normalean oraintxe konpondu duzunaz bestelako arrazoi batengatik.