ASA: VPN порт и статичен PAT за DMZ на един публичен IP

Две услуги, един публичен адрес и DNS име, което сякаш запазва порт. Не го прави. Преди да публикувате DMZ сървър до VPN записа на ASA, запишете кортежите на записите и ги проверете по ред; първото поле, което съвпада със съществуваща услуга, е мястото, където планът спира. Всичко по-долу предполага, че VPN завършва на самото устройство, а не на вътрешен сървър.

Запишете петте полета, преди да напишете командата

За всеки публичен запис отбележете семейството на адреса, публичния адрес, транспорта, публичния порт и собственика. Собственикът е или локална за ASA услуга, или транслатиран вътрешен сървър. Два записа могат да споделят адрес и пак да са различни кортежи, а два записа могат да изглеждат различно на диаграма, докато се сблъскват на устройството.

Дръжте втора колона за реалния порт - този, на който вътрешният сървър всъщност слуша. Публичният порт и реалният порт са независими избори и в момента, в който ги слеете в една колона, губите способността да прочетете собствения си превод по-късно.

Четете реалните и преобразуваните позиции правилно

Започнете от кортежа, който вече имате, а не от сървъра, който искате да добавите. Илюстративното разделяне оставя одобрения VPN запис на публичен TCP 443 и публикува DMZ HTTPS сървър на публичен TCP 8443, докато този сървър продължава да слуша на 443:

Public TCP 443  -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443

В разгърнатата команда реалната услуга и преобразуваната услуга стоят на фиксирани позиции и разменянето им описва друго преобразуване, а не счупено. Това е най-честият начин работещ превод да се превърне в загадка: конфигурацията е валидна, тя просто сочи другаде.

Ръководството ASA 9.16 NAT на Cisco документира статичния PAT, използването на адрес на интерфейс и значенията на реалния срещу преобразувания порт. Прочетете раздела за версията, която действително използвате; команда, запомнена от по-стара платформа, не е пълна текуща конфигурация.

Отчитайте транспорта като част от резервацията

TCP 443 и UDP 443 са различни кортежи и тази разлика не ви дава UDP безплатно. VPN може да има отделни TLS и DTLS слушатели, а други конфигурирани услуги може вече да държат транспорта, който искате. Направете опис на ефективните слушатели и политиката за достъп, вместо да приемате, че уеб страницата е целият VPN запис.

Второ име на хост, което се разрешава до същия адрес, също не решава сблъсък на ниво транспорт. DNS е преобразуване от име към адрес, а не брокер на портове, и публикуването на сървър чрез PAT не е същата операция като преместването на VPN слушателя на друг порт.

Ако VPN записът наистина трябва да се премести, четири неща се променят заедно: клиентският профил, публичният URL, филтрирането по веригата и всеки транспорт, който разгръщането използва. Направете ги в един прозорец, а не едно по едно. Дръжте отделен път за управление към устройството отворен, преди да докоснете услугата, през която го достигате. Без втори път преместването е промяна, от която не можете да се откажете отвън.

Проверявайте отвън със свежи връзки

Разрешете само предвиденото DMZ приложение под ефективната политика за достъп, след което проверете съответния ред на преобразуване, обратния път на сървъра и името на хоста в сертификата. PAT променя мрежовата дестинация; той не дава достъп до приложението и не поправя сертификат, който посочва друг хост.

Тествайте двете услуги с нови връзки от оторизиран външен хост: VPN трябва все още да се установява, а DMZ заявката трябва да достигне своя предвиден слушател. Установена сесия може да пази предишно състояние, така че тя не доказва нищо за преобразуване, което сте променили преди минута.

Затворете цикъла, като актуализирате описа на записите с това, което сте разгърнали, включително всеки слушател, който сте открили, а не създали. Следващият човек, който публикува услуга на този адрес, ще започне от вашата таблица и грешен ред там струва повече от грешна команда тук.