Koji paket mora da pogodi VPN politika sa dva WAN-a?

Zahtjevi da se VPN usmjeri preko drugog uplinka opisuju najmanje dva različita posla, a politika koja rješava jedan ne dira u drugi. U prvom poslu šifrovani transport između dvije krajnje tačke prelazi na drugu WAN adresu. U drugom, dešifrovani aplikacijski tok povezanog korisnika izlazi prema drugom sljedećem hopu. Oba su legitimna, oba koriste rutiranje, i svaki traži podudaranje na paketu koji postoji u tački gdje se odluka donosi. Prođite kroz provjere ispod po redu, jer prva određuje koji paket kasnija pravila moraju imenovati.

Imenujte dva razgovora

Zamislite udaljenog radnika povezanog na kancelarijski gateway, koji otvara HTTPS prema internom aplikacijskom serveru. Na mreži su dva nezavisna razgovora, i oni na svakom kraju imaju različite adrese. Spoljni razgovor teče između dvije VPN krajnje tačke: od adrese gatewaya do adrese peera, s onim protokolom i portom koje je implementacija dogovorila. Unutrašnji razgovor teče od adrese dodijeljene klijentu do adrese aplikacijskog servera na portu 443.

Odredišni port aplikacije nije transportni port VPN-a, i nikakva količina politike na TCP 443 neće pomjeriti tunel. Isto tako, pravilo koje preusmjerava transportnu adresu peera ne govori ništa o tome kuda ide HTTP zahtjev tog korisnika nakon dešifrovanja. Zapišite oba razgovora s njihovim stvarnim adresama prije nego što dotaknete pravilo, jer većina zbrke u ovoj oblasti dolazi iz toga što se jedno imenuje a drugo konfiguriše.

Nađite gdje vaša politika zaista vidi paket

Podudaranje se mora procijeniti u lancu i imenskom prostoru gdje je paket još u obliku koji ste opisali. Pravilo prikačeno na LAN ulaz vidi unutrašnji paket nešifrovan, prije nego što bude rutiran prema tunelu. Pravilo primijenjeno na lokalno generisan saobraćaj vidi pakete koje gateway sam stvara, i ono ne pokriva automatski saobraćaj koji gateway samo prosljeđuje. Enkapsulirani izlaz je opet treći slučaj, obično se obrađuje na interfejsu koji nosi tunel, a ne na LAN strani.

Zato se isti isječak konfiguracije ponaša različito na dvije platforme: tačke pričvršćivanja se razlikuju, a proizvođačka kuka politike može stajati prije ili poslije koraka šifrovanja. Čitajte putanju paketa za konkretan proizvod umjesto da pretpostavljate redoslijed sa dijagrama drugog proizvođača.

Potvrdite transport koji ste dogovorili

Za IPsec enkapsuliran u UDP, RFC 3948 stavlja ESP unutar UDP-a i koristi marker koji nije ESP da IKE ostane razlučiv na zajedničkom portu. Obični ESP je IP protokol, a ne TCP ili UDP port, pa pravilo firewall-a napisano prema broju porta uopšte ga neće pogoditi. Ova razlika odlučuje treba li vašoj WAN politici UDP pravilo, pravilo protokola ili oboje.

Dogovorene vrijednosti pobjeđuju zapamćene. Čitajte trenutne portove i adrese asocijacije sa uređaja umjesto da dodajete TCP 4500 ili stari port proizvođača za svaki slučaj, što hvata nepovezan saobraćaj i skriva stvarni problem klasifikacije.

Provjerite povratnu putanju prije nego što se obavežete

Uspjeh u odlaznom smjeru dokazuje pola dizajna. Paket koji se vraća prema bazenu udaljenih klijenata više nije vidljiv pod adresom klijenta kada ga enkapsulacija zamijeni: spoljno odredište je transportna adresa peera. Ako drugi uplink dosegne taj peer preko drugog operatera, njegova translacija i filtriranje mogu se razilaziti s prvim, i asocijaciju će možda trebati ponovo izgraditi, a ne migrirati.

Stanje translacije mrežnih adresa je uobičajena žrtva promjene WAN-a. Zabilježite odabrani uplink, očekivanu spoljnu izvornu adresu, translaciju u upotrebi i dostupnost peera natrag prema njoj, pa držite transport dostupnim bez slanja u tunel koji ga nosi.

Provjerite oba sloja s dva snimka

Jedan snimak na WAN interfejsu i jedan unutar tunela rješavaju pitanje brže od bilo kojeg poređenja konfiguracija. Pokrenite ih sa gatewaya dok odobreni klijent izvršava jedan zahtjev, i sačuvajte oba fajla.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

Prvi snimak treba pokazati spoljni razgovor kako napušta interfejs koji ste namjeravali, s očekivanom izvornom adresom. Drugi treba pokazati unutrašnji razgovor jednom, bez dupliranja, s klijentskom adresom kao izvorom i aplikacijskim serverom kao odredištem. Pretraga rute potvrđuje koju bi tablicu ruter koristio za taj par izvor i odredište, i tu se greška u politici obično pojavi. Ako se neki snimak ne pojavi, tačka odluke je negdje drugo, a ne tamo gdje je pravilo prikačeno, i ispravka pripada tamo, a ne u šire podudaranje.