{"id":91646,"date":"2020-08-16T07:42:09","date_gmt":"2020-08-16T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1"},"modified":"2020-08-16T07:42:09","modified_gmt":"2020-08-16T05:42:09","slug":"kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","title":{"rendered":"Come risolvere i problemi del VPN IPsec nazionale. Parte 1.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Come
\n<\/p>\n

Situazione<\/h3>\n

\nUscita. Bevo caff\u00e8. Lo studente ha configurato una connessione VPN tra due punti e poi \u00e8 scomparso. Controllo: il tunnel c'\u00e8 davvero, ma non c'\u00e8 traffico nel tunnel. Lo studente non risponde alle chiamate.<\/p>\n

Metto il bollitore e mi immergo nel troubleshooting di C-Terra Gateway. Condivido la mia esperienza e metodologia.
\n<\/a><\/noindex><\/p>\n

Dati di origine<\/h3>\n

\nDue siti fisicamente separati sono collegati tramite un tunnel GRE. Il GRE deve essere crittografato:<\/p>\n

\"Come
\n
\nControllo il funzionamento del tunnel GRE. Per farlo, avvio un ping dal dispositivo R1 all'interfaccia GRE del dispositivo R2. Questo \u00e8 il traffico di destinazione da crittografare. Non ricevo risposta:<\/p>\n

root@R1:~# ping 1.1.1.2 -c 4\nPING 1.1.1.2 (1.1.1.2) 56(84) byte di dati.\n\n--- 1.1.1.2 statistiche ping ---\n4 pacchetti trasmessi, 0 ricevuti, 100% perdita di pacchetti, tempo 3057ms<\/code><\/pre>\n
\nControllo i log su Gate1 e Gate2. Il log comunica con entusiasmo che il tunnel IPsec \u00e8 stato attivato con successo, nessun problema:<\/p>\n
root@Gate1:~# cat \/var\/log\/cspvpngate.log\nAug  5 16:14:23 localhost  vpnsvc: 00100119  Connessione IPSec 5 stabilita, selettore di traffico 172.17.0.1->172.16.0.1, proto 47, peer 10.10.10.251, id \"10.10.10.251\", Filtro\nIPsec:Protect:CMAP:1:LIST, Azione IPsec Azione:CMAP:1, Regola IKERule:CMAP:1<\/code><\/pre>\n
\nNelle statistiche del tunnel IPsec su Gate1 vedo che il tunnel esiste davvero, ma il contatore Rcvd \u00e8 azzerato:<\/p>\n
root@Gate1:~# sa_mgr show\nSessioni ISAKMP: 0 iniziate, 0 risposte\n\nConnessioni ISAKMP:\nNum Conn-id (Indirizzo Locale,Porta)-(Indirizzo Remoto,Porta) Stato Inviato Ricevuto\n1 3 (10.10.10.251,500)-(10.10.10.252,500) attivo 1070 1014\n\nConnessioni IPsec:\nNum Conn-id (Indirizzo Locale,Porta)-(Indirizzo Remoto,Porta) Protocollo Tipo Azione Inviato Ricevuto\n1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0<\/code><\/pre>\n
\nFaccio troubleshooting su C-Terra in questo modo: cerco dove si perdono i pacchetti di destinazione sul percorso da R1 a R2. Nel processo (spoiler) trover\u00f2 un errore.<\/p>\n
Risolvere i problemi<\/h3>\n
\nPasso 1. Cosa riceve Gate1 da R1<\/b><\/p>\n
Uso il pacchetto sniffer integrato \u2013 tcpdump. Avvio lo sniffer sull'interfaccia interna (Gi0\/1 nella notazione simile a Cisco o eth1 nella notazione del sistema operativo Debian):<\/p>\n
root@Gate1:~# tcpdump -i eth1\n\ntcpdump: output dettagliato nascosto, usa -v o -vv per una decodifica protocollo completa\nin ascolto su eth1, tipo link EN10MB (Ethernet), dimensione cattura 262144 byte\n14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta di echo ICMP, id 2083, seq 1, lunghezza 64\n14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta di echo ICMP, id 2083, seq 2, lunghezza 64\n14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta di echo ICMP, id 2083, seq 3, lunghezza 64\n14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta di echo ICMP, id 2083, seq 4, lunghezza 64<\/code><\/pre>\n
\nVedo che Gate1 riceve pacchetti GRE da R1. Procedo oltre.<\/p>\n
Passo 2. Cosa fa Gate1 con i pacchetti GRE<\/b><\/p>\n
Con l'utility klogview controllo cosa succede con i pacchetti GRE all'interno VPN<\/a> del driver di C-Terra:<\/p>\n
root@Gate1:~# klogview -f 0xffffffff\n\nrisultato della filtrazione per pacchetto in uscita 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: catena 4 \"IPsecPolicy:CMAP\", filtro 8, id evento IPsec:Protect:CMAP:1:LIST, stato PASS\nincapsulamento con SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0\npacchetto in uscita passato 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: incapsulato\n<\/code><\/pre>\n
\nVedo che il traffico GRE target (proto 47) 172.16.0.1 -> 172.17.0.1 \u00e8 passato (PASS) sotto la regola di crittografia LIST nella mappa crittografica CMAP ed \u00e8 stato crittografato (incapsulato). Successivamente, il pacchetto \u00e8 stato instradato (pacchetto passato). Non ci sono traffico di risposta nell'output di klogview.<\/p>\n
Controllo le liste di accesso sul dispositivo Gate1. Vedo una lista di accesso LIST, che definisce il traffico target per la crittografia, il che significa che le regole M\u042d non sono impostate:<\/p>\n
Gate1#show access-lists\nLista di accesso IP estesa LIST\n    10 consenti gre host 172.16.0.1 host 172.17.0.1<\/code><\/pre>\n
\nOutput: problema non sul dispositivo Gate1.<\/p>\n
Informazioni supplementari su klogview<\/b><\/p>\n
Il driver VPN gestisce tutto il traffico di rete, non solo quello che deve essere crittografato. Ecco quali messaggi sono visibili in klogview, se il driver VPN ha elaborato il traffico di rete e lo ha trasmesso in forma non crittografata:<\/p>\n
root@R1:~# ping 172.17.0.1 -c 4<\/code><\/pre>\n
<\/p>\n
root@Gate1:~# klogview -f 0xffffffff\n\nrisultato della filtrazione per pacchetto in uscita 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: catena 4 \"IPsecPolicy:CMAP\": nessuna corrispondenza\npacchetto in uscita passato 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filtrato<\/code><\/pre>\n
\nVedo che il traffico ICMP (proto 1) 172.16.0.1->172.17.0.1 non \u00e8 passato (nessuna corrispondenza) nelle regole di crittografia della mappa crittografica CMAP. Il pacchetto \u00e8 stato instradato (pacchetto passato) in chiaro.<\/p>\n
Passo 3. Cosa riceve Gate2 da Gate1<\/b><\/p>\n
Avvio uno sniffer sull'interfaccia WAN (eth0) di Gate2:<\/p>\n
root@Gate2:~# tcpdump -i eth0\ntcpdump: output dettagliato soppresso, usare -v o -vv per decodifica completa del protocollo\nin ascolto su eth0, tipo di collegamento EN10MB (Ethernet), dimensione di cattura 262144 byte\n16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), lunghezza 140\n16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), lunghezza 140\n16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), lunghezza 140\n16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), lunghezza 140<\/code><\/pre>\n
\nVedo che Gate2 riceve pacchetti ESP da Gate1.<\/p>\n
Passo 4. Cosa fa Gate2 con i pacchetti ESP<\/b><\/p>\n
Avvio l'utilit\u00e0 klogview su Gate2:<\/p>\n
root@Gate2:~# klogview -f 0xffffffff\nrisultato della filtrazione per pacchetto in entrata 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: catena 17 \"FilterChain:L3VPN\", filtro 21, stato DROP\npacchetto in entrata scartato 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: firewall\n<\/code><\/pre>\n
\nVedo che i pacchetti ESP (proto 50) sono stati bloccati (DROP) dalla regola (L3VPN) del firewall. Mi assicuro che la Gi0\/0 sia effettivamente associata alla lista di accesso L3VPN:<\/p>\n
Gate2#show ip interface gi0\/0\nGigabitEthernet0\/0 \u00e8 attivo, il protocollo di linea \u00e8 attivo\n  Indirizzo Internet \u00e8 10.10.10.252\/24\n  MTU \u00e8 1500 byte\n  La lista di accesso in uscita non \u00e8 impostata\n  La lista di accesso in entrata \u00e8 L3VPN<\/code><\/pre>\n
\nProblema individuato.<\/p>\n
Passo 5. Cosa c'\u00e8 di sbagliato nella lista di accesso
\n<\/b>
\nGuardo cosa rappresenta la lista di accesso L3VPN:<\/p>\n
Gate2#show access-list L3VPN\nElenco di accesso IP esteso L3VPN\n    10 consenti udp host 10.10.10.251 any eq isakmp\n    20 consenti udp host 10.10.10.251 any eq non500-isakmp\n    30 consenti icmp host 10.10.10.251 any<\/code><\/pre>\n
\nVedo che i pacchetti ISAKMP sono consentiti, quindi viene stabilito un tunnel IPsec. Tuttavia, non c'\u00e8 una regola di autorizzazione per ESP. Evidentemente, lo studente ha confuso icmp ed esp.<\/p>\n
Correggo l'elenco di accesso:<\/p>\n
Gate2(config)#\nip access-list extended L3VPN\nno 30\n30 permit esp host 10.10.10.251 any<\/code><\/pre>\n
\nPasso 6. Controllo il funzionamento<\/b><\/p>\n
Per prima cosa mi assicuro che l'elenco di accesso L3VPN sia corretto:<\/p>\n
Gate2#show access-list L3VPN\nElenco di accesso IP esteso L3VPN\n    10 consenti udp host 10.10.10.251 any eq isakmp\n    20 consenti udp host 10.10.10.251 any eq non500-isakmp\n    30 consenti esp host 10.10.10.251 any<\/code><\/pre>\n
\nOra Avvio il traffico di destinazione dal dispositivo R1:<\/p>\n
root@R1:~# ping 1.1.1.2 -c 4\nPING 1.1.1.2 (1.1.1.2) 56(84) bytes di dati.\n64 bytes da 1.1.1.2: icmp_seq=1 ttl=64 time=35.3 ms\n64 bytes da 1.1.1.2: icmp_seq=2 ttl=64 time=3.01 ms\n64 bytes da 1.1.1.2: icmp_seq=3 ttl=64 time=2.65 ms\n64 bytes da 1.1.1.2: icmp_seq=4 ttl=64 time=2.87 ms\n\n--- statistiche ping 1.1.1.2 ---\n4 pacchetti trasmessi, 4 ricevuti, 0% perdita di pacchetti, tempo 3006ms\nrtt min\/avg\/max\/mdev = 2.650\/10.970\/35.338\/14.069 ms<\/code><\/pre>\n
\nVittoria. Il tunnel GRE \u00e8 stato stabilito. Il contatore del traffico in entrata nella statistica IPsec non \u00e8 zero:<\/p>\n
root@Gate1:~# sa_mgr show\nSessioni ISAKMP: 0 iniziate, 0 risposte\n\nConnessioni ISAKMP:\nNum Conn-id (Indirizzo locale, Porta)-(Indirizzo remoto, Porta) Stato Inviati Ricevuti\n1 3 (10.10.10.251,500)-(10.10.10.252,500) attivo 1474 1350\n\nConnessioni IPsec:\nNum Conn-id (Indirizzo locale, Porta)-(Indirizzo remoto, Porta) Protocollo Azione Tipo Inviati Ricevuti\n1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480<\/code><\/pre>\n
\nSul gateway Gate2, nel output di klogview sono apparse le segnalazioni che il traffico di destinazione 172.16.0.1->172.17.0.1 \u00e8 stato decrittato (decapsulato) con successo dalla regola LIST nella mappa crittografica CMAP:<\/p>\n
root@Gate2:~# klogview -f 0xffffffff\nrisultato della filtrazione per pacchetto in entrata 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: catena 18 \"IPsecPolicy:CMAP\", filtro 25, id evento IPsec:Protect:CMAP:1:LIST, stato PASS\npacchetto in entrata passato 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsulato<\/code><\/pre>\n
\nConclusioni<\/b><\/p>\n
Lo studente ha danneggiato l'uscita. 
\nFai attenzione con le regole del ME.<\/p>\n
Ingegnere anonimo
\nt.me\/anonimous_engineer<\/i>
\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0421\u0438\u0442\u0443\u0430\u0446\u0438\u044f \u0412\u044b\u0445\u043e\u0434\u043d\u043e\u0439. \u041f\u044c\u044e \u043a\u043e\u0444\u0435. \u0421\u0442\u0443\u0434\u0435\u043d\u0442 \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043b VPN \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u0435 \u043c\u0435\u0436\u0434\u0443 \u0434\u0432\u0443\u043c\u044f \u0442\u043e\u0447\u043a\u0430\u043c\u0438 \u0438 \u0438\u0441\u0447\u0435\u0437. \u041f\u0440\u043e\u0432\u0435\u0440\u044f\u044e: \u0442\u0443\u043d\u043d\u0435\u043b\u044c \u0434\u0435\u0439\u0441\u0442\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0435\u0441\u0442\u044c, \u043d\u043e \u0442\u0440\u0430\u0444\u0438\u043a\u0430 \u0432 \u0442\u0443\u043d\u043d\u0435\u043b\u0435 \u043d\u0435\u0442. \u041d\u0430 \u0437\u0432\u043e\u043d\u043a\u0438 \u0441\u0442\u0443\u0434\u0435\u043d\u0442 \u043d\u0435 \u043e\u0442\u0432\u0435\u0447\u0430\u0435\u0442. \u0421\u0442\u0430\u0432\u043b\u044e \u0447\u0430\u0439\u043d\u0438\u043a \u0438 \u043f\u043e\u0433\u0440\u0443\u0436\u0430\u044e\u0441\u044c \u0432 \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043d\u0433 \u0421-\u0422\u0435\u0440\u0440\u0430 \u0428\u043b\u044e\u0437. \u0414\u0435\u043b\u044e\u0441\u044c \u0441\u0432\u043e\u0438\u043c \u043e\u043f\u044b\u0442\u043e\u043c \u0438 \u043c\u0435\u0442\u043e\u0434\u043e\u043b\u043e\u0433\u0438\u0435\u0439. \u0418\u0441\u0445\u043e\u0434\u043d\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u0414\u0432\u0435 \u0442\u0435\u0440\u0440\u0438\u0442\u043e\u0440\u0438\u0430\u043b\u044c\u043d\u043e \u0440\u0430\u0437\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0435 \u043f\u043b\u043e\u0449\u0430\u0434\u043a\u0438 \u0441\u0432\u044f\u0437\u0430\u043d\u044b GRE \u0442\u0443\u043d\u043d\u0435\u043b\u0435\u043c. GRE \u043d\u0443\u0436\u043d\u043e \u0437\u0430\u0448\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c: \u041f\u0440\u043e\u0432\u0435\u0440\u044f\u044e \u0440\u0430\u0431\u043e\u0442\u043e\u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0441\u0442\u044c GRE […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91647,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91646","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Come risolvere i problemi dell'IPsec VPN domestico. Parte 1 | ProHoster","description":"Situazione Uscita.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u0442\u044c \u043e\u0442\u0435\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0439 IPsec VPN. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u0421\u0438\u0442\u0443\u0430\u0446\u0438\u044f \u0412\u044b\u0445\u043e\u0434\u043d\u043e\u0439.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-trablshutit-otechestvennyj-ipsec-vpn-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-16T05:42:09+00:00","article:modified_time":"2020-08-16T05:42:09+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91646","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:23:24","updated":"2026-02-04 14:42:05","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/91646","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=91646"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/91646\/revisions"}],"predecessor-version":[{"id":156750,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/91646\/revisions\/156750"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/91647"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=91646"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=91646"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=91646"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}