Kami menerbitkan semua layanan yang terletak di hypervisor rumah melalui layanan
EC2 Amazon Web Services melalui instance gratis untuk Amazon Linux AMI 2018 menggunakan
libreswan ,
xl2tpd dan dengan sedikit distorsi ...
Administrator sistem dari bisnis tradisional (non-TI) dengan pengalaman, biasanya setelah beberapa saat, memiliki peternakan virtualisasi server sendiri di rumah untuk menguji tumpukan solusi di lapangan. Ini bisa berupa tiruan dangkal dari jaringan kantor-cabang terdistribusi, pengujian infrastruktur terintegrasi ketersediaan tinggi, penyebaran versi baru dari beberapa solusi, dll.
Secara eksternal, dapat terlihat dari PC rumahan sederhana yang dipompa dengan hypervisor built-in dan NAS tingkat konsumen sebagai penyimpanan iSCSI (atau bahkan sebagai mesin virtual sederhana pada PC yang sama) ke server rack-mount berukuran kecil penuh yang dibeli untuk unit kontrol yang dihapus murah dengan silsilah dari pusat data barat, dengan tsiska BU yang sama untuk konektivitas jaringan dan terjebak di Fibre Channel yang sama, dibeli di NAS pasar sekunder, tetapi sudah kelas bisnis.
Tentu saja, di zaman kita yang menggila untuk cloud, seluruh infrastruktur dapat dengan mudah digunakan di pusat data cloud, tetapi ini masih tidak selalu memungkinkan, terutama karena biayanya. Tidak masalah jika pengujian membutuhkan beberapa mesin virtual ringan dari paket yang tersedia, tetapi bagaimana jika bertugas Anda harus memutar beberapa lusin atau bahkan ratusan "mesin virtual" yang terpisah dengan berbagai layanan, dan Anda juga ingin memiliki arsip sehingga Anda dapat memilikinya kapan saja. ada sampel yang memutar konfigurasi / pengaturan setahun yang lalu. Atau ada kebutuhan untuk mentransfer semua jebakan dengan sinkronisasi yang sama antara ADDS dan ADFS sebelum mentransfer beberapa layanan bisnis yang ada ke MS Azure yang sama.
Masalah utama dalam hal ini adalah publikasi (penerusan) semua infrastruktur ini ke luar, sehingga Anda dapat berlatih menghubungkan pengguna dari luar ke "situs server" rumah Anda atau ke layanan "cloud" Anda sendiri, atau integrasi dengan layanan pihak ketiga dll.
Baik jika koneksi rumah dirancang untuk tarif bisnis, dalam hal ini tidak ada masalah dengan permintaan yang masuk, dan alamat IP hampir selalu "putih", statis.
Tetapi apa yang harus dilakukan ketika penyedia "rumah" yang biasa hadir di tempat tinggal, yang selain itu hanya dapat memberikan alamat dari jaringan Pribadi. Atau itu akan memberikan alamat putih, tetapi secara tradisional memotong semua yang masuk dari kisaran port istimewa (<1024)? Atau Anda adalah siswa miskin yang klise dan tidak mampu membayar tarif bulanan yang dirancang untuk badan hukum. Atau apakah Anda sering harus mengubah tempat tinggal Anda, menyeret server virtual Anda "barang-barang" ke punuk? Sebuah kasus khusus juga relevan bagi mereka yang tinggal di luar CIS, ketika penyedia secara paksa menyediakan peralatan sendiri untuk menghubungkan ke Internet dan di sana Anda secara fisik tidak dapat mengkonfigurasi penerusan port yang Anda butuhkan ke peternakan virtual di rumah di luar.
Salah satu solusinya adalah dengan menggunakan salah satu layanan VPN pihak ketiga. Sayangnya, beberapa dari mereka mengizinkan izin koneksi masuk sehubungan dengan terowongan, paling sering itu adalah layanan berbayar terpisah. Juga dalam hal ini, pilihan alamat IP eksternal akan sangat terbatas jika Anda ingin menguji situasi dengan kehadiran alamat IP eksternal di negara tertentu, terlebih lagi, sebagai suatu peraturan, tidak ada jaminan bahwa pada saat yang sama sekelompok klien layanan VPN lainnya tidak menggantung pada alamat ini. , atau akan menjadi statis untuk waktu yang lama, yang penting untuk menyiapkan catatan subdomain layanan di DNS.
Juga layak (IMHO), meskipun beberapa metode sesat, adalah untuk menggunakan router "virtual" Anda sendiri pada beberapa platform cloud eksternal dengan kemampuan untuk mengkonfigurasi terowongan VPN dari farm hypervisor rumah ke mesin virtual ini di cloud, dengan koneksi masuk yang diperlukan diteruskan dari antarmuka jaringan eksternal layanan cloud to home hypervisor. Dan idealnya, hampir tidak membayar apa pun untuk semuanya.
Baru-baru ini kehilangan pekerjaan saya, dan dengan itu akses ke kebun pengujian perusahaan yang hangat dan nyaman, tetapi sebagai imbalannya menerima banyak waktu luang untuk memperbarui keterampilan saya, saya memutuskan untuk memberikan layanan dari hypervisor rumah saya kesempatan untuk melihat koneksi klien yang masuk.
Penulis baris ini
“mencintai semua jenis penyimpangan infrastruktur” , sehingga sebagai router virtual kita akan menggunakan contoh Amazon Web Services (AWS) EC2 t2.micro gratis untuk Linux, yang alih-alih AWS: VPC (secara teori) akan memberikan sedikit lebih banyak fleksibilitas dalam debugging dan fitur , dan topologi penyimpangan VPN ini ditunjukkan di bawah ini:
Apa yang kita lihat di sini?
Ada mesin virtual (750 jam kerja per bulan selama tahun ini), gratis (misalnya), di Linux, yang digunakan di AWS: EC2. Panggilan masuk dari beberapa pengguna layanan rumah Anda jatuh ke alamat IPv4 putih eksternal dari Elastic IP, kemudian melalui aturan masuk (Inbound) di "Grup Keamanan" port yang kita butuhkan memetakan ke dalam ke antarmuka jaringan contoh, kemudian paket permintaan ini melalui iptables melalui terowongan IPSec ke mesin virtual untuk Windows 2016, di mana, menggunakan perutean, RRAS sampai ke layanan yang diinginkan di dalam virtual farm rumah. Kami memberikan perhatian khusus pada kehadiran tiga NAT sekaligus: satu di AWS Linux, satu di router "jaringan kantor" dan satu lagi, secara implisit, pada router rumah.
Dalam hal ini (saya), mesin virtual di bawah Windows Server 2016 memainkan peran router untuk mensimulasikan jaringan kantor dan platform servernya, MS WAP digunakan di dalamnya bersamaan dengan mesin terpisah dengan MS ADFS dan lainnya, sehingga tidak ada masalah untuk menggantinya dengan OS lain. bahkan sepotong buatan sendiri secukupnya. Dengan Windows RRAS, ngomong-ngomong, segala sesuatunya menjadi rumit di sepanjang jalan, di sepanjang jalan saya harus berurusan dengan berbagai momen tidak menyenangkan (tentang yang di bawah), jadi jika Anda memilih untuk tidak menyukai MS Windows Server sebagai router, maka dengan sistem operasi lain mungkin lebih mudah.
Pertama kita akan membuat akun AWS jika Anda masih belum memilikinya. Tidak ada masalah dengan pembuatan akun itu sendiri, Anda hanya perlu menunjukkan rincian kartu plastik Anda, dari mana 1 USD akan didebet (dan kemudian dikembalikan) sebagai cek.
Hanya dua poin yang perlu disebutkan di sini:
- Pastikan untuk mengunjungi AWS: IAM (Identity and Access Management) dan aktifkan MFA (Multi-Factor Authentication) untuk akun baru Anda, atau bahkan lebih baik, seperti yang direkomendasikan AWS - buat akun terpisah dengan MFA juga dan terus bekerja melalui pembatasan hak-hak terkait. dia. Jika tidak, Anda mungkin berakhir dalam situasi yang tidak menyenangkan ketika Trojan mencuri kredensial AWS dari PC Anda dan, misalnya, seseorang menambang dari hati Anda dengan biaya Anda pada paket contoh kinerja tinggi yang mahal ...
- Untuk alasan praktis, sebaiknya Anda menyiapkan lansiran anggaran. Ini dilakukan dalam pengaturan akun, item menu yang sesuai disebut "Dasbor Manajemen Penagihan & Biaya". Pada panel yang terbuka, pilih item "Anggaran" di sebelah kiri dan konfigurasikan anggaran bulanan yang direncanakan sesuai selera menggunakan wisaya bawaan. Jangan lupa untuk mengatur peringatan di sana: jika melebihi jumlah yang ditentukan, Anda akan segera menerima pesan. Ini berguna jika Anda belum pernah bekerja dengan AWS sebelumnya dan takut untuk secara tidak sengaja “mendapatkan” jumlah bulat dalam percobaan Anda.
Selanjutnya, kita perlu
AWS: EC2 .
Salah satu langkah paling penting adalah memilih wilayah AWS (dasarnya pusat data) di mana kami ingin menggunakan mesin virtual kami. Penempatan akan secara langsung mempengaruhi lokasi geografis "router virtual" Anda, dan karenanya penundaan jaringan saat bekerja dengannya. Ini penting karena AWS tidak menyediakan migrasi langsung antar kawasan (
Layanan Migrasi Server AWS bawaan hanya dapat memigrasi sesuatu ke cloud AWS itu sendiri) dan jika terjadi kesalahan penempatan, lebih mudah untuk membuat kembali instance baru lagi di lokasi yang diinginkan. Atau, Anda harus menghapus gambar dari instance (Gambar, built-in EC2) di
AWS: S3 (layanan penyimpanan) dan dari sana tarik gambar ini ke instance EC2 di wilayah baru. Dalam kasus saya, wilayah
Frankfurt pada awalnya dipilih:
Kami membuat instance baru, pilih opsi
"Free tier only" di sebelah kiri, yang akan membatasi daftar gambar yang diusulkan hanya yang gratis. Saya memilih
"Amazon Linux AMI 2018" (
lebih lanjut tentang distribusi Linux di AWS), karena pada "Amazon Linux 2 AMI" xl2tpd tidak berfungsi dengan baik karena sifat dari kernel yang dirakit oleh Amazon.
Anda dapat memilih gambar Linux lain yang Anda kenal dari daftar yang disediakan. Anda juga dapat masuk lebih dalam ke
AWS Marketplace dan mencari gambar alternatif di sana, cukup hati-hati membaca komentar tentang biayanya: gambar itu sendiri dan sumber daya komputasi dapat gratis, tetapi Anda harus membayar ekstra untuk ruang disk, dll.
Kami memilih tipe yang diusulkan
"t2.micro" , ia menyediakan 1 vCPU, 1 GB memori, 8-30 GB (SSD / Magnetic) ruang disk dan 750 jam kerja gratis setiap bulan selama setahun. Cukup untuk "router virtual" kami. Perlu dicatat bahwa ruang disk kosong dan waktu kerja dihabiskan untuk semua kasus, jadi dalam kasus kesulitan keuangan Anda tidak perlu membuat / menjalankannya lebih dari yang Anda mampu kecuali gratis.
Klik pada wizard "Next ...", pada langkah ke-3 kami meninggalkan semua nilai default, pada tanggal 4 kami setuju dengan standar disk drive SSD 8 gigabyte yang diusulkan dan instance dimulai dengan tombol Tinjau dan Luncurkan:
Setelah itu kita akan mendapatkan jendela dengan pesan tentang membuat pasangan kunci baru untuk menghubungkan ke kita melalui SSH dan proposal untuk memberi nama pasangan ini dan mengunduh kunci pribadi dalam format * .pem. Kami akan sangat membutuhkannya di masa depan, sehingga disarankan untuk segera menyimpannya di tempat yang aman. Jika file ini hilang, Anda akan kehilangan kemampuan untuk terhubung dari jarak jauh ke instance yang menggunakannya. Di EC2, tidak ada cara untuk meregenerasi lagi untuk instance yang ada, satu-satunya cara adalah menghubungkan disk instance ke instance lain yang memiliki akses dan pengeditan tombol berikutnya.
Setelah beberapa saat, instance akan diluncurkan, ia akan memiliki alamat IPv4 internal (pribadi) dan eksternal (publik), serta dua nama DNS yang sesuai.
Segera konfigurasikan Grup Keamanan untuk memastikan arus lalu lintas untuk layanan yang Anda butuhkan:
Kita akan membutuhkan port masuk yang terbuka 500, 1701, 4500 UDP, dan 4500 TCP untuk mengatur terowongan VPN IPSec L2TP, HTTP & HTTPS untuk menerbitkan layanan pertanian rumah, akses eksternal ke instance melalui SSH dibuat secara otomatis ketika membuat instance, karena EC2 pada dasarnya tidak mengandung akses built-in ke konsol mesin virtual melalui antarmuka web-nya. Hanya ada kemampuan untuk melihat layar:
Dianjurkan untuk mengkonfigurasi akses melalui VPN dan SSH hanya dari alamat IP rumah Anda. Urutan aturan di Grup Keamanan tidak masalah.
Karena kami akan menggunakan beberapa dokumentasi NAT, AWS merekomendasikan menonaktifkan
"Pemeriksaan sumber / tujuan jaringan" dalam kasus ini:
Karena kita akan menggunakan tunneling IPSec, dan bukan transport, pengaturan ini tidak masuk akal bagi kita, tetapi untuk berjaga-jaga, lebih baik mematikannya.
Terhubung melalui SSH ke instance kami. Jika Anda menggunakan klien SSH grafis, misalnya, Putty, untuk menghubungkan, bantuan built-in pada koneksi, yang disebut oleh RMB pada contoh -> Connect, akan membantu Anda:
Amazon Linux mempertahankan silsilah dari RHEL dan CentOS, sehingga pengelola paket yum digunakan.
Semua operasi yang dijelaskan di bawah ini harus dilakukan dengan eskalasi hak istimewa, oleh karena itu kami mendahului mereka dengan sudo atau hanya berfungsi sebagai root.
Pembaruan pertama:
Sebagai perangkat lunak untuk mengatur server VPN, kami akan menggunakan kombinasi libreswan dan xl2tpd.
LibreSwan (
cabang dari Openwan dan analog dari StrongSwan) adalah implementasi VPN IPSec dan IKE (Internet Key Exchange) yang populer. Itu dapat dengan benar memotong berbagai jenis NAT dan kombinasinya, yang sangat penting ketika mengatur tunneling IPSec.
xl2tpd juga banyak digunakan, keunggulan utamanya adalah kemampuan bawaan untuk mengautentikasi dan mengirimkan parameter koneksi klien melalui ppp saat menghubungkan (misalnya, alamat IP, pengaturan rute default, server dns, dll.), yang menghilangkan kebutuhan untuk penyebaran DHCP dan Radius tambahan bagi kami tugas sederhana.
Karena xl2tpd tidak dalam repositori standar Amazon Linux, kita perlu mengaktifkan EPEL (Paket Ekstra untuk Linux Perusahaan):
Instal paket yang diperlukan:
Aktifkan perutean level kernel:
di file
/etc/sysctl.conf kita menulis:
net.ipv4.ip_forward = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 1 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.lo.accept_redirects = 0 net.ipv4.conf.lo.secure_redirects = 0 net.ipv4.conf.lo.send_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 net.ipv4.conf.eth0.secure_redirects = 0 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0
Nonaktifkan
rp_filter di sesi saat ini agar tidak melakukan reboot:
Kami menerapkan pengaturan dan memeriksa ketersediaan perutean:
Kita perlu memastikan penerusan paket yang datang (sehubungan dengan antarmuka publik dari instance) dari port layanan yang diperlukan ke terowongan IPSec masa depan kita. Untuk ini, perlu tidak hanya de-NAT paket-paket ini, tetapi juga untuk melakukan penyamaran pada antarmuka
ppp0 .
Kami akan menggunakan fitur
iptables built-in untuk ini, yang dalam kasus Amazon Linux awalnya dikonfigurasi untuk sepenuhnya mengizinkan lalu lintas ke segala arah:
membuat DNAT dari port yang diperlukan:
teruskan semua paket yang datang ke port-port ini ke alamat gerbang Windows:
lakukan penyamaran untuk paket-paket ini:
Dianjurkan untuk menjaga aturan iptables sehingga mereka mengencangkan secara otomatis ketika instance dimulai kembali:
Dalam hal ini, kami menggunakan DNAT (NAT Tujuan) dari port TCP yang diperlukan dari antarmuka jaringan eth0 dari instance ke arah alamat IPv4 10.100.0.2, yang merupakan alamat pada antarmuka ppp layanan RRAS gerbang Windows kami di hypervisor rumah.
Berikut ini adalah poin yang sangat penting: karena layanan di dalam hypervisor harus dapat menanggapi permintaan yang diterima dari instance AWS, maka perlu untuk memberikan penyamaran (mengganti alamat pengirim) pada antarmuka
ppp0 instance sebelum mengirim paket, jika jawabannya akan menuju arah yang sama sekali berbeda: dari gerbang Windows di hypervisor melewati terowongan IPSec langsung ke router default (router rumah), sebagai akibatnya, tentu saja, itu akan dibuang di sisi klien dari layanan, seolah-olah itu berasal dari sumber yang tidak diminta. Jika menyamar digunakan dalam header paket di pintu masuk ke terowongan vpn, alamat pengirim akan berubah dari alamat di suatu tempat di Internet ke alamat
ppp0 dari antarmuka contoh AWS: EC2, mis. dalam kasus saya di 10.100.0.1
Sebagai alternatif untuk menggunakan iptables untuk distribusi Linux lain atau sistem * NIX, Anda dapat merekomendasikan rinetd lama yang baik, di mana semua ini dilakukan secara umum dalam satu baris dalam konfigurasi
rinetd.conf :
<ip source> <port source> <ip destination> <port destination>
Satu-satunya hal yang perlu diaktifkan dalam kasus ini di kernel adalah kemungkinan routing / NAT traffic.
Saatnya memasak libreswan.
File
/etc/ipsec.conf berisi instruksi untuk mengunduh semua file .conf dari /etc/ipsec.d/, jadi kami membuat file konfigurasi baru di direktori /etc/ipsec.d/aws_vpn.conf dan menambahkannya ke:
config setup
Untuk kesederhanaan, kami akan menggunakan otentikasi IPSec berdasarkan kunci bersama (PSK), bukan sertifikat, jadi kami harus menentukannya secara eksplisit. File
/etc/ipsec.secrets berisi instruksi untuk mengunduh semua file .secrets dari
/etc/ipsec.d/ , di sana kami membuat file baru
/etc/ipsec.d/aws_vpn.secrets dan tentukan PSK di dalamnya dalam format:
< 172...> %any : PSK "< PSK>"
Sebagai contoh:
172.31.20.120 %any : PSK "Pa$$w0rd"
Karena koneksi ppp akan digunakan di dalam terowongan IPSec, dan ada autentikasi sendiri, kami mengonfigurasinya juga:
Kami memasukkan nama pengguna dan kata sandi dalam file
/ etc / ppp / chap-secrets dalam format:
<user> * <password> *
Sebagai contoh:
aws_user * Pa$$w0rd *
Saat menghubungkan ke klien ppp, dimungkinkan untuk melewati sejumlah opsi untuk mengkonfigurasi antarmuka jaringan dan tabel perutean pada bagiannya.
Dalam file
/etc/ppp/options.xl2tpd , setel opsi ini:
Karena kita tidak perlu memberikan alamat dns, menang, dll ke klien. hal - semua opsi lain perlu dikomentari.
Di sini Anda memerlukan penjelasan tentang konfigurasi.
Perilaku standar untuk koneksi VPN adalah menginstal Rute Default baru di tabel klien, yang memaksa semua lalu lintas dari itu ke Internet untuk "pergi" melalui server vpn. Dalam kasus kami, ini salah, karena tujuan gerbang Windows adalah untuk menyediakan akses simulasi ke Internet dari jaringan kantor virtual di belakangnya di hypervisor dan untuk mempublikasikan sumber daya layanan internal ke luar melalui AWS: EC2, sehingga tidak rasional untuk mengarahkan semua lalu lintas melalui instance ke AWS: EC2. Inilah sebabnya mengapa Anda perlu mencegah koneksi VPN di RRAS dari mengubah rute default (ke router rumah).
Penting juga untuk memilih nilai MTU dan MRU yang benar: kami menggunakan tunneling IPSec dan ukuran muatan yang terlalu besar mungkin tidak sesuai dengan batas enkapsulasi, yang akan menyebabkan fragmentasi dan kemungkinan besar kesalahan. Jika itu muncul, coba pertama-tama untuk mengurangi nilai-nilai ini, misalnya, ke 1280. Nilai-nilai yang ditunjukkan dalam konfigurasi yang diberikan kompatibel dengan klien Windows VPN.
Masih mengkonfigurasi xl2tpd
Kami mengkonfigurasi semua yang diperlukan dalam file konfigurasi xl2tpd
/etc/xl2tpd/xl2tpd.conf :
[global] port=1701 ipsec saref = yes ; , ;debug tunnel = yes ;debug avp = yes ;debug network = yes ;debug state = yes ;debug tunnel = yes [lns default] name = AWSvpnServer ; ppp ip range = 10.100.0.2-10.100.0.2 ; ppp0 AWS:EC2 local ip = 10.100.0.1 require authentication = yes require chap = yes refuse pap = yes pppoptfile = /etc/ppp/options.xl2tpd length bit = yes
Kami memeriksa semua yang telah kami lakukan
Kami mencoba menjalankan kedua layanan dan memeriksa konfigurasi:
service ipsec start service xl2tpd start ipsec verify
Layanan mungkin sudah berjalan, dalam hal ini mereka hanya restart.
Jika semuanya baik-baik, maka keluaran dari ipsec verifikasi harus sama dengan tangkapan layar:
Anda dapat men-debug xl2tpd secara interaktif dengan menjalankannya dengan sakelar -D dan menggantungnya di “jendela” terpisah dari terminal SSH menggunakan utilitas
layar :
Dalam hal ini, proses xl2tpd tidak akan masuk ke latar belakang, tetapi akan menampilkan semua aktivitasnya di layar terminal.
Jika ada masalah, Anda perlu menghapus komentar opsi debugging di konfigurasi (lihat komentar) dan lihat isi log sistem dan file
/var/log/pluto.log . Perlu juga memperhatikan konten opsi
virtual_private / virtual-private dalam file
/etc/ipsec.conf , ini mencantumkan semua jaringan pribadi yang tersedia untuk bertukar data melalui IPSec. Jika karena alasan tertentu Anda memiliki pengalamatan sendiri, misalnya, Anda menggunakan kumpulan alamat IPv4 putih Anda sendiri, Anda harus membuat perubahan pada parameter ini.
Mari kita beralih ke langkah terakhir - mengatur layanan RRAS di gerbang Windows dan memeriksa publikasi layanan dari Internet
Diasumsikan bahwa hypervisor rumah Anda memiliki mesin virtual yang menjalankan Windows 2012R2 atau lebih baru, yang digunakan dalam mode grafis (Desktop), dan ada dua adapter jaringan dalam mesin virtual ini: satu melihat ke jaringan rumah dan memiliki router rumah sebagai rute default dan yang lainnya menjadi jaringan “kantor” virtual lokal, di mana ada layanan yang diterbitkan di luar. Domain Windows adalah opsional, kecuali tentu saja layanan itu sendiri memerlukannya.
Kami menginstal semua peran yang diperlukan menggunakan Server Manager atau menggunakan cmdlet PowerShell
Install-WindowsFeature :
Di sini saya mendemonstrasikan pemasangan peran melalui grafik, karena dengan begitu masih akan lebih mudah untuk memanggil wizard pengaturan dari Server Manager dan mengkonfigurasi layanan RRAS sendiri dalam jadwal, yang akan menyenangkan kita dengan antarmuka lama yang baik dari saat Windows Server 2003:
Klik RMB di server Anda, pilih
"Konfigurasi dan Aktifkan Perutean dan Akses Jarak Jauh" lalu konfigurasikan secara manual:
Silakan pilih semua gagak, lengkapi wizard dan mulai layanan:
Pertama, mari kita lepaskan jaringan area lokal virtual kami di luar. Kami pergi ke IPv4-> NAT dan membuat antarmuka baru, sebagai antarmuka yang ada di mana NAT akan diimplementasikan, pilih antarmuka eksternal (yang terlihat di Internet, atau lebih tepatnya di jaringan rumah Anda), tandai sebagai publik dan aktifkan NAT di atasnya:
Kami memeriksa bagaimana lalu lintas dari LAN virtual keluar melalui gerbang kami. Kami belum perlu mengkonfigurasi Windows Firewall.
Jika semuanya baik-baik saja, kami akhirnya akan menciptakan apa yang kami perjuangkan, koneksi VPN ke instance AWS kami dan memeriksa publikasi layanan kami. Kami masuk ke snap-in RRAS ke
“Network Interfaces” dan membuat antarmuka Demand-dial baru dengan nama arbitrer:
Segera pilih koneksi L2TP, sehingga antarmuka baru kami tidak akan secara otomatis mencoba menentukan jenis VPN dan akibatnya koneksi akan lebih cepat:
Selanjutnya dalam wizard kami menunjukkan alamat publik cloud kami (dalam kasus saya, Elastic IP). Pada langkah selanjutnya, biarkan semuanya apa adanya, karena kami tidak memerlukan koneksi situs ke situs:
Tentukan akun pengguna di mana kami mengkonfigurasi koneksi ppp (dalam file
/ etc / ppp / chap-secrets ). Tidak diperlukan nama domain:
Wizard membuat koneksi baru. Sekarang tinggal mengkonfigurasinya. Kami akan menyesuaikan batas waktu idle (Idle-time), menghapus CHAP yang ketinggalan zaman hanya mendukung MS-CHAPv2, tentukan kunci PSK di “Properti Lanjutan” (yang ditetapkan untuk xl2tpd dalam file /etc/ipsec.d/aws_vpn. rahasia) dan hapus IPv6:
Setelah membuat antarmuka baru, Anda juga harus masuk ke properti layanan RRAS itu sendiri, mengaktifkan kebijakan IPSec Anda untuk L2TP dan menentukan PSK Anda. Mereka diminta untuk memulai kembali layanan RRAS.
Tampaknya semuanya dapat dengan aman mengangkat antarmuka baru dan menikmati pekerjaan. Tapi tidak. Karena kenyataan bahwa kami menggunakan NAT di sisi AWS: EC2 misalnya, klien Windows VPN tidak akan dapat terhubung ke node Nat-Traversal tersebut. Ini berlaku untuk versi klien (hingga yang terbaru pada saat penulisan artikel Windows 10 build ini) dan untuk versi server.
Untungnya, ada solusi resmi untuk masalah ini dalam bentuk suntingan di registri pengaturan layanan Kebijakan IPSec diikuti oleh reboot:
Di
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ PolicyAgentbuat kunci DWORD (32-bit)
AsumsikanUDPEncapsulationContextOnSendRule = 2dan reboot Windows Gate kami.
Layanan RRAS sayangnya terkenal karena ketidakteraturan dalam konfigurasi dan operasi, dan bahkan setelah reboot, ia melakukan awal yang tertunda. Jadi Anda dapat mempercepatnya setelah reboot.
Jika semuanya dilakukan dengan benar, koneksi akan berfungsi dalam 5-10 detik.
Masih membuat publikasi sumber daya yang diperlukan di gerbang Windows itu sendiri.
Untuk pengujian kami akan mengerjakan publikasi dari server web. Pertama, lihat terowongan IPSec kami dan aturan iptables.
Dengan tangan gemetar, kami memeriksa dari PC sewenang-wenang yang terhubung ke Internet:
Wow, berhasil ...
Selama instalasi peran yang diperlukan, MS IIS "asli" dipasang secara paksa, tetapi kami menginginkannya lebih mudah. Untuk ini, pada platform Windows,
HFS (HTTP File Server) sangat cocok - gratis, tidak memerlukan instalasi, memberikan halaman tertentu dan header HTTP, dapat bekerja pada port arbitrary (secara default adalah 8080, jadi dalam kasus kami perlu mengkonfigurasi ulang ke 80), dan juga segera menulis di konsolnya dari mana koneksi berasal, yang sangat nyaman untuk debugging publikasi banyak sumber daya web pada platform Windows. Untuk menggunakannya, Anda harus terlebih dahulu menghentikan situs MS IIS untuk melepaskan ikatan server tertanam dari port yang diperlukan. Karena kami tidak ingin menginstal konsol manajemen MS IIS (pada kenyataannya, konsol MS IIS 6 akan hadir untuk kompatibilitas, tetapi IIS 7+ tidak dapat dikontrol melalui itu), kami akan melakukan ini melalui PowerShell:
Stop-WebSite -Name "Default Web Site"
atau cukup melalui utilitas manajemen iisreset:
iisreset /stop
Setelah itu, Anda harus mengizinkan lalu lintas masuk ke port 80 di Firewall Windows bawaan.
Kami memulai HFS dan memeriksa:
Semuanya bagus. Kami telah mencapai hal itu dari mana saja di Internet, Anda dapat melihat server web yang tinggal di rumah kami sebagai mesin virtual dalam hypervisor sewenang-wenang.
Sentuhan terakhir: kami mengajarkan RRAS untuk meneruskan semua permintaan seperti itu dari luar ke jaringan kantor virtual, di mana menurut legenda, kami memiliki server web lain.
Untuk melakukan ini, kita kembali ke snap-in manajemen RRAS di IPv4-> NAT dan RMB pada antarmuka VPN kami, di mana kami memilih tab
"Layanan dan Port" , tandai di daftar Server Web dan tentukan server web di jaringan virtual internal yang sumber dayanya ingin kami publikasikan ke internet:
Klik OK dan ... semuanya sudah siap. Kami memeriksa - semuanya akan berfungsi dengan baik.
Sedemikian sederhana, Anda dapat dengan cepat mempublikasikan hampir semua layanan dan sumber daya, dari situs, server mail ke beberapa integrasi kompleks. Biasanya, untuk sebagian besar dari mereka, Anda harus memiliki domain DNS Anda sendiri dengan kemampuan untuk membuat subdomain di dalamnya dan mengedit catatan yang diperlukan. Juga disarankan untuk menggunakan sertifikat SSL untuk menerbitkan sumber daya web,
berkat LetsEncrypt dan layanan yang kompatibel dengan ACME lainnya, semua ini dapat dilakukan sepenuhnya gratis dan dengan pembaruan otomatis.
Ketika Anda me-restart instance, alamat IPv4 publik tidak berubah - hanya ketika dihentikan, tetapi masih disarankan untuk menggunakan alamat IPv4 statis di AWS: EC2. Statis dalam arti bahwa ketika Anda mematikan instance Anda, itu akan tetap ditugaskan untuk itu, dan tidak akan jatuh ke kolam renang umum umum. Tentu saja, ini perlu agar tidak mengganggu setiap saat dengan konfigurasi ulang catatan DNS di domain, dan tidak ada yang membatalkan TTL dengan caching. Harganya banyak uang dan disebut, seperti yang telah disebutkan di atas,
IP Elastis .
Otomatisasi proses primitif
Akhirnya, saya ingin menyebutkan fitur hebat lainnya dari AWS: EC2 - konfigurasi cepat instance yang dapat digunakan. Ada banyak opsi penyebaran cepat di AWS: EC2, hingga layanan khusus (dan agak rumit, tetapi sangat kuat), tetapi ada yang paling sederhana: pada langkah 3 di wisaya untuk membuat contoh baru di bagian bawah adalah bidang
"Data pengguna" . Anda dapat menempatkan skrip di bash atau bahkan PowerShell di dalamnya (dalam hal instance untuk Windows), dan skrip ini akan dieksekusi secara otomatis segera setelah membuat instance.
Yaitu Anda dapat sedikit memodifikasi semua perintah dan konfigurasi di atas untuk membuat skrip bash Anda sendiri dan menggunakannya untuk dengan cepat meningkatkan router AWS: EC2 virtual tersebut.
Pelajari lebih lanjut tentang fitur ini .
Terima kasih telah meluangkan waktu untuk membaca artikel ini.