Om ’n IKEv2-kliënt by sy toegewysde virtuele IP te bereik

’n Gateway moet ’n verbinding na ’n skootrekenaar begin wat oor IKEv2 aan hom gekoppel is, deur daardie kliënt se toegewysde virtuele adres te gebruik. Die tonnel is op, die kliënt bereik alles agter die gateway, en die omgekeerde rigting faal steeds. Daardie asimmetrie is normaal: die onderhandelde beleid beskryf watter adresse mag praat, nie watter kant mag begin nie. Drie dinge moet in lyn wees voordat ’n versoek wat deur die gateway begin word, werk.

Die tonnel maak nie die bronadres reg nie

’n CHILD SA dek ’n paar verkeersselektore, een per kant, en laat verkeer in beide rigtings van daardie paar toe. Dit sê niks oor watter eweknie die IKE-uitruiling eerste geopen het nie. ’n Gateway wat oorspronklik vir die tonnel geluister het, kan steeds die eerste toepassingspakket stuur, mits die gekose bron en bestemming binne die geïnstalleerde selektore val. Wanneer die versoek van die verkeerde koppelvlak vertrek, is dit eenvoudig nie vir die tonnel in aanmerking nie.

Roetering na die kliënt is nodig en nie voldoende nie. Die beleid moet die bron toelaat wat jy werklik gebruik het.

Lees die geïnstalleerde beleid, nie die konfigurasielêer nie

Begin by die aktiewe assosiasie en sy selektore, want dinamiese toewysing verander wat op die kern geïnstalleer is.

ipsec statusall
ip xfrm policy

Die statusuitleg noem die verbinding, die toegewysde virtuele adres en die selektore wat tans vir daardie eweknie geld. Die beleidsuitvoer wys dieselfde selektore as kerntoestand, en dit is wat pakketkeuse werklik raadpleeg. Vergelyk die selektor aan die gateway-kant met die bron wat jou toepassing gaan gebruik, want ’n wanverhouding verduidelik die fout onmiddellik. Lees die kliënt se huidige adres eerder as een uit ’n vorige sessie, want ’n hertoegewysde VIP maak die ou beleid ongeldig.

Die kliënt moet luister waar die pakket aankom

Selfs ’n perfekte beleid bereik ’n geslote poort wanneer die diens net aan loopback bind. Die luisteraar moet op die toegewysde adres of op ’n wildcard-plaaslike adres wees.

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

Die soketuitleg wys of die poort aan die virtuele adres gebind is, en die brandmuurreëls wys of nuwe verbindings vanaf die beskermde bron aanvaar word. ’n Reël wat vir gevestigde verbindings geskryf is, laat nie ’n verbinding toe wat die gateway begin nie. Hou die diens se eie verifikasie, want om deur die tonnel aan te kom stel net vas uit watter netwerk die pakket gekom het. ’n Kliënt agter sy eie NAT het steeds geen inkomende poortaanstuur nodig nie, want hierdie versoeke reis binne die bestaande tonnel.

Toets die nuwe rigting op sy eie

’n Werkende versoek van kliënt na bediener oefen nooit hierdie pad nie. Genereer die versoek vanaf die gateway en waarneem beide kante.

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

Die roete-opsoek antwoord watter bron en koppelvlak die gateway sou gebruik, en dit is die waarde wat die beleid moet toelaat. Die opname moet wys dat die versoek binne ESP vertrek eerder as as gewone TCP op die publieke koppelvlak. Op die kliënt, neem die ontsleutelde verkeer op om aankoms te bevestig en of die diens geantwoord het. As die versoek verdwyn sonder ESP op die draad, vermoed die bronadres voor die kliënt se brandmuur.

Herhaal die toets ná ’n sleutelvernuwing of ’n herverbinding, want die VIP kan verander. ’n Pad wat net tot die volgende sessie werk, is nie ’n werkende pad nie.