ASA DHCP relay preko site-to-site VPN-a: praktični vodič
Prođite kroz tri dionice ASA DHCP relaya preko site-to-site VPN-a: sučelje prema klijentima, tunelska politika za relay promet i odgovor na giaddr.
Relay radi u tri dionice i samo srednja prelazi VPN. Klijent emitira broadcast na segmentu podružnice, ASA pretvara taj broadcast u unicast zahtjev upućen DHCP poslužitelju, a poslužitelj odgovara na relay adresu, a ne na klijenta. Prođite dionice tim redom i većina slučajeva «relay je pokvaren» svodi se na nedostajuću politiku ili pogrešno pročitan redak setroute.
Prva dionica: uključite relay na sučelju prema klijentima
Na ASA u podružnici relay je svojstvo sučelja koje gleda prema klijentima. Poslužitelj se može deklarirati globalno sa svojim dostupnim sučeljem ili ispod tog sučelja prema klijentima, kako bi usmjerivačka tablica odabrala izlaz. Ta dva oblika nisu zamjenjiva, a kopiranje pogrešnog prvo je mjesto gdje vodič krene po zlu.
Provjerite trenutnu konfiguraciju prije nego što bilo što promijenite: koje sučelje ima uključen relay, koji je oblik poslužitelja prisutan i je li setroute vezan uz sučelje prema klijentima. Ako ASA istodobno radi i DHCP poslužitelj za drugi segment, zaustavite se i pročitajte popis ograničenja; poslužitelj i relay ne mogu biti uključeni na istom uređaju.
Relay upisuje vlastitu adresu prema klijentima u polje adrese pristupnika. Na tu će adresu poslužitelj odgovoriti, pa ona mora biti dostupna s udaljenog lokaliteta kroz tunel, ne samo lokalno.
Druga dionica: prenesite promet koji generira ASA kroz tunel
Ovo je korak koji ljudi preskaču. Policy-based site-to-site VPN obično se gradi za promet između podmreža, a relay zahtjev generira sama ASA. Ako tunelski access popis i crypto karta pokrivaju samo tokove od hosta u podružnici do podmreže poslužitelja, relay paket možda nikada ne uđe u tunel. Provjerite access popis u oba smjera, ne samo redak od podružnice prema poslužitelju.
Potvrdite da zanimljiv promet pokriva ASA-in relay izvor i adresu poslužitelja te da je dopušten i povratni smjer. Kod dizajna zasnovanog na VTI-ju odluka o usmjeravanju jednostavnija je, ali podrška za relay preko VTI-ja stigla je u određenom izdanju; vodič za DHCP na ASA navodi 9.14(1), pa provjerite image prije nego što kopirate VTI primjer na stariji uređaj.
Ping s ASA prema poslužitelju sam po sebi malo dokazuje. Može uspjeti drugim putem, s drugom izvornom adresom ili pod politikom koju relay paketi ne zadovoljavaju.
Treća dionica: pročitajte odgovor i opciju setroute
RFC 2131 kaže da poslužitelj šalje odgovor na adresu u giaddr kada to polje nije nula. Dakle povratni put mora usmjeravati na relay adresu, a tunelska politika mora dopustiti smjer od poslužitelja prema relayu. Ako je zahtjev prošao, a ponuda nikada ne stigne, ovdje treba tražiti.
Zatim razdvojite dvije stvari koje zvuče slično. Ključna riječ setroute mijenja ili dodaje opciju zadanog usmjerivača koju ASA daje klijentu. Ona ne instalira rutu na ASA i ne stvara VPN politiku. Klijent koji dobije adresu ali ne može ništa dosegnuti često ima problem s setroute ili opsegom, a ne s tunelom. Testirajte to klijentom bez statičkog pristupnika i gledajte koji se zadani usmjerivač pojavljuje u ponudi.
Pročitajte ponudu od početka do kraja: ponuđena adresa, maska, zadani usmjerivač, DNS i vrijeme najma. Zatim pustite da se najam obnovi. Relay koji jednom radi, a padne pri obnovi, obično ima problem s opsegom, najmom ili povratnim putem koji je prva razmjena sakrila.
Što provjeravam prije nego što kažem da je riješeno
Pođite od klijenta i uhvatite broadcast, zatim potvrdite da ga je ASA prenio sa svojom adresom kao giaddr. Na udaljenoj strani potvrdite da je poslužitelj vidio taj zahtjev i odabrao opseg koji odgovara podružnici. Vratite se u podružnicu i potvrdite da je klijent prihvatio ponudu i da doseže svoj pristupnik.
Ako je bilo koja dionica tiha, provjerite odgovarajuću politiku ili rutu umjesto da dodajete još jednu relay naredbu. Relay konfiguracija obično je već ispravna kad netko eskalira; promijenila se tunelska politika ili povratna ruta.
Zapišite tri dionice u zapis o promjenama: sučelje prema klijentima, VPN politika koja pokriva relay promet i povratna ruta poslužitelja do giaddr. Upravo taj zapis čini sljedeću izgradnju podružnice ponovljivim poslom umjesto sesije otklanjanja pogrešaka. On također govori sljedećem inženjeru koji izlaz naredbe prvo prikupiti.