Koji paket mora pogoditi VPN politika sa dva WAN-a?

Zahtevi da se VPN usmeri preko drugog uplinka opisuju najmanje dva različita posla, a politika koja rešava jedan ne dira u drugi. U prvom poslu šifrovani transport između dve krajnje tačke prelazi na drugu WAN adresu. U drugom dešifrovani aplikacijski tok povezanog korisnika izlazi prema drugom sledećem hopu. Oba su legitimna, oba koriste rutiranje, i svaki traži podudaranje na paketu koji postoji u tački gde se odluka donosi. Prođite kroz provere 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 dve 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 dodeljene 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 pomeriti tunel. Isto tako, pravilo koje preusmerava transportnu adresu peera ne govori ništa o tome kuda ide HTTP zahtev tog korisnika nakon dešifrovanja. Zapišite oba razgovora s njihovim stvarnim adresama pre nego što dotaknete pravilo, jer većina zabune u ovoj oblasti dolazi iz toga što se jedno imenuje a drugo konfiguriše.

Nađite gde vaša politika zaista vidi paket

Podudaranje se mora proceniti u lancu i imenskom prostoru gde je paket još u obliku koji ste opisali. Pravilo prikačeno na LAN ulaz vidi unutrašnji paket nešifrovan, pre nego što bude rutiran prema tunelu. Pravilo primenjeno na lokalno generisan saobraćaj vidi pakete koje gateway sam stvara, i ono ne pokriva automatski saobraćaj koji gateway samo prosleđ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 isečak konfiguracije ponaša različito na dve platforme: tačke pričvršćivanja se razlikuju, a proizvođačka kuka politike može stajati pre ili posle koraka šifrovanja. Čitajte putanju paketa za konkretan proizvod umesto da pretpostavljate redosled 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 oznaku koja 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 vrednosti pobeđuju zapamćene. Čitajte trenutne portove i adrese asocijacije sa uređaja umesto da dodajete TCP 4500 ili stari port proizvođača za svaki slučaj, što hvata nepovezan saobraćaj i skriva stvarni problem klasifikacije.

Proverite povratnu putanju pre nego što se obavežete

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

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

Proverite oba sloja s dva snimka

Jedan snimak na WAN interfejsu i jedan unutar tunela rešavaju pitanje brže od bilo kojeg poređenja konfiguracija. Pokrenite ih sa gatewaya dok odobreni klijent izvršava jedan zahtev, 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 da pokaže spoljni razgovor kako napušta interfejs koji ste nameravali, s očekivanom izvornom adresom. Drugi treba da pokaže 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 negde drugde, a ne tamo gde je pravilo prikačeno, i ispravka pripada tamo, a ne u šire podudaranje.