Šliuzas turi pradėti ryšį su nešiojamuoju kompiuteriu, prijungtu prie jo per IKEv2, naudodamas tam klientui priskirtą virtualų adresą. Tunelis veikia, klientas pasiekia viską už šliuzo, tačiau priešinga kryptis vis tiek nepavyksta. Ši asimetrija yra normali: suderinta politika apibūdina, kurie adresai gali kalbėtis, o ne kuri pusė gali pradėti. Trys dalykai turi sutapti, kad šliuzo pradėta užklausa veiktų.

Tunelis nepataiso šaltinio adreso

CHILD SA apima porą srauto selektorių, po vieną kiekvienai pusei, ir leidžia srautą abiem tos poros kryptimis. Ji nieko nesako apie tai, kuri pusė pirmoji atidarė IKE mainus. Šliuzas, kuris iš pradžių klausėsi tunelio, vis dar gali išsiųsti pirmąjį programos paketą, jei pasirinktas šaltinis ir paskirties vieta patenka į įdiegtus selektorius. Kai užklausa išeina iš netinkamos sąsajos, ji tiesiog netinka tuneliui.

Maršrutizavimas link kliento yra būtinas ir nepakankamas. Politika turi priimti šaltinį, kurį iš tikrųjų naudojote.

Skaitykite įdiegtą politiką, o ne konfigūracijos failą

Pradėkite nuo aktyvios asociacijos ir jos selektorių, nes dinaminis priskyrimas keičia tai, kas įdiegta branduolyje.

ipsec statusall
ip xfrm policy

Būsenos išvestis įvardija ryšį, priskirtą virtualų adresą ir selektorius, kurie šiuo metu galioja tam partneriui. Politikos išvedimas rodo tuos pačius selektorius kaip branduolio būseną, ir būtent į ją kreipiasi paketų parinkimas. Palyginkite šliuzo pusės selektorių su šaltiniu, kurį naudos jūsų programa, nes neatitikimas iš karto paaiškina gedimą. Skaitykite dabartinį kliento adresą, o ne ankstesnės sesijos, nes iš naujo priskirtas VIP padaro seną politiką negaliojančią.

Klientas turi klausytis ten, kur atvyksta paketas

Net tobula politika pasiekia uždarą prievadą, kai paslauga susiejama tik su loopback. Klausytojas turi būti priskirtame adrese arba vietiniame pakaitos adrese.

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

Lizdų sąrašas rodo, ar prievadas susietas su virtualiu adresu, o užkardos taisyklės rodo, ar priimami nauji ryšiai iš apsaugoto šaltinio. Taisyklė, parašyta jau užmegztiems ryšiams, neįleidžia ryšio, kurį pradeda šliuzas. Išsaugokite pačios paslaugos autentifikavimą, nes atėjimas per tunelį tik nustato, iš kurio tinklo atėjo paketas. Klientui už savo NAT vis tiek nereikia gaunamojo prievado persiuntimo, nes šios užklausos keliauja esamo tunelio viduje.

Išbandykite naują kryptį atskirai

Veikianti užklausa iš kliento į serverį niekada neišbando šio kelio. Sugeneruokite užklausą iš šliuzo ir stebėkite abu galus.

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

Maršruto paieška atsako, kokį šaltinį ir sąsają naudotų šliuzas, ir tai yra reikšmė, kurią politika turi priimti. Įraše turėtų būti matyti, kad užklausa išeina ESP viduje, o ne kaip paprastas TCP viešoje sąsajoje. Kliente įrašykite iššifruotą srautą, kad patvirtintumėte atėjimą ir ar paslauga atsakė. Jei užklausa dingsta be ESP linijoje, įtarkite šaltinio adresą prieš kliento užkardą.

Pakartokite testą po raktų pakeitimo arba pakartotinio prisijungimo, nes VIP gali pasikeisti. Kelias, kuris veikia tik iki kitos sesijos, nėra veikiantis kelias.

Susiję straipsniai