IKEv2-asiakkaan tavoittaminen sen määritetyllä virtuaalisella IP:llä

Yhdyskäytävän on aloitettava yhteys kannettavaan tietokoneeseen, joka on liitetty siihen IKEv2:n kautta, käyttämällä kyseiselle asiakkaalle määritettyä virtuaaliosoitetta. Tunneli on pystyssä, asiakas tavoittaa kaiken yhdyskäytävän takana, ja vastasuunta epäonnistuu silti. Tämä epäsymmetria on normaalia: neuvoteltu käytäntö kuvaa, mitkä osoitteet saavat puhua, ei sitä, kumpi osapuoli saa aloittaa. Kolmen asian on osuttava kohdalleen ennen kuin yhdyskäytävän aloittama pyyntö toimii.

Tunneli ei korjaa lähdeosoitetta

CHILD SA kattaa parin liikenteen valitsimia, yhden kummallekin puolelle, ja sallii liikenteen tuon parin molempiin suuntiin. Se ei kerro mitään siitä, kumpi vastapuoli avasi IKE-vaihdon ensin. Yhdyskäytävä, joka alun perin kuunteli tunnelia, voi yhä lähettää ensimmäisen sovelluspaketin, edellyttäen että valittu lähde ja kohde osuvat asennettujen valitsimien sisään. Kun pyyntö lähtee väärästä rajapinnasta, se ei yksinkertaisesti kelpaa tunnelille.

Reititys asiakasta kohti on välttämätöntä eikä riittävää. Käytännön on hyväksyttävä lähde, jota todella käytit.

Lue asennettu käytäntö, älä asetustiedostoa

Aloita aktiivisesta liitoksesta ja sen valitsimista, koska dynaaminen määritys muuttaa sitä, mitä ytimeen on asennettu.

ipsec statusall
ip xfrm policy

Tilatuloste nimeää yhteyden, määritetyn virtuaaliosoitteen ja valitsimet, jotka ovat kyseiselle vastapuolelle tällä hetkellä voimassa. Käytännön vienti näyttää samat valitsimet ytimen tilana, ja juuri sitä pakettien valinta todella kysyy. Vertaa yhdyskäytävän puolen valitsinta lähteeseen, jota sovelluksesi käyttää, koska eroavuus selittää epäonnistumisen heti. Lue asiakkaan nykyinen osoite eikä edellisen istunnon osoitetta, koska uudelleen määritetty VIP tekee vanhasta käytännöstä mitättömän.

Asiakkaan on kuunneltava siellä, minne paketti saapuu

Jopa täydellinen käytäntö päätyy suljettuun porttiin, kun palvelu sitoutuu vain loopbackiin. Kuuntelijan on oltava määritetyllä osoitteella tai paikallisella jokeriosoitteella.

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

Pistokeluettelo näyttää, onko portti sidottu virtuaaliosoitteeseen, ja palomuurin säännöt näyttävät, hyväksytäänkö uudet yhteydet suojatusta lähteestä. Vakiintuneille yhteyksille kirjoitettu sääntö ei päästä läpi yhteyttä, jonka yhdyskäytävä aloittaa. Säilytä palvelun oma todennus, koska tunnelin kautta saapuminen vahvistaa vain, mistä verkosta paketti tuli. Asiakas oman NAT:nsa takana ei silti tarvitse saapuvaa portin uudelleenohjausta, koska nämä pyynnöt kulkevat olemassa olevan tunnelin sisällä.

Testaa uusi suunta erikseen

Toimiva pyyntö asiakkaalta palvelimelle ei koskaan harjoita tätä polkua. Luo pyyntö yhdyskäytävältä ja tarkkaile molempia päitä.

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

Reittihaku vastaa, mitä lähdettä ja rajapintaa yhdyskäytävä käyttäisi, ja juuri sen arvon käytännön on hyväksyttävä. Kaappauksen pitäisi näyttää pyynnön lähtevän ESP:n sisällä eikä tavallisena TCP:nä julkisella rajapinnalla. Kaappaa asiakkaalla purettu liikenne vahvistaaksesi saapumisen ja sen, vastasiko palvelu. Jos pyyntö katoaa ilman ESP:tä verkosta, epäile lähdeosoitetta ennen asiakkaan palomuuria.

Toista testi avaimen vaihdon tai uudelleenyhdistämisen jälkeen, koska VIP voi muuttua. Polku, joka toimii vain seuraavaan istuntoon asti, ei ole toimiva polku.