Încerc să configurez un server Strongswan care rulează în modul tunel divizat, ceea ce înseamnă că trebuie să dezactivez utilizarea serverului ca gateway implicit pe partea clientului și, de asemenea, să dezactivez rutarea completă în clientul VPN.
Atunci trebuie să trimit Opțiunea DHCP 121 (rută statică fără clasă) și Opțiunea DHCP 249 (varianta Microsoft a rutei statice fără clasă) când un client solicită o adresă IP de la serverul Strongswan VPN.
Am nevoie de ambele opțiuni 121 și 249 pentru a ține cont de toate combinațiile de sisteme de operare care se pot conecta (Windows, Linux, Android, MacOS, iPhone etc).
Nu am avut atât de mult succes în utilizarea serverului ISC DHCP cu Strongswan, din moment ce nu era fericit să ascult traficul printr-o interfață WireGuard.A spus că nu acceptă WireGuard sau interfața loopback și că practic a ignorat solicitările DHCP venite de la serverul VPN Strongswan de pe cealaltă parte a conexiunii wireguard.
Așa că am trecut la serverul DHCP Freeradius, deoarece Strongswan folosea deja Freeradius pentru autentificarea utilizatorilor când se conectează la serverul VPN Strongswan.
La urma urmei: Cât de greu ar putea fi, din moment ce aveam de gând să adaug „câteva fișiere de configurare la Freeradius”? :-)
Se pare că este puțin complicat, dar am reușit să-l fac pe Freeradius să asculte traficul pe linkul meu Wireguard folosind următoarea configurație:
asculta {
tip = dhcp
# Subrețeaua 192.168.200.0/24 este subrețeaua mea WireGuard care acționează ca un
# coloana vertebrală VPN de la site la site.
ipaddr = 192.168.200.4
src_ipaddr = 192.168.200.4
port = 67
interfață = wg0
difuzare = nu
}
În fișierul meu strongswan.conf am următoarele:
charon {
load_modular = da
pluginuri {
includ strongswan.d/charon/*.conf
dhcp {
force_server_address = da
identity_lease = da
interfață = wg0
încărcare = da
server = 192.168.200.4
use_server_port = da
}
}
}
Oricum: am făcut ca serverul DHCP Freeradius să transmită adrese IP clientului VPN atunci când Strongswan trimite DHCP-Discover sau DHCP-Request către serverul DHCP Freeradius, dar cumva nu-l pot face să trimită rutele statice?
Văd în dosar dicţionar care rezidă în /etc/freeradius/3.0 din care este încărcat dicționarul pentru opțiunile specifice dhcp /usr/share/freeradius/dictionary.dhcp.
În acel fișier pot găsi următoarele două informații:
# Opțiune de rută statică fără clasă
ATRIBUT DHCP-Classless-Static-Route 121 octeți
...
ATRIBUT DHCP-Site-specific-25 249 octeți
Conform StrongSwan Wiki Pot seta următoarea poartă hop pentru ruta mea statică către 0.0.0.0, deci dacă vreau să spun că subrețeaua 192.168.200.0/24 este accesibil prin legătura VPN. Trebuie să codific ruta ca octeți scrisi ca cod hexadecimal folosind ordinea: {CIDR}{Rețea}{Gateway}.
Asa de 192.168.200.0/24 prin 0.0.0.0 devine 0x18C0A8C800000000
Așa că m-am gândit că ar trebui doar să modific actualizați răspunsul în dhcp DHCP-Descoperire și dhcp DHCP-Solicitare la următoarele:
actualizare răspuns {
&DHCP-Domain-Name-Server = 192.168.200.1
&DHCP-Subnet-Mask = 255.255.255.0
&DHCP-IP-Address-Lease-Time = 86400
&DHCP-Classless-Static-Route = 0x18C0A8C800000000
&DHCP-Site-specific-25 = 0x18C0A8C800000000
&DHCP-DHCP-Server-Identifier = 192.168.200.4
}
Cu toate acestea, nu pot vedea că ruta este împinsă în tabelul meu de rutare, când încerc să mă autent prin clientul Windows VPN.
Deci ce îmi lipsește?
Actualizați
Se pare că codificarea pentru opțiunea DHCP 249 este puțin diferită de opțiunea DHCP 121.
Cel puțin conform Pagina web Microsoft pentru opțiunea DHCP 249.
Cu toate acestea, devin puțin confuz cu privire la modul în care aceasta se traduce prin codificare în Freeradius.
Din câte îmi pot da seama, am spus deja că antetul începe cu opțiunea DHCP 249, din cauza modului în care DHCP-Site-specific-25 este definit în dicționar.
Dar pagina web Microsoft spune că primul octet de după acesta este lungimea tuturor rutelor din DHCP măsurată în octeți, urmată de aceeași codificare pentru rutele definite în opțiunea DHCP 121.
Deci traseul codificat 0x18C0A8C800000000 trebuie precedat cu 08, deci alinierea cu rutele statice Microsoft se citește acum:
&DHCP-Site-specific-25 = 0x0818C0A8C800000000
Am testat cu acea modificare, dar tot nu am avut succes.
A doua actualizare
Mai multă muncă de fișier de configurare pentru DHCP și apoi de monitorizare prin tcpdump despre ceea ce se întâmplă de fapt.
Ori de câte ori un client se conectează la Strongswan, cererea pentru o adresă IP este redirecționată către serverul DCHP, deci, în esență, Strongswan acționează ca agent de retransmisie DHCP dacă am înțeles acea parte corect.
În tcpdump, pot vedea că are loc următorul schimb:
Clientul trimite DHCP Discover
Serverul răspunde cu Oferta DHCP
Clientul trimite o solicitare DHCP
Serverul răspunde cu DHCP ACK
Prima mea concluzie de la monitorizarea tcpdump este că nu trebuie să calculez bytelength pe ruta statică codificată, pentru că asta îngreunează rezultatul de la tcpdump.
Cu alte cuvinte, codificarea pentru opțiunea DHCP 121 și opțiunea DHCP 249 e aceeasi.
Citirile suplimentare sugerează că rutarea statică este asociată cu informațiile DHCP, dar nu am văzut niciodată acel pachet în tcpdump.
Ieșirea de la tcpdump atunci când rulează cu configurația mea inițială de actualizare răspuns mai sus oferă următoarea sesiune:
tcpdump: ascultare pe wg0, RAW de tip link (IP brut), dimensiunea capturii 262144 octeți
10:58:17.185671 IP (to 0x0, ttl 64, id 46089, offset 0, flags [niciun], proto UDP (17), lungime 300)
192.168.200.1.67 > 192.168.200.4.67: [udp sum ok] BOOTP/DHCP, Solicitare de la 7a:a7:8f:1f:b7:88, lungime 272, xid 0x5c9716b5, Flags [none])0x [none]
Gateway-IP 192.168.200.1
Client-Ethernet-Adresă 7a:a7:8f:1f:b7:88
Extensii Vendor-rfc1048
Cookie magic 0x63825363
DHCP-Message Opțiunea 53, lungime 1: Discover
Client-ID Opțiunea 61, lungime 22: tip hardware 108, 61:73:73:65:40:68:6f:6d:65:2e:6d:6f:6c:67:61:61:72:64: 2e:65:75
Opțiunea de solicitare a parametrilor 55, lungimea 2:
Domain-Name-Server, Netbios-Name-Server
END Opțiunea 255, lungime 0
10:58:17.195305 IP (to 0x0, ttl 64, id 19475, offset 0, flags [niciun], proto UDP (17), lungime 328)
192.168.200.4.67 > 192.168.200.1.67: [bad udp cksum 0x129d -> 0x9ffd!] BOOTP/DHCP, Răspuns, lungime 300, xid 0x5c9716b5, Flags [niciunul]00
IP-ul dvs. 192.168.201.13
Gateway-IP 192.168.200.1
Client-Ethernet-Adresă 7a:a7:8f:1f:b7:88
Extensii Vendor-rfc1048
Cookie magic 0x63825363
DHCP-Message Opțiunea 53, lungime 1: Oferta
Subnet-Mask Opțiunea 1, lungime 4: 255.255.255.0
Domain-Name-Server Opțiunea 6, lungime 4: 192.168.200.1
Opțiunea de închiriere 51, lungime 4: 86400
Server-ID Opțiunea 54, lungime 4: 192.168.200.4
Opțiunea de traseu static fără clasă 121, lungime 8: (192.168.200.0/24:0.0.0.0)
Classless-Static-Route-Microsoft Opțiunea 249, lungime 8: (192.168.200.0/24:0.0.0.0)
END Opțiunea 255, lungime 0
Opțiunea PAD 0, lungimea 0, apare 12
10:58:17.219444 IP (to 0x0, ttl 64, id 46098, offset 0, flags [niciun], proto UDP (17), lungime 312)
192.168.200.1.67 > 192.168.200.4.67: [udp sum ok] BOOTP/DHCP, Solicitare de la 7a:a7:8f:1f:b7:88, lungime 284, xid 0x5c9716b5, Flags [none]
Gateway-IP 192.168.200.1
Client-Ethernet-Adresă 7a:a7:8f:1f:b7:88
Extensii Vendor-rfc1048
Cookie magic 0x63825363
DHCP-Message Opțiunea 53, lungime 1: Solicitare
Client-ID Opțiunea 61, lungime 22: tip hardware 108, 61:73:73:65:40:68:6f:6d:65:2e:6d:6f:6c:67:61:61:72:64: 2e:65:75
Opțiunea IP solicitată 50, lungime 4: 192.168.201.13
Server-ID Opțiunea 54, lungime 4: 192.168.200.4
Opțiunea de solicitare a parametrilor 55, lungimea 2:
Domain-Name-Server, Netbios-Name-Server
END Opțiunea 255, lungime 0
10:58:17.228663 IP (to 0x0, ttl 64, id 19477, offset 0, flags [niciunul], proto UDP (17), lungime 328)
192.168.200.4.67 > 192.168.200.1.67: [bad udp cksum 0x129d -> 0x9d02!] BOOTP/DHCP, Răspuns, lungime 300, xid 0x5c9716b5, steaguri [none]
IP-ul dvs. 192.168.201.8
Gateway-IP 192.168.200.1
Client-Ethernet-Adresă 7a:a7:8f:1f:b7:88
Extensii Vendor-rfc1048
Cookie magic 0x63825363
DHCP-Message Opțiunea 53, lungime 1: ACK
Subnet-Mask Opțiunea 1, lungime 4: 255.255.255.0
Domain-Name-Server Opțiunea 6, lungime 4: 192.168.200.1
Opțiunea de închiriere 51, lungime 4: 86400
Server-ID Opțiunea 54, lungime 4: 192.168.200.4
Opțiunea de traseu static fără clasă 121, lungime 8: (192.168.200.0/24:0.0.0.0)
Classless-Static-Route-Microsoft Opțiunea 249, lungime 8: (192.168.200.0/24:0.0.0.0)
END Opțiunea 255, lungime 0
Opțiunea PAD 0, lungimea 0, apare 12
Faptul că pot vedea Rută-statică fără clasă și Rută-Microsoft fără clasă-statică fiind anunțat și chiar spune că subrețeaua 192.168.200.0/24 este disponibil prin tunel, îmi dă indiciu că sunt pe drumul cel bun.
In orice caz:
Ruta încă nu apare în tabelul meu de rutare.
Poate că are ceva de făcut cu următoarea linie:
192.168.200.4.67 > 192.168.200.1.67: [proasta udp cksum 0x129d -> 0x9ffd!] BOOTP/DHCP, Răspuns, lungime 300, xid 0x5c9716b5, steaguri [niciunul] (0x0000)
Stie cineva care este ceea ce trebuie reparat?
