IKEv2 bezero batera iristea bere IP birtual esleituan

Gatewayak IKEv2 bezero batera hasitako eskaerak hautatzaile bat datorrena, tokiko iturri egokia eta helbide irisgarrian entzule bat behar ditu. Egiaztatu hirurak.

Gateway batek IKEv2 bidez berari konektatuta dagoen ordenagailu eramangarri baterako konexioa hasi behar du, bezero horri esleitutako helbide birtuala erabiliz. Tunela martxan dago, bezeroak gatewayaren atzeko guztietara iristen da, eta alderantzizko norabideak huts egiten jarraitzen du. Asimetria hori normala da: negoziatutako politikak zein helbidek hitz egin dezaketen deskribatzen du, ez zein aldek has dezakeen. Hiru gauza bat etorri behar dira gatewayak hasitako eskaera funtziona dezan.

Tunelak ez du iturri-helbidea konpontzen

CHILD SA batek trafiko-hautatzaileen bikote bat estaltzen du, bat alde bakoitzeko, eta bikote horren bi norabidetan trafikoa baimentzen du. Ez du ezer esaten zein parek ireki zuen IKE trukea lehenengo. Hasieran tunelarentzat entzuten zuen gateway batek oraindik lehen aplikazio-paketea bidal dezake, aukeratutako iturria eta helburua instalatutako hautatzaileen barruan dauden bitartean. Eskaera interfaze okerretik irteten denean, ez da tunelerako egokia besterik gabe.

Bezeroarenganako bideratzea beharrezkoa da eta ez da nahikoa. Politikak benetan erabili duzun iturria onartu behar du.

Irakurri instalatutako politika, ez konfigurazio fitxategia

Hasi elkarte aktibotik eta haren hautatzaileetatik, esleipen dinamikoak nukleoan instalatuta dagoena aldatzen baitu.

ipsec statusall
ip xfrm policy

Egoeraren irteerak konexioa, esleitutako helbide birtuala eta pare horretarako indarrean dauden hautatzaileak izendatzen ditu. Politikaren iraulketak hautatzaile berak erakusten ditu nukleoaren egoera gisa, eta paketeen hautaketak horri galdetzen dio benetan. Konparatu gateway aldeko hautatzailea zure aplikazioak erabiliko duen iturriarekin, desadostasunak hutsegitea berehala azaltzen baitu. Irakurri bezeroaren uneko helbidea, aurreko saio batekoa beharrean, VIP berresleitu batek politika zaharra baliogabetzen baitu.

Bezeroak paketea iristen den tokian entzun behar du

Politika ezin hobeak ere portu itxi batera iristen da zerbitzua loopback-era bakarrik lotzen denean. Entzulea esleitutako helbidean edo tokiko komodin helbide batean egon behar du.

ss -ltnp 'sport = :9090'
iptables -S INPUT

Soketen zerrendak erakusten du portua helbide birtualera lotuta dagoen, eta suebakiaren arauek iturri babestutik konexio berriak onartzen diren. Ezarritako konexioetarako idatzitako arau batek ez du gatewayak hasten duen konexio bat onartzen. Mantendu zerbitzuaren autentikazio propioa, tuneletik iristeak paketea zein saretatik etorri zen soilik ezartzen baitu. Bere NAT propioaren atzeko bezero batek oraindik ez du sarrerako portu-birbideratzerik behar, eskaera horiek lehendik dagoen tunelaren barruan bidaiatzen baitute.

Probatu norabide berria bere horretan

Bezerotik zerbitzarirako eskaera on batek ez du inoiz bide hau probatzen. Sortu eskaera gatewaytik eta behatu bi muturrak.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

Ibilbide-kontsultak gatewayak zein iturri eta interfaze erabiliko lituzkeen erantzuten du, eta horixe da politikak onartu behar duen balioa. Harrapaketak eskaera ESP barruan irteten erakutsiko du, ez TCP arrunt gisa interfaze publikoan. Bezeroan, harrapatu deszifratutako trafikoa iristea eta zerbitzuak erantzun duen baieztatzeko. Eskaera ESPrik gabe desagertzen bada sarean, susma ezazu iturri-helbidea bezeroaren suebakia baino lehen.

Errepikatu proba gakoak berritzean edo berriz konektatzean, VIPa aldatu baitaiteke. Hurrengo saiora arte bakarrik funtzionatzen duen bidea ez da bide balioduna.

Erlazionatutako artikuluak